From isms-bounces@lists.ietf.org Fri Jul 01 05:41:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoI1Z-0003Zk-1z; Fri, 01 Jul 2005 05:41:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoHtt-0003i9-OU for isms@megatron.ietf.org; Fri, 01 Jul 2005 05:33:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13525 for ; Fri, 1 Jul 2005 05:33:28 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoIJl-0008E6-P5 for isms@ietf.org; Fri, 01 Jul 2005 06:00:19 -0400 Received: from pc6 (1Cust59.tnt14.lnd4.gbr.da.uu.net [62.188.143.59]) by galaxy.systems.pipex.net (Postfix) with SMTP id E2A79E0000BD; Fri, 1 Jul 2005 10:33:07 +0100 (BST) Message-ID: <010301c57e17$7579eec0$0601a8c0@pc6> From: "Tom Petch" To: "Fleischman, Eric" , References: <474EEBD229DF754FB83D256004D021080EC38D@XCH-NW-6V1.nw.nos.boeing.com> Subject: Re: [Isms] Coming to consensus Date: Fri, 1 Jul 2005 09:54:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Fleischman, Eric" To: "Ken Hornstein" ; Sent: Friday, July 01, 2005 12:42 AM Subject: RE: [Isms] Coming to consensus >Group: >Don't both TLS and SSH require TCP transports while only DTLS can >support UDP? To quote from "draft-ietf-secsh-architecture-22.txt" "The transport layer will typically be run over a TCP/IP connection, but might also be used on top of any other reliable data stream." so SSH does not need everything TCP has to offer, just reliability. (I seem to recall this coming up in other places, that neither UDP nor TCP are right for the upper layers, leading protocol designers to cast around for something that fits better.) _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 07:00:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoJFw-0003PL-7z; Fri, 01 Jul 2005 07:00:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoJFu-0003KV-FY for isms@megatron.ietf.org; Fri, 01 Jul 2005 07:00:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05543 for ; Fri, 1 Jul 2005 07:00:19 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoJfX-0001tC-8b for isms@ietf.org; Fri, 01 Jul 2005 07:26:52 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 542203969B; Fri, 1 Jul 2005 12:59:47 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 02581-03; Fri, 1 Jul 2005 12:59:46 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id D26BD399CA; Fri, 1 Jul 2005 12:59:43 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id EF1B8353F9C; Fri, 1 Jul 2005 09:41:50 +0200 (CEST) Date: Fri, 1 Jul 2005 09:41:50 +0200 From: Juergen Schoenwaelder To: Ken Hornstein Subject: Re: [Isms] Coming to consensus Message-ID: <20050701074150.GC2223@boskop.local> Mail-Followup-To: Ken Hornstein , isms@ietf.org References: <200506302231.j5UMVOOU011505@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506302231.j5UMVOOU011505@ginger.cmf.nrl.navy.mil> User-Agent: Mutt/1.5.8i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.7 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Thu, Jun 30, 2005 at 06:31:25PM -0400, Ken Hornstein wrote: > Of these three obvious choices, the first two really want a stream transport > (TCP). Obviously, DTLS does not. Can someone explain DTLS for dummies please? In particular, I would like to know what the header size is that we have to add to SNMP messages for DTLS. In addition, I would like to know what the effort is to establish a DTLS session and more important how long such a DTLS session will last or when it needs to be renewed. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 07:00:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoJFw-0003Pl-Ee; Fri, 01 Jul 2005 07:00:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoJFu-0003LR-Q9 for isms@megatron.ietf.org; Fri, 01 Jul 2005 07:00:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05551 for ; Fri, 1 Jul 2005 07:00:19 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoJfX-0001t9-Cs for isms@ietf.org; Fri, 01 Jul 2005 07:26:51 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 77EA3399CD; Fri, 1 Jul 2005 12:59:44 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 02518-07; Fri, 1 Jul 2005 12:59:43 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id B65EC3918C; Fri, 1 Jul 2005 12:59:43 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 412D1353F85; Fri, 1 Jul 2005 09:38:20 +0200 (CEST) Date: Fri, 1 Jul 2005 09:38:20 +0200 From: Juergen Schoenwaelder To: "Fleischman, Eric" Subject: Re: [Isms] Coming to consensus Message-ID: <20050701073820.GB2223@boskop.local> Mail-Followup-To: "Fleischman, Eric" , Ken Hornstein , isms@ietf.org References: <474EEBD229DF754FB83D256004D021080EC38D@XCH-NW-6V1.nw.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <474EEBD229DF754FB83D256004D021080EC38D@XCH-NW-6V1.nw.nos.boeing.com> User-Agent: Mutt/1.5.8i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.7 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Thu, Jun 30, 2005 at 03:42:34PM -0700, Fleischman, Eric wrote: > My own perspective (for whatever it is worth) is that SNMP has had > better performance in wireless and bandwidth constrained environments > using UDP than TCP. Can you point me to the details of this study? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 07:00:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoJFw-0003QE-Ln; Fri, 01 Jul 2005 07:00:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoJFv-0003MD-0v for isms@megatron.ietf.org; Fri, 01 Jul 2005 07:00:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05556 for ; Fri, 1 Jul 2005 07:00:19 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoJfX-0001tB-Bm for isms@ietf.org; Fri, 01 Jul 2005 07:26:51 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 9BBEB3918C; Fri, 1 Jul 2005 12:59:46 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 02521-07; Fri, 1 Jul 2005 12:59:45 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id CAAB5399A2; Fri, 1 Jul 2005 12:59:43 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 0A8CE353F6E; Fri, 1 Jul 2005 09:37:25 +0200 (CEST) Date: Fri, 1 Jul 2005 09:37:25 +0200 From: Juergen Schoenwaelder To: Kaushik Narayan Subject: Re: [Isms] Coming to consensus Message-ID: <20050701073725.GA2223@boskop.local> Mail-Followup-To: Kaushik Narayan , Ken Hornstein , isms@ietf.org, elear@cisco.com References: <200506302231.j5UMVOOU011505@ginger.cmf.nrl.navy.mil> <6.2.0.14.0.20050630170124.03861eb8@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.0.14.0.20050630170124.03861eb8@email.cisco.com> User-Agent: Mutt/1.5.8i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.7 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: elear@cisco.com, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Thu, Jun 30, 2005 at 05:06:04PM -0700, Kaushik Narayan wrote: > We believe that BEEP should be considered as a choice > of encapsulation protocol for ISMS. This will align us closer > to NetConf and Secure Syslog. The default to support netconf transport mapping as we all know is ssh. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 09:19:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoLQp-0004gK-D8; Fri, 01 Jul 2005 09:19:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoLQn-0004al-7P for isms@megatron.ietf.org; Fri, 01 Jul 2005 09:19:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21832 for ; Fri, 1 Jul 2005 09:19:41 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoLql-0001Tz-B5 for isms@ietf.org; Fri, 01 Jul 2005 09:46:35 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 01 Jul 2005 06:19:35 -0700 X-IronPort-AV: i="3.93,250,1115017200"; d="scan'208"; a="285017026:sNHT30957772" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j61DJXVX021721; Fri, 1 Jul 2005 06:19:33 -0700 (PDT) Received: from [144.254.23.76] (dhcp-data-vlan10-23-76.cisco.com [144.254.23.76]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j61DIu5L011581; Fri, 1 Jul 2005 06:18:56 -0700 Message-ID: <42C542E3.8090103@cisco.com> Date: Fri, 01 Jul 2005 15:19:31 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0+ (Macintosh/20050531) MIME-Version: 1.0 To: Ken Hornstein Subject: Re: [Isms] Coming to consensus References: <200506302231.j5UMVOOU011505@ginger.cmf.nrl.navy.mil> In-Reply-To: <200506302231.j5UMVOOU011505@ginger.cmf.nrl.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1120223937.318278"; x:"432200"; a:"rsa-sha1"; b:"nofws:2156"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"JCQhBM8zV6NY6+bxLGFn1dBZc6tVloQ5VUq4cERWYZl+e7cdH0kRguuTa2zhPJrgEGn3sChK" "dBk5xNwLd5H2Z7o+pycES9txQZ/d6aBTu0/Infnl1r6EUOyczQAVMmXeAH7ubUctDWEzXLbvqHv" "0K4OdX+Sa9ZzSAdhbEdSZnYA="; c:"Date: Fri, 01 Jul 2005 15:19:31 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] Coming to consensus" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Ken, My strong recommendation would be that if we are going to do TCP+SASL it should be a BEEP profile. There are substantial ancillary benefits for BEEP. For instance, the ability to multiplex streams such as NETCONF, secure SYSLOG, and the like come immediately to mind. Also, it may simply configuration in these cases - you do one authentication transaction and you're done (as per the BEEP spec) for all the substrates. In addition BEEP offers the ability for connection establishment to occur in either direction, and that has benefits with regard to NATs and firewalls. In the coming weeks I will work with others to submit a viable proposal along these lines. Regards, Eliot Ken Hornstein wrote: > ISMS participants: > > First off, my apologies for not being more active in recent weeks; the > rest of my life keeps intruding onto IETF work. > > To cut to the chase: I recently had a conference call with our sheperding > AD, Sam Hartman, regarding the current status of ISMS. These are the > conclusions that we came to: > > - The consensus declaration for encapsulation keying has been accepted by > the working group. > > - There has been no clear consensus expressed by the WG participants regarding > a particular protocol to be used by ISMS with EK. > > - There are three obvious choices (to us) for protocols to be used by ISMS: > > TLS+SASL (more on us throwing SASL into this mix in a moment) > SSH > DTLS > > Of these three obvious choices, the first two really want a stream transport > (TCP). Obviously, DTLS does not. > > So, the question before the ISMS WG is: which protocol do we want? Other > suggestions for protocols to be used are welcome; Sam and I just listed > the ones that we saw people talking about, and ones that we thought were > a reasonable fit for ISMS. We would like the WG to come to a consensus > by August. If we had a draft by then, that would be great, but we do > not view that as necessary. > > Regarding TLS+SASL ... since the desire of ISMS is to produce a protocol > which can leverage other authentication mechanisms, not only do you want > to use TLS (which will provide session encryption plus the use of PK > certificates), but you also want provisions to use SASL (or something like > SASL I suppose, but I'm not aware of an equivalant), which supports > a wide variety of authentication mechanisms. This combination has been > used by a number of protocols within the IETF community, and seems to > be rather successful. > > --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@lists.ietf.org Fri Jul 01 09:25:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoLWh-0000sK-Ce; Fri, 01 Jul 2005 09:25:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoLWf-0000oS-TZ for isms@megatron.ietf.org; Fri, 01 Jul 2005 09:25:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22420 for ; Fri, 1 Jul 2005 09:25:47 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoLwd-0001fz-Aw for isms@ietf.org; Fri, 01 Jul 2005 09:52:40 -0400 Received: from pc6 (1Cust217.tnt105.lnd4.gbr.da.uu.net [213.116.58.217]) by galaxy.systems.pipex.net (Postfix) with SMTP id E40DDE000278; Fri, 1 Jul 2005 14:25:31 +0100 (BST) Message-ID: <023501c57e37$ec7ad0a0$0601a8c0@pc6> From: "Tom Petch" To: References: <474EEBD229DF754FB83D256004D021080EC300@XCH-NW-6V1.nw.nos.boeing.com> <20050601171147.GD29036@boskop.local> Date: Fri, 1 Jul 2005 14:24:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: [Isms] SNMP over TCP X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen, As author of RFC3430, do you have a view as to how many implementations, or potential implementations, of this there are? Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 10:02:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoM62-0004dZ-L3; Fri, 01 Jul 2005 10:02:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoM61-0004dR-9R for isms@megatron.ietf.org; Fri, 01 Jul 2005 10:02:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26446 for ; Fri, 1 Jul 2005 10:02:19 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoMVy-0004Ar-U3 for isms@ietf.org; Fri, 01 Jul 2005 10:29:12 -0400 Received: from pc6 (1Cust114.tnt109.lnd4.gbr.da.uu.net [62.188.172.114]) by galaxy.systems.pipex.net (Postfix) with SMTP id 619C9E0002AC; Fri, 1 Jul 2005 15:02:07 +0100 (BST) Message-ID: <02bd01c57e3d$09dfe4a0$0601a8c0@pc6> From: "Tom Petch" To: References: <200506302231.j5UMVOOU011505@ginger.cmf.nrl.navy.mil> <20050701074150.GC2223@boskop.local> Subject: DTLS for Dummies wasRe: [Isms] Coming to consensus Date: Fri, 1 Jul 2005 15:00:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen DTLS is a single I-D, namely draft-rescorla-dtls-04.txt, 25pp; I am not sure if it is standards track. It adds epoch and sequence number, 64bit, to a TLS packet, retransmits on timeout, may detect duplicate/replayed packets. I would not say it introduces the concept of a session to UDP; except insofar as one is implied by the 5-tuple of protocol, ports and IP addresses. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Ken Hornstein" Cc: Sent: Friday, July 01, 2005 9:41 AM Subject: Re: [Isms] Coming to consensus > On Thu, Jun 30, 2005 at 06:31:25PM -0400, Ken Hornstein wrote: > > > Of these three obvious choices, the first two really want a stream transport > > (TCP). Obviously, DTLS does not. > > Can someone explain DTLS for dummies please? In particular, I would > like to know what the header size is that we have to add to SNMP > messages for DTLS. In addition, I would like to know what the effort > is to establish a DTLS session and more important how long such a > DTLS session will last or when it needs to be renewed. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 11:04:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoN4O-0005uN-4R; Fri, 01 Jul 2005 11:04:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoN4M-0005pF-RL for isms@megatron.ietf.org; Fri, 01 Jul 2005 11:04:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03507 for ; Fri, 1 Jul 2005 11:04:40 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoNUJ-0001Wn-5t for isms@ietf.org; Fri, 01 Jul 2005 11:31:34 -0400 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 j61F3PO2021353; Fri, 1 Jul 2005 11:03:30 -0400 (EDT) Message-Id: <200507011503.j61F3PO2021353@ginger.cmf.nrl.navy.mil> To: Kaushik Narayan Subject: Re: [Isms] Coming to consensus In-Reply-To: <6.2.0.14.0.20050630170124.03861eb8@email.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: Fri, 01 Jul 2005 11:03:27 -0400 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: isms@ietf.org, elear@cisco.com X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >We believe that BEEP should be considered as a choice >of encapsulation protocol for ISMS. This will align us closer >to NetConf and Secure Syslog. I'll add it to the list. Buuuutttt .... are you sure it makes sense? I ask because as I understand BEEP, it's really designed as an application protocol layer with framing, flow control, etc etc ... which I think might be a bit heavyweight for SNMP's needs. Also, I'll note that BEEP security is currently defined as TLS+SASL. I guess what the working group needs to decide is (if we come to a consensus that TLS+SASL is the way to go) does adding BEEP to the mix gain us anything versus using TLS+SASL directly. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 11:17:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoNGe-00078T-Ql; Fri, 01 Jul 2005 11:17:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoNGd-00078O-Br for isms@megatron.ietf.org; Fri, 01 Jul 2005 11:17:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04368 for ; Fri, 1 Jul 2005 11:17:20 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoNgb-0002ox-PY for isms@ietf.org; Fri, 01 Jul 2005 11:44:15 -0400 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 j61FHCSW021578 for ; Fri, 1 Jul 2005 11:17:16 -0400 (EDT) Message-Id: <200507011517.j61FHCSW021578@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Coming to consensus In-Reply-To: <42C542E3.8090103@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: Fri, 01 Jul 2005 11:17:14 -0400 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: 7aefe408d50e9c7c47615841cb314bed Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >In the coming weeks I will work with others to submit a viable proposal >along these lines. I admit BEEP is not my forte, but I'm sure a draft describing how one would do SNMP over BEEP would be extremely helpful in discussing it. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 12:30:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoOOu-0000if-LO; Fri, 01 Jul 2005 12:30:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoOOs-0000iP-GW for isms@megatron.ietf.org; Fri, 01 Jul 2005 12:29:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12729 for ; Fri, 1 Jul 2005 12:29:55 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoOop-0002Sg-AT for isms@ietf.org; Fri, 01 Jul 2005 12:56:50 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA21688; Fri, 1 Jul 2005 09:29:43 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j61GTgv16252; Fri, 1 Jul 2005 11:29:42 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 09:29:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Coming to consensus Date: Fri, 1 Jul 2005 09:29:41 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC38F@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] Coming to consensus Thread-Index: AcV+H+ZFx2zWO6DdSZ2ekQ/v98ny7gAOZFTA From: "Fleischman, Eric" To: "Tom Petch" , X-OriginalArrivalTime: 01 Jul 2005 16:29:42.0419 (UTC) FILETIME=[15954E30:01C57E5A] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom, The quote you read means that SSH should not operate on top of an unreliable data stream such as UDP but it can operate on top of a reliable data stream such as TCP and probably SCTP. Based on this quote it would seem to me that to select SSH would imply that SNMP must use TCP transports only. If so, then I personally advise against the SSH option because our experience is that SNMP behaves poorly using TCP within bandwidth limited environments. Therefore, I prefer SNMP to be able to use UDP. Therefore, based on this limited information, it appears to me that (D)TLS is a preferable alternative when compared to SSH. --Eric -----Original Message----- From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 Sent: Friday, July 01, 2005 12:54 AM >Don't both TLS and SSH require TCP transports while only DTLS can=20 >support UDP? To quote from "draft-ietf-secsh-architecture-22.txt" "The transport layer will typically be run over a TCP/IP connection, but might also be used on top of any other reliable data stream." so SSH does not need everything TCP has to offer, just reliability. (I seem to recall this coming up in other places, that neither UDP nor TCP are right for the upper layers, leading protocol designers to cast around for something that fits better.) _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 12:48:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoOhF-0004iT-4G; Fri, 01 Jul 2005 12:48:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoOhD-0004iJ-Rp for isms@megatron.ietf.org; Fri, 01 Jul 2005 12:48:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14367 for ; Fri, 1 Jul 2005 12:48:52 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoP7C-0004R7-Ti for isms@ietf.org; Fri, 01 Jul 2005 13:15:48 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j61GmXGn022035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jul 2005 09:48:34 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j61GmQWb001315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Jul 2005 09:48:29 -0700 (PDT) Message-ID: <42C573E3.6050304@qualcomm.com> Date: Fri, 01 Jul 2005 12:48:35 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Petch Subject: Re: DTLS for Dummies wasRe: [Isms] Coming to consensus References: <200506302231.j5UMVOOU011505@ginger.cmf.nrl.navy.mil> <20050701074150.GC2223@boskop.local> <02bd01c57e3d$09dfe4a0$0601a8c0@pc6> In-Reply-To: <02bd01c57e3d$09dfe4a0$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Just on the first part of your note: DTLS is indeed standards track and has been approved by the IESG recently (this week) and is in the RFC Ed queue now. https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11289&rfc_flag=0 regards, Lakshminath Tom Petch wrote: >Juergen > >DTLS is a single I-D, namely draft-rescorla-dtls-04.txt, 25pp; I am not sure if >it is standards track. > >It adds epoch and sequence number, 64bit, to a TLS packet, retransmits on >timeout, may detect duplicate/replayed packets. > >I would not say it introduces the concept of a session to UDP; except insofar as >one is implied by the 5-tuple of protocol, ports and IP addresses. > >Tom Petch > >----- Original Message ----- >From: "Juergen Schoenwaelder" >To: "Ken Hornstein" >Cc: >Sent: Friday, July 01, 2005 9:41 AM >Subject: Re: [Isms] Coming to consensus > > > > >>On Thu, Jun 30, 2005 at 06:31:25PM -0400, Ken Hornstein wrote: >> >> >> >>>Of these three obvious choices, the first two really want a stream transport >>>(TCP). Obviously, DTLS does not. >>> >>> >>Can someone explain DTLS for dummies please? In particular, I would >>like to know what the header size is that we have to add to SNMP >>messages for DTLS. In addition, I would like to know what the effort >>is to establish a DTLS session and more important how long such a >>DTLS session will last or when it needs to be renewed. >> >>/js >> >>-- >>Juergen Schoenwaelder International University Bremen >> P.O. Box 750 561, 28725 Bremen, Germany >> >>_______________________________________________ >>Isms mailing list >>Isms@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/isms >> >> > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 13:02:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoOul-0004kJ-Ub; Fri, 01 Jul 2005 13:02:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoOuk-0004gX-Fn for isms@megatron.ietf.org; Fri, 01 Jul 2005 13:02:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15402 for ; Fri, 1 Jul 2005 13:02:49 -0400 (EDT) Message-Id: <200507011702.NAA15402@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoPKh-0005zV-Rv for isms@ietf.org; Fri, 01 Jul 2005 13:29:45 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc13) with SMTP id <20050701170239016000md0oe>; Fri, 1 Jul 2005 17:02:40 +0000 From: "David B Harrington" To: "'Fleischman, Eric'" , "'Tom Petch'" , Subject: RE: [Isms] Coming to consensus Date: Fri, 1 Jul 2005 13:02:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-reply-to: <474EEBD229DF754FB83D256004D021080EC38F@XCH-NW-6V1.nw.nos.boeing.com> Thread-Index: AcV+H+ZFx2zWO6DdSZ2ekQ/v98ny7gAOZFTAAAEMaWA= X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, > our experience is that SNMP behaves > poorly using TCP within bandwidth limited environments. When you say "our experience", can you qualify "our"? Is that Boeing? IETF? Can you share the research that quantifies this assertion? The debate about TCP or UDP for SNMP has raged for years. I'd be interested in seeing some rigorous research on this. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 13:11:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoP3H-0007nR-MU; Fri, 01 Jul 2005 13:11:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoP3G-0007mv-Vj for isms@megatron.ietf.org; Fri, 01 Jul 2005 13:11:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16149 for ; Fri, 1 Jul 2005 13:11:39 -0400 (EDT) Received: from i887e.i.pppool.de ([85.73.136.126] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoPTG-0006YU-9C for isms@ietf.org; Fri, 01 Jul 2005 13:38:35 -0400 Received: by boskop.local (Postfix, from userid 501) id 3F7513544D0; Fri, 1 Jul 2005 19:11:18 +0200 (CEST) Date: Fri, 1 Jul 2005 19:11:18 +0200 From: Juergen Schoenwaelder To: Tom Petch Message-ID: <20050701171118.GA626@boskop.local> Mail-Followup-To: Tom Petch , isms@ietf.org References: <474EEBD229DF754FB83D256004D021080EC300@XCH-NW-6V1.nw.nos.boeing.com> <20050601171147.GD29036@boskop.local> <023501c57e37$ec7ad0a0$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <023501c57e37$ec7ad0a0$0601a8c0@pc6> User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: isms@ietf.org Subject: [Isms] Re: SNMP over TCP X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Fri, Jul 01, 2005 at 02:24:28PM +0200, Tom Petch wrote: > Juergen, > > As author of RFC3430, do you have a view as to how many implementations, or > potential implementations, of this there are? No. I know that for example NET-SNMP supports SNMP over TCP and there are others I have heard of but where I do not have first hand info. But even if I were to have a number, I would not know how to interpret the number. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 13:11:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoP3V-0007xv-37; Fri, 01 Jul 2005 13:11:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoP3S-0007xn-Oq for isms@megatron.ietf.org; Fri, 01 Jul 2005 13:11:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16221 for ; Fri, 1 Jul 2005 13:11:51 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoPTS-0006Zd-SJ for isms@ietf.org; Fri, 01 Jul 2005 13:38:47 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA11193; Fri, 1 Jul 2005 10:11:41 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j61HBev07851; Fri, 1 Jul 2005 12:11:40 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 10:11:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Coming to consensus Date: Fri, 1 Jul 2005 10:11:34 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC391@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] Coming to consensus Thread-Index: AcV+K/+gOxxvySwMTtyG0Dvy/ICmcAAL5duw From: "Fleischman, Eric" To: X-OriginalArrivalTime: 01 Jul 2005 17:11:34.0747 (UTC) FILETIME=[EF0C22B0:01C57E5F] 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen, I'm sorry but I think that you will find (or, at least, this is what I concluded after seeing many different studies over the years) that SNMP performance results are heavily gated by the specific target environment. Studies exist (e.g., see http://www.ee.umd.edu/~dxj/IM2001.pdf#search=3D'SNMP%20use%20of%20TCP') concluding that SNMP performs much better over TCP for large bulk transfers, for example. However, our experience is that SNMP performs considerably worse using TCP within capacity limited environments and also within wireless environments. The reason for this should be obvious: in the former case (capacity limited environments) it is due to UDP packets not being "good corporate citizens" and gobbling up all the capacity they can, causing TCP transmissions to "back off"; in the latter case (wireless) it is due to how TCP behaves in high signal intermittence environments. In addition, TCP's misbehavior in high latency environments (e.g., across geo-stationary satellites) is also well-studied and well known, though I don't know of anyone who actually used SNMP-over-TCP in that environment. Regardless, I believe that the choice of which transport protocol to use for SNMP is very much a function of where and how you want to use it. Consequently, I believe that whatever session security we choose should be able to support both SNMP transport alternatives. If it is actually the case that SSH is only able to use reliable transports, then it is not as viable an alternative as (D)TLS. If this is indeed the case, then ISMS' determining the preferential protocol should be a "no op" -- use the one that can handle both UDP and TCP uses. --Eric -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 Sent: Friday, July 01, 2005 12:38 AM > My own perspective (for whatever it is worth) is that SNMP has had=20 > better performance in wireless and bandwidth constrained environments=20 > using UDP than TCP. Can you point me to the details of this study? /js _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 13:44:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoPZM-0004oH-Dm; Fri, 01 Jul 2005 13:44:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoPZK-0004ny-Oj for isms@megatron.ietf.org; Fri, 01 Jul 2005 13:44:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20746 for ; Fri, 1 Jul 2005 13:44:47 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoPzL-0001Xz-7N for isms@ietf.org; Fri, 01 Jul 2005 14:11:43 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 01 Jul 2005 10:44:41 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j61Hi5Vx025743; Fri, 1 Jul 2005 10:44:37 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 10:44:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DTLS for Dummies wasRe: [Isms] Coming to consensus Date: Fri, 1 Jul 2005 10:44:26 -0700 Message-ID: Thread-Topic: DTLS for Dummies wasRe: [Isms] Coming to consensus Thread-Index: AcV+RarVIKT2F0ihTSajIchWA1y2WQAG7a0g From: "Khanh Nguyen \(khanhvn\)" To: "Tom Petch" , X-OriginalArrivalTime: 01 Jul 2005 17:44:28.0589 (UTC) FILETIME=[878C85D0:01C57E64] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org As far as I remember, DTLS acknowledgement/retransmission are used only during initial handshaking. DTLS data are not ack'ed and thus not reliable. The use of seq # as Tom said will provide replay protection though. Encryption and MAC are similar to TLS, except explicit CBC IV & seq # is used. In terms of connection establishment, DTLS has more overhead than TLS because of extra handshake messages (6 packets in DTLS vs 4 in TLS). Khanh > -----Original Message----- > From: isms-bounces@lists.ietf.org=20 > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Tom Petch > Sent: Friday, July 01, 2005 6:01 AM > To: j.schoenwaelder@iu-bremen.de > Cc: isms@ietf.org > Subject: DTLS for Dummies wasRe: [Isms] Coming to consensus >=20 > Juergen >=20 > DTLS is a single I-D, namely draft-rescorla-dtls-04.txt,=20 > 25pp; I am not sure if it is standards track. >=20 > It adds epoch and sequence number, 64bit, to a TLS packet,=20 > retransmits on timeout, may detect duplicate/replayed packets. >=20 > I would not say it introduces the concept of a session to=20 > UDP; except insofar as one is implied by the 5-tuple of=20 > protocol, ports and IP addresses. >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "Ken Hornstein" > Cc: > Sent: Friday, July 01, 2005 9:41 AM > Subject: Re: [Isms] Coming to consensus >=20 >=20 > > On Thu, Jun 30, 2005 at 06:31:25PM -0400, Ken Hornstein wrote: > > > > > Of these three obvious choices, the first two really want=20 > a stream=20 > > > transport (TCP). Obviously, DTLS does not. > > > > Can someone explain DTLS for dummies please? In particular, I would=20 > > like to know what the header size is that we have to add to SNMP=20 > > messages for DTLS. In addition, I would like to know what=20 > the effort=20 > > is to establish a DTLS session and more important how long=20 > such a DTLS=20 > > session will last or when it needs to be renewed. > > > > /js > > > > -- > > Juergen Schoenwaelder International University Bremen > > P.O. Box 750 561, 28725=20 > Bremen, Germany > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 14:23:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQAz-00082q-49; Fri, 01 Jul 2005 14:23:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQAx-00082l-Hm for isms@megatron.ietf.org; Fri, 01 Jul 2005 14:23:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25477 for ; Fri, 1 Jul 2005 14:23:39 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoQay-0003J1-CY for isms@ietf.org; Fri, 01 Jul 2005 14:50:36 -0400 Received: from pc6 (1Cust83.tnt102.lnd4.gbr.da.uu.net [213.116.52.83]) by galaxy.systems.pipex.net (Postfix) with SMTP id 1000DE0001A5; Fri, 1 Jul 2005 19:23:21 +0100 (BST) Message-ID: <035201c57e61$886d0220$0601a8c0@pc6> From: "Tom Petch" To: "Fleischman, Eric" , References: <474EEBD229DF754FB83D256004D021080EC38F@XCH-NW-6V1.nw.nos.boeing.com> Subject: (D)TLS considered harmful: was Re: [Isms] Coming to consensus Date: Fri, 1 Jul 2005 19:22:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.9 (++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I think the use of the term (D)TLS somewhat misleading. TLS, reliable transport based, a comprehensive set of I-Ds updating well established RFC, in turn building on extensive experience of the similar but differently named SSL, I regard as a mature standard, worthy of serious consideration for any security issue. DTLS is a single I-D, in the RFC editor queue (thanks for that), expects to achieve reliable transport with 64 bits of extra header. Its pedigree is impeccable but it is untested. Will it fly? will it prove vulnerable to some class of attacks, will it be widely available, will it go on being updated in parallel with TLS? So I see two very different protocols even if in their elements of security they share a common set of methods. To refer to them together as (D)TLS as if were something like FTP which can be configured to run over TCP or UDP I think misleading. Tom Petch ----- Original Message ----- From: "Fleischman, Eric" To: "Tom Petch" ; Sent: Friday, July 01, 2005 6:29 PM Subject: RE: [Isms] Coming to consensus Tom, The quote you read means that SSH should not operate on top of an unreliable data stream such as UDP but it can operate on top of a reliable data stream such as TCP and probably SCTP. Based on this quote it would seem to me that to select SSH would imply that SNMP must use TCP transports only. If so, then I personally advise against the SSH option because our experience is that SNMP behaves poorly using TCP within bandwidth limited environments. Therefore, I prefer SNMP to be able to use UDP. Therefore, based on this limited information, it appears to me that (D)TLS is a preferable alternative when compared to SSH. --Eric -----Original Message----- From: Tom Petch [mailto:nwnetworks@dial.pipex.com] Sent: Friday, July 01, 2005 12:54 AM >Don't both TLS and SSH require TCP transports while only DTLS can >support UDP? To quote from "draft-ietf-secsh-architecture-22.txt" "The transport layer will typically be run over a TCP/IP connection, but might also be used on top of any other reliable data stream." so SSH does not need everything TCP has to offer, just reliability. (I seem to recall this coming up in other places, that neither UDP nor TCP are right for the upper layers, leading protocol designers to cast around for something that fits better.) _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 14:55:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQg5-0007yM-9s; Fri, 01 Jul 2005 14:55:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQg4-0007xM-42 for isms@megatron.ietf.org; Fri, 01 Jul 2005 14:55:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28763 for ; Fri, 1 Jul 2005 14:55:48 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoR63-0004iA-0L for isms@ietf.org; Fri, 01 Jul 2005 15:22:45 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j61J4ZR3019463 for ; Fri, 1 Jul 2005 12:04:35 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j61J0VwJ012965 for ; Fri, 1 Jul 2005 14:00:31 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Jul 2005 14:55:43 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF238109EBFD9B@ma19exm01.e6.bcs.mot.com> From: Donati Andrew-MGIA0477 To: ietfdbh@comcast.net, "'Fleischman, Eric'" , "'Tom Petch'" , isms@ietf.org Subject: RE: [Isms] Coming to consensus Date: Fri, 1 Jul 2005 14:55:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I heard of an observation from someone who noted that SNMP over TCP is not scalable with many devices. However, it would be interesting to hear about experiences using SNMP over TCP in the case where a table is read that contains over a thousand rows of data from one or a few devices. Perhaps the answer would be to use both UDP and TCP. Use TCP to read large tables (from only a few devices at a time) and use UDP for all other cases. Thanks, Andy -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Friday, July 01, 2005 1:03 PM To: 'Fleischman, Eric'; 'Tom Petch'; isms@ietf.org Subject: RE: [Isms] Coming to consensus Hi, > our experience is that SNMP behaves > poorly using TCP within bandwidth limited environments. When you say "our experience", can you qualify "our"? Is that Boeing? IETF? Can you share the research that quantifies this assertion? The debate about TCP or UDP for SNMP has raged for years. I'd be interested in seeing some rigorous research on this. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 14:57:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQhA-0002LW-VQ; Fri, 01 Jul 2005 14:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQh9-0002DC-I7 for isms@megatron.ietf.org; Fri, 01 Jul 2005 14:56:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28854 for ; Fri, 1 Jul 2005 14:56:55 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoR77-0004ke-MM for isms@ietf.org; Fri, 01 Jul 2005 15:23:53 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA00632; Fri, 1 Jul 2005 11:56:37 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j61Iub102714; Fri, 1 Jul 2005 11:56:37 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 11:56:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: (D)TLS considered harmful: was Re: [Isms] Coming to consensus Date: Fri, 1 Jul 2005 11:56:32 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC393@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: (D)TLS considered harmful: was Re: [Isms] Coming to consensus Thread-Index: AcV+afnCKnvtauV/Rh+Rqzl8IDRNVQAAB6nQ From: "Fleischman, Eric" To: "Tom Petch" , X-OriginalArrivalTime: 01 Jul 2005 18:56:33.0225 (UTC) FILETIME=[993B9B90:01C57E6E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom, I am sorry that my lazy typing "(D)TLS" was misleading. In the future, I could type DTLS/TLS, if that would be clearer or whatever reference mechanism you prefer. I have no problems with your characterizations of DTLS. I also recognize that its lower maturity means that there are more risks for us to leverage DTLS than there is adopting the mature TLS or SSH alternatives. However, I can't think of a UDP variant with stronger credentials (i.e., it is based upon TLS) and greater promise than DTLS. If anyone can name a better UDP candidate, please do so.=20 However, if it is actually the case that DTLS is the only (or best) alternative enabling ISMS to support SNMP over UDP transports, then the next question for our WG is "how important is the preservation of a transport choice for SNMP?" My own conclusion is that it is important, because SNMP's performance differs as a partial function of its underlying transport, such that each alternative has differing performance behaviors more suited to different environments/uses. I value and leverage this distinction because I work in different environments. Individuals with a more uniform operating environment may perhaps not value this flexibility. That's fine, but, as I argued previously within this WG in regards to authentication infrastructures, I believe that we should enable greater flexibility to the fullest extent that we can because SNMP users operate in so many diverse environments. This is why I recommend an approach that could support both TCP and UDP. --Eric=20 -----Original Message----- From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 Sent: Friday, July 01, 2005 10:22 AM To: Fleischman, Eric; isms@ietf.org Subject: (D)TLS considered harmful: was Re: [Isms] Coming to consensus=20 I think the use of the term (D)TLS somewhat misleading. TLS, reliable transport based, a comprehensive set of I-Ds updating well established RFC, in turn building on extensive experience of the similar but differently named SSL, I regard as a mature standard, worthy of serious consideration for any security issue. DTLS is a single I-D, in the RFC editor queue (thanks for that), expects to achieve reliable transport with 64 bits of extra header. Its pedigree is impeccable but it is untested. Will it fly? will it prove vulnerable to some class of attacks, will it be widely available, will it go on being updated in parallel with TLS? So I see two very different protocols even if in their elements of security they share a common set of methods. To refer to them together as (D)TLS as if were something like FTP which can be configured to run over TCP or UDP I think misleading. Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 14:58:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQj2-0006Qa-Su; Fri, 01 Jul 2005 14:58:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQj1-0006Gq-HS for isms@megatron.ietf.org; Fri, 01 Jul 2005 14:58:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29055 for ; Fri, 1 Jul 2005 14:58:51 -0400 (EDT) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoR92-0004pR-Fz for isms@ietf.org; Fri, 01 Jul 2005 15:25:48 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j61IwPff022697; Fri, 1 Jul 2005 18:58:25 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 j61IwDoS011259; Fri, 1 Jul 2005 18:58:25 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 M2005070111582522553 ; Fri, 01 Jul 2005 11:58:25 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 11:58:25 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 11:58:25 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 14:58:23 -0400 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: (D)TLS considered harmful: was Re: [Isms] Coming to consensus Date: Fri, 1 Jul 2005 14:57:02 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C59290169EE7E@pysmsx401.amr.corp.intel.com> Thread-Topic: (D)TLS considered harmful: was Re: [Isms] Coming to consensus Thread-Index: AcV+aiVV62E9lGqrSJ2e8V6NI0/ZjAAA3fYQ From: "Blumenthal, Uri" To: "Tom Petch" , "Fleischman, Eric" , X-OriginalArrivalTime: 01 Jul 2005 18:58:23.0052 (UTC) FILETIME=[DAB1E0C0:01C57E6E] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Let's get some things straight. 1. TLS is Transport Layer SECURITY (as SSL is SECURE Socket LAYER). It happens to run over reliable transport (because it allows leaving some problems alone that would otherwise have to be addressed), but reliability of the delivery was never a goal of either protocol - just a byproduct. 2. DTLS is TLS adopted to unreliable transport, and thus it deals with the issues that reliable protocol would've shielded from. It never cared and isn't going to "achieve realiable transport". All that transport layer change means - is that DTLS has now to deal with potential message drop and/or reordering. Which it does by adding extra fields. It is misleading to imply something else. P.S. From TLS, SSH and DTLS - DTLS is the most versatile choice for SNMP protocol. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Tom Petch Sent: Friday, July 01, 2005 1:22 PM To: Fleischman, Eric; isms@ietf.org Subject: (D)TLS considered harmful: was Re: [Isms] Coming to consensus=20 I think the use of the term (D)TLS somewhat misleading. TLS, reliable transport based, a comprehensive set of I-Ds updating well established RFC, in turn building on extensive experience of the similar but differently named SSL, I regard as a mature standard, worthy of serious consideration for any security issue. DTLS is a single I-D, in the RFC editor queue (thanks for that), expects to achieve reliable transport with 64 bits of extra header. Its pedigree is impeccable but it is untested. Will it fly? will it prove vulnerable to some class of attacks, will it be widely available, will it go on being updated in parallel with TLS? So I see two very different protocols even if in their elements of security they share a common set of methods. To refer to them together as (D)TLS as if were something like FTP which can be configured to run over TCP or UDP I think misleading. Tom Petch ----- Original Message ----- From: "Fleischman, Eric" To: "Tom Petch" ; Sent: Friday, July 01, 2005 6:29 PM Subject: RE: [Isms] Coming to consensus Tom, The quote you read means that SSH should not operate on top of an unreliable data stream such as UDP but it can operate on top of a reliable data stream such as TCP and probably SCTP. Based on this quote it would seem to me that to select SSH would imply that SNMP must use TCP transports only. If so, then I personally advise against the SSH option because our experience is that SNMP behaves poorly using TCP within bandwidth limited environments. Therefore, I prefer SNMP to be able to use UDP. Therefore, based on this limited information, it appears to me that (D)TLS is a preferable alternative when compared to SSH. --Eric -----Original Message----- From: Tom Petch [mailto:nwnetworks@dial.pipex.com] Sent: Friday, July 01, 2005 12:54 AM >Don't both TLS and SSH require TCP transports while only DTLS can >support UDP? To quote from "draft-ietf-secsh-architecture-22.txt" "The transport layer will typically be run over a TCP/IP connection, but might also be used on top of any other reliable data stream." so SSH does not need everything TCP has to offer, just reliability. (I seem to recall this coming up in other places, that neither UDP nor TCP are right for the upper layers, leading protocol designers to cast around for something that fits better.) _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 15:00:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQkw-0000vj-1x; Fri, 01 Jul 2005 15:00:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQku-0000om-Sx for isms@megatron.ietf.org; Fri, 01 Jul 2005 15:00:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29235 for ; Fri, 1 Jul 2005 15:00:49 -0400 (EDT) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoRAw-00056u-0x for isms@ietf.org; Fri, 01 Jul 2005 15:27:46 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j61J0dff024068; Fri, 1 Jul 2005 19:00:39 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 j61J0NoQ013258; Fri, 1 Jul 2005 19:00:39 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 M2005070112003916737 ; Fri, 01 Jul 2005 12:00:39 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 12:00:39 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 12:00:38 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 15:00:34 -0400 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] Coming to consensus Date: Fri, 1 Jul 2005 14:59:13 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C59290169EE83@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Coming to consensus Thread-Index: AcV+bqUkzCpxqtFbTwWPV6NNx5TvWgAABHbQ From: "Blumenthal, Uri" To: "Donati Andrew-MGIA0477" , , "Fleischman, Eric" , "Tom Petch" , X-OriginalArrivalTime: 01 Jul 2005 19:00:34.0059 (UTC) FILETIME=[28C7F5B0:01C57E6F] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Clearly. If you need a lot of data from a few devices - TCP's the best. If you need a few bits of data from a lot of devices - UDP's your best friend. If you want a lot of data from a lot of devices - heavy hierarchical infrastructure or pistol with one round is your only choice. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Donati Andrew-MGIA0477 Sent: Friday, July 01, 2005 2:56 PM To: ietfdbh@comcast.net; 'Fleischman, Eric'; 'Tom Petch'; isms@ietf.org Subject: RE: [Isms] Coming to consensus=20 Hi, I heard of an observation from someone who noted that SNMP over TCP is not scalable with many devices.=20 However, it would be interesting to hear about experiences using SNMP over TCP in the case where a table is read that contains over a thousand rows of data from one or a few devices. =20 Perhaps the answer would be to use both UDP and TCP. Use TCP to read large tables (from only a few devices at a time) and use UDP for all other cases. Thanks, Andy -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Friday, July 01, 2005 1:03 PM To: 'Fleischman, Eric'; 'Tom Petch'; isms@ietf.org Subject: RE: [Isms] Coming to consensus=20 Hi, > our experience is that SNMP behaves > poorly using TCP within bandwidth limited environments.=20 When you say "our experience", can you qualify "our"? Is that Boeing? IETF? Can you share the research that quantifies this assertion? The debate about TCP or UDP for SNMP has raged for years. I'd be interested in seeing some rigorous research on this. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 15:05:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQp7-0000Zy-LA; Fri, 01 Jul 2005 15:05:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQp5-0000Zt-Qr for isms@megatron.ietf.org; Fri, 01 Jul 2005 15:05:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29755 for ; Fri, 1 Jul 2005 15:05:07 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoRF6-0005j5-4J for isms@ietf.org; Fri, 01 Jul 2005 15:32:05 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 01 Jul 2005 12:04:43 -0700 X-IronPort-AV: i="3.93,251,1115017200"; d="scan'208"; a="646825726:sNHT1639288540" Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j61J4dvN004255; Fri, 1 Jul 2005 12:04:39 -0700 (PDT) Message-Id: <6.2.0.14.0.20050701112745.03d12440@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 01 Jul 2005 12:04:41 -0700 To: "Fleischman, Eric" From: Kaushik Narayan Subject: RE: [Isms] Coming to consensus In-Reply-To: <474EEBD229DF754FB83D256004D021080EC38F@XCH-NW-6V1.nw.nos.b oeing.com> References: <474EEBD229DF754FB83D256004D021080EC38F@XCH-NW-6V1.nw.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Eric, Based on this quote it would seem to me that to select SSH would imply >that SNMP must use TCP transports only. If so, then I personally advise >against the SSH option because our experience is that SNMP behaves >poorly using TCP within bandwidth limited environments. Therefore, I >prefer SNMP to be able to use UDP. I am not sure that SNMPoDTLSoUDP will behave any better that SNMPoTCP within those limited bandwidth environments. regards, kaushik! >Therefore, based on this limited >information, it appears to me that (D)TLS is a preferable alternative >when compared to SSH. > >--Eric > >-----Original Message----- >From: Tom Petch [mailto:nwnetworks@dial.pipex.com] >Sent: Friday, July 01, 2005 12:54 AM > > >Don't both TLS and SSH require TCP transports while only DTLS can > >support UDP? > >To quote from "draft-ietf-secsh-architecture-22.txt" > >"The transport layer will typically be > run over a TCP/IP connection, but might also be used on top of any > other reliable data stream." > >so SSH does not need everything TCP has to offer, just reliability. (I >seem to recall this coming up in other places, that neither UDP nor TCP >are right for the upper layers, leading protocol designers to cast >around for something that fits better.) > > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 15:06:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQpt-0000bV-Hp; Fri, 01 Jul 2005 15:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQps-0000bQ-8h for isms@megatron.ietf.org; Fri, 01 Jul 2005 15:06:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29870 for ; Fri, 1 Jul 2005 15:05:56 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoRFs-0005km-Ml for isms@ietf.org; Fri, 01 Jul 2005 15:32:53 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 6AA7BE0063; Fri, 1 Jul 2005 15:05:58 -0400 (EDT) To: Ken Hornstein Subject: Re: [Isms] Coming to consensus References: <200506302231.j5UMVOOU011505@ginger.cmf.nrl.navy.mil> From: Sam Hartman Date: Fri, 01 Jul 2005 15:05:58 -0400 In-Reply-To: <200506302231.j5UMVOOU011505@ginger.cmf.nrl.navy.mil> (Ken Hornstein's message of "Thu, 30 Jun 2005 18:31:25 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Note that the WG may decide to support more than one protocol. In general you should do this because you believe there are environments where all the protocols you choose are the right fit not because you are unable to get consensus any other way. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 15:14:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQy4-00022j-28; Fri, 01 Jul 2005 15:14:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQy2-0001rf-Ef for isms@megatron.ietf.org; Fri, 01 Jul 2005 15:14:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01136 for ; Fri, 1 Jul 2005 15:14:22 -0400 (EDT) Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoRO1-0006Ai-Bl for isms@ietf.org; Fri, 01 Jul 2005 15:41:19 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) 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 j61JED2S005992; Fri, 1 Jul 2005 19:14:13 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j61JEDoA022198; Fri, 1 Jul 2005 19:14:13 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005070112141217049 ; Fri, 01 Jul 2005 12:14:12 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 12:13:58 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 12:13:58 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 15:13:57 -0400 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] Coming to consensus X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 1 Jul 2005 15:12:36 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C59290169EEA0@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Coming to consensus Thread-Index: AcV+cGjjuB0WdskZRkq4859Ws+qnQQAAA6AQ From: "Blumenthal, Uri" To: "Kaushik Narayan" , "Fleischman, Eric" X-OriginalArrivalTime: 01 Jul 2005 19:13:57.0113 (UTC) FILETIME=[07704690:01C57E71] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>Based on this quote it would seem to me that to select SSH would imply >>that SNMP must use TCP transports only. If so, then I personally advise >>against the SSH option because our experience is that SNMP behaves >>poorly using TCP within bandwidth limited environments. Therefore, I >>prefer SNMP to be able to use UDP. > >I am not sure that SNMPoDTLSoUDP will behave any better that SNMPoTCP >within those limited bandwidth environments. I find this concern ungrounded. DTLS adds considerable overhead during the session establishment phase. After that it's as light-weight, as can be reasonably expected from a protocol that provides ancryption and authentication. So depending on whether DTLS is used when a lot of short-lived sessions are created and destroyed, or when sessions are reasonably long-lived - you'd see it faring better than TCP, or not. >Therefore, based on this limited >information, it appears to me that (D)TLS is a preferable alternative >when compared to SSH. > >--Eric > >-----Original Message----- >From: Tom Petch [mailto:nwnetworks@dial.pipex.com] >Sent: Friday, July 01, 2005 12:54 AM > > >Don't both TLS and SSH require TCP transports while only DTLS can > >support UDP? > >To quote from "draft-ietf-secsh-architecture-22.txt" > >"The transport layer will typically be > run over a TCP/IP connection, but might also be used on top of any > other reliable data stream." > >so SSH does not need everything TCP has to offer, just reliability. (I >seem to recall this coming up in other places, that neither UDP nor TCP >are right for the upper layers, leading protocol designers to cast >around for something that fits better.) > > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 15:17:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoR14-0005oJ-FH; Fri, 01 Jul 2005 15:17:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoR12-0005aY-L5 for isms@megatron.ietf.org; Fri, 01 Jul 2005 15:17:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01555 for ; Fri, 1 Jul 2005 15:17:28 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoRR3-0006nH-QO for isms@ietf.org; Fri, 01 Jul 2005 15:44:26 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA02793; Fri, 1 Jul 2005 12:17:08 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j61JHDv28964; Fri, 1 Jul 2005 14:17:13 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 12:17:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: FW: [Isms] Coming to consensus Date: Fri, 1 Jul 2005 12:17:07 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC395@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] Coming to consensus Thread-Index: AcV+b8mmIluPm3rVTpScKPfr2GSkDAAAQ8ug From: "Fleischman, Eric" To: X-OriginalArrivalTime: 01 Jul 2005 19:17:10.0905 (UTC) FILETIME=[7AF29690:01C57E71] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Eric, We in the ISMS WG are currently considering mechanisms to secure SNMP transports. We are considering DTLS, TLS, SSH and BEEP as possible candidates. I was wondering if you could provide us with insight concerning DTLS behavior. For example, what performance differences might Application X experience by being in a protocol stack with DTLS and UDP when compared to that same application just over UDP? Thanks? --Eric -----Original Message----- From: Kaushik Narayan [mailto:kaushik@cisco.com]=20 Sent: Friday, July 01, 2005 12:05 PM To: Fleischman, Eric Cc: Tom Petch; isms@ietf.org Subject: RE: [Isms] Coming to consensus=20 Hi Eric, Based on this quote it would seem to me that to select SSH would imply >that SNMP must use TCP transports only. If so, then I personally advise >against the SSH option because our experience is that SNMP behaves=20 >poorly using TCP within bandwidth limited environments. Therefore, I=20 >prefer SNMP to be able to use UDP. I am not sure that SNMPoDTLSoUDP will behave any better that SNMPoTCP within those limited bandwidth environments. regards, kaushik! >Therefore, based on this limited >information, it appears to me that (D)TLS is a preferable alternative=20 >when compared to SSH. > >--Eric > >-----Original Message----- >From: Tom Petch [mailto:nwnetworks@dial.pipex.com] >Sent: Friday, July 01, 2005 12:54 AM > > >Don't both TLS and SSH require TCP transports while only DTLS can=20 > >support UDP? > >To quote from "draft-ietf-secsh-architecture-22.txt" > >"The transport layer will typically be > run over a TCP/IP connection, but might also be used on top of any > other reliable data stream." > >so SSH does not need everything TCP has to offer, just reliability. (I >seem to recall this coming up in other places, that neither UDP nor TCP >are right for the upper layers, leading protocol designers to cast=20 >around for something that fits better.) > > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 15:48:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoRUl-0003kJ-5N; Fri, 01 Jul 2005 15:48:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoRUj-0003Z9-Gh for isms@megatron.ietf.org; Fri, 01 Jul 2005 15:48:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05083 for ; Fri, 1 Jul 2005 15:48:09 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoRuk-0001E4-8R for isms@ietf.org; Fri, 01 Jul 2005 16:15:07 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 01 Jul 2005 12:48:04 -0700 Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j61Jm0vN004971; Fri, 1 Jul 2005 12:48:00 -0700 (PDT) Message-Id: <6.2.0.14.0.20050701124509.03d0d9b8@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 01 Jul 2005 12:48:02 -0700 To: "Blumenthal, Uri" From: Kaushik Narayan Subject: RE: [Isms] Coming to consensus In-Reply-To: <3DEC199BD7489643817ECA151F7C59290169EEA0@pysmsx401.amr.cor p.intel.com> References: <3DEC199BD7489643817ECA151F7C59290169EEA0@pysmsx401.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Uri, Please find my reply inline. >I am not sure that SNMPoDTLSoUDP will behave any better that SNMPoTCP > >within those limited bandwidth environments. > >I find this concern ungrounded. > >DTLS adds considerable overhead during the session establishment phase. >After that it's as light-weight, as can be reasonably expected from a >protocol that provides ancryption and authentication. So depending on >whether DTLS is used when a lot of short-lived sessions are created and >destroyed, or when sessions are reasonably long-lived - you'd see it >faring better than TCP, or not. That session establishment is what I am concerned about, I think the assumption is that we would have long lived sessions between managers and agents to reduce the initial session establishment cost. That could be problematic since a single manager might be communicating with 10,000 agents on behalf of several users. That's a lot of state that needs to be maintained on the manager. regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 15:58:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoReO-0006iS-4J; Fri, 01 Jul 2005 15:58:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoReM-0006bk-UW for isms@megatron.ietf.org; Fri, 01 Jul 2005 15:58:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07804 for ; Fri, 1 Jul 2005 15:58:08 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoS4G-0002nk-BL for isms@ietf.org; Fri, 01 Jul 2005 16:25:05 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j61JvtZC007692 for ; Fri, 1 Jul 2005 15:57:55 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 01 Jul 2005 15:57:56 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 01 Jul 2005 15:57:56 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Jul 2005 15:57:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Coming to consensus Date: Fri, 1 Jul 2005 15:57:54 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010323E6@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Coming to consensus Thread-Index: AcV+djuyAqBEod/FThOTThrOBW5vSQAAGnGg From: "Nelson, David" To: X-OriginalArrivalTime: 01 Jul 2005 19:57:56.0210 (UTC) FILETIME=[2C768520:01C57E77] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:99.7895 P:95.9108 R:95.9108 S:62.3200 ) 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: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Kaushik Narayan writes... > That's a lot of state that needs to be maintained on the manager. Perhaps, but managers are typically highly capable workstations, with fast CPUs, a large amount of RAM and an even larger amount of disk-resident virtual memory, swap files and page files. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 16:28:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoS7b-0003eq-Um; Fri, 01 Jul 2005 16:28:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoS7Z-0003PF-Mw for isms@megatron.ietf.org; Fri, 01 Jul 2005 16:28:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18625 for ; Fri, 1 Jul 2005 16:28:19 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoSXY-0000ga-Ij for isms@ietf.org; Fri, 01 Jul 2005 16:55:15 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 01 Jul 2005 13:28:09 -0700 Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j61KS66q009794; Fri, 1 Jul 2005 13:28:07 -0700 (PDT) Message-Id: <6.2.0.14.0.20050701131946.03d1b758@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 01 Jul 2005 13:28:05 -0700 To: "Nelson, David" From: Kaushik Narayan Subject: RE: [Isms] Coming to consensus In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010323E6@MAANDMBX2.ets.ent erasys.com> References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010323E6@MAANDMBX2.ets.enterasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [171.69.75.224] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > > That's a lot of state that needs to be maintained on the manager. > >Perhaps, but managers are typically highly capable workstations, with >fast CPUs, a large amount of RAM and an even larger amount of >disk-resident virtual memory, swap files and page files. Sure enough but there are limits to that. In the past, when tried to do SNMPoIPSec, the managers (a workstation with a 1 Gig of RAM) couldn't handle more than 20/30 tunnels and we had to recommend running IPSec from the first hop router and this was stations just doing SNMP with devices. I am not saying that we will have exactly the same number with TLS but I am not sure we will be able to do ten thousand TLS sessions. regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 16:57:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoSZk-0000Ix-If; Fri, 01 Jul 2005 16:57:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoSZg-000074-8W for isms@megatron.ietf.org; Fri, 01 Jul 2005 16:57:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21409 for ; Fri, 1 Jul 2005 16:57:21 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoSzg-0003yB-IU for isms@ietf.org; Fri, 01 Jul 2005 17:24:18 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 01 Jul 2005 13:57:13 -0700 X-IronPort-AV: i="3.93,251,1115017200"; d="scan'208"; a="195948226:sNHT24669952" Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j61Kv9oe028498; Fri, 1 Jul 2005 13:57:09 -0700 (PDT) Message-Id: <6.2.0.14.0.20050701133032.03d1afa8@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 01 Jul 2005 13:57:12 -0700 To: "Blumenthal, Uri" From: Kaushik Narayan Subject: RE: [Isms] Coming to consensus In-Reply-To: <3DEC199BD7489643817ECA151F7C59290169EF1E@pysmsx401.amr.cor p.intel.com> References: <3DEC199BD7489643817ECA151F7C59290169EF1E@pysmsx401.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Uri, I am just stating that 1. Since we have already chose to go down the path of using an encapsulated keying scheme for SNMPv3 security, we MUST not get too hung up on SNMPoUDP. I think if there are applications for SNMPoUDP, then they mostly like will use SNMPv3 USM. 2. We can definitely ease some of the "session establishment" pain by making sure that we cross leverage across management protocols since the managed end-points are the same. To that extent use of BEEP is interesting since it can allow us to potentially share the BEEP session (and the underlying TLS session) between NetConf, SNMPv3 and Syslog. regards, kaushik! At 01:22 PM 7/1/2005, Blumenthal, Uri wrote: > >>......So depending on > >>whether DTLS is used when a lot of short-lived sessions are created >and > >>destroyed, or when sessions are reasonably long-lived - you'd see it > >>faring better than TCP, or not. > > > >That session establishment is what I am concerned about, I think the > >assumption is that we would have long lived sessions between managers > >and agents to reduce the initial session establishment cost. That could > >be problematic since a single manager might be communicating with > >10,000 agents on behalf of several users. > > > >That's a lot of state that needs to be maintained on the manager. > >In some foreign language there's a saying about an irreconcilable >contradiction of the desire to both have sex and preserve the virginity. >Obviously, something has to give. > >People cannot use session-oriented protocols (with session establishment >cost) in the same way as "pure" UDP-based ones - with impunity. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 17:39:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoTDz-0004z5-0P; Fri, 01 Jul 2005 17:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoTDw-0004lq-Pd for isms@megatron.ietf.org; Fri, 01 Jul 2005 17:39:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25620 for ; Fri, 1 Jul 2005 17:38:57 -0400 (EDT) Received: from fmr16.intel.com ([192.55.52.70] helo=fmsfmr006.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoTdx-00006J-V4 for isms@ietf.org; Fri, 01 Jul 2005 18:05:55 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j61Lcnbm002345; Fri, 1 Jul 2005 21:38:49 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 j61LcloE024929; Fri, 1 Jul 2005 21:38:49 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 M2005070114384920089 ; Fri, 01 Jul 2005 14:38:49 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 14:38:49 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 14:38:49 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 17:38:47 -0400 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] Coming to consensus Date: Fri, 1 Jul 2005 17:37:26 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C59290169EF84@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Coming to consensus Thread-Index: AcV+f3cnc+L7HWsQQ3iybEVlmmQjogABTzPQ From: "Blumenthal, Uri" To: "Kaushik Narayan" X-OriginalArrivalTime: 01 Jul 2005 21:38:47.0736 (UTC) FILETIME=[43741B80:01C57E85] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > I am just stating that > > 1. Since we have already chose to go down the path of using an > encapsulated keying scheme for SNMPv3 security, we MUST not > get too hung up on SNMPoUDP. I do not see the logic of this. I.e. the conclusion doesn't follow... > I think if there are applications for > SNMPoUDP, then they mostly like will use SNMPv3 USM. I do not think this opinion has been accepted. > 2. We can definitely ease some of the "session establishment" pain > by making sure that we cross leverage across management protocols > since the managed end-points are the same. To that extent use of BEEP > is interesting since it can allow us to potentially share the BEEP session > (and the underlying TLS session) between NetConf, SNMPv3 and Syslog. Hmm, fine... If that's the road the WG wants to follow. At 01:22 PM 7/1/2005, Blumenthal, Uri wrote: > >>......So depending on > >>whether DTLS is used when a lot of short-lived sessions are created >and > >>destroyed, or when sessions are reasonably long-lived - you'd see it > >>faring better than TCP, or not. > > > >That session establishment is what I am concerned about, I think the > >assumption is that we would have long lived sessions between managers > >and agents to reduce the initial session establishment cost. That could > >be problematic since a single manager might be communicating with > >10,000 agents on behalf of several users. > > > >That's a lot of state that needs to be maintained on the manager. > >In some foreign language there's a saying about an irreconcilable >contradiction of the desire to both have sex and preserve the virginity. >Obviously, something has to give. > >People cannot use session-oriented protocols (with session establishment >cost) in the same way as "pure" UDP-based ones - with impunity. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 01 21:40:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoX04-0002V1-BB; Fri, 01 Jul 2005 21:40:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoX02-0002Ok-1f for isms@megatron.ietf.org; Fri, 01 Jul 2005 21:40:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20189 for ; Fri, 1 Jul 2005 21:40:49 -0400 (EDT) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoXQ5-0003po-EA for isms@ietf.org; Fri, 01 Jul 2005 22:07:51 -0400 Received: by romeo.rtfm.com (Postfix, from userid 1001) id D9ECB17058; Fri, 1 Jul 2005 18:53:02 -0700 (PDT) To: "Fleischman, Eric" Subject: Re: FW: [Isms] Coming to consensus References: <474EEBD229DF754FB83D256004D021080EC395@XCH-NW-6V1.nw.nos.boeing.com> From: Eric Rescorla Date: Fri, 01 Jul 2005 18:53:02 -0700 In-Reply-To: <474EEBD229DF754FB83D256004D021080EC395@XCH-NW-6V1.nw.nos.boeing.com> (Eric Fleischman's message of "Fri, 1 Jul 2005 12:17:07 -0700") Message-ID: <86mzp6as8x.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: 02ec665d00de228c50c93ed6b5e4fc1a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org "Fleischman, Eric" writes: > We in the ISMS WG are currently considering mechanisms to secure SNMP > transports. We are considering DTLS, TLS, SSH and BEEP as possible > candidates. I was wondering if you could provide us with insight > concerning DTLS behavior. For example, what performance differences > might Application X experience by being in a protocol stack with DTLS > and UDP when compared to that same application just over UDP? Thanks? Sure... There are two kinds of overhead to consider: initial connection setup and ongoing dataflow. DTLS's connection setup is similar to that of TLS. The initial handshake takes 2 or 3 RTTs (depending on if the server uses the anti-DoS HelloVerifyRequest mechanism). From a computational perspective, DTLS's overhead is the same as TLS: in the standard RSA mode the server has to perform one RSA private operation (slowish) and the client has to perform a fast one. As with TLS there are modes in which both sides have higher performance costs (e.g., ephemeral keying) and lower (e.g., pre-shared keying). Overall, connection setup costs in TLS/DTLS are pretty similar to those in e.g., SSH. DTLS's per-packet space overhead is on the order of 30-55 octets per packet: - 4 octets for header - 8 octets for sequence number - 8-16 octets for initialization vector (DTLS currently only supports CBC mode) - 10-20 octets for the MAC (10 if you use truncated MACs, 20 if you use full HMAC-SHA1) - 1-16 bytes of padding (depending on message alignment) The overhead of DTLS is 8 bytes longer than the overhead of TLS 1.1 due to the explicit sequence number required to allow out-of-order delivery. There is of course computational overhead associated with enciphering the records. However, this overhead is typically small compared to the speed of modern computers. A fast server should be able to do gig-speed DTLS/TLS. Obviously, if you have a slow device you won't be able to go as fast, but it's pretty common to see TLS in low-powered devices such as Palms and phones so I don't expect this to be a big problem. In any case, these costs are inherent in the encrypting and MACing process so as long as to secure the traffic you need to pay them whatever protocol you chooce. best, -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jul 02 01:59:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dob2E-0004TG-TR; Sat, 02 Jul 2005 01:59:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dob2A-0004PB-TJ for isms@megatron.ietf.org; Sat, 02 Jul 2005 01:59:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13530 for ; Sat, 2 Jul 2005 01:59:21 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DobSG-0004ku-9s for isms@ietf.org; Sat, 02 Jul 2005 02:26:21 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j625wRLb002847; Fri, 1 Jul 2005 22:58:27 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j625wNQx019809; Fri, 1 Jul 2005 22:58:23 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j625wMu2019803; Fri, 1 Jul 2005 22:58:23 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 1 Jul 2005 22:58:22 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Eric Rescorla Subject: Re: FW: [Isms] Coming to consensus In-Reply-To: <86mzp6as8x.fsf@romeo.rtfm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, I would say that the question to ask is the 1) CPU 2) space of SNMPv3/USM vs SNMPv3/new_security_model over DTLS (v3oDTLS) After the session setup, I would guess that the computation cost of v3oDTLS vs SNMPv3/USM would be the memcopy of the SNMP message. The message space difference between v3oDTLS vs SNMPv3/USM is a little harder, since the IV and HMAC would be "the same", but the rest of the fields in v3oDTLS would be compared to the values of msgAuthoritativeEngineID (5-20 octets long), msgAuthoritativeEngineBoots INTEGER (0..2147483647), msgAuthoritativeEngineTime INTEGER (0..2147483647), msgUserName (0-32 octets long). Thus, using DTLS, the SNMP messages could be bigger, depending on the size of the engineID and user name! Note that for each DTLS session, there is space info that must be saved by each side. It takes some space too. (But not that much.) Regards, /david t. perkins On Fri, 1 Jul 2005, Eric Rescorla wrote: > "Fleischman, Eric" writes: > > We in the ISMS WG are currently considering mechanisms to secure SNMP > > transports. We are considering DTLS, TLS, SSH and BEEP as possible > > candidates. I was wondering if you could provide us with insight > > concerning DTLS behavior. For example, what performance differences > > might Application X experience by being in a protocol stack with DTLS > > and UDP when compared to that same application just over UDP? Thanks? > > Sure... > > There are two kinds of overhead to consider: initial connection > setup and ongoing dataflow. > > DTLS's connection setup is similar to that of TLS. The initial > handshake takes 2 or 3 RTTs (depending on if the server uses > the anti-DoS HelloVerifyRequest mechanism). From a computational > perspective, DTLS's overhead is the same as TLS: in the > standard RSA mode the server has to perform one RSA private > operation (slowish) and the client has to perform a fast one. > As with TLS there are modes in which both sides have higher > performance costs (e.g., ephemeral keying) and lower (e.g., > pre-shared keying). Overall, connection setup costs in TLS/DTLS > are pretty similar to those in e.g., SSH. > > DTLS's per-packet space overhead is on the order of 30-55 octets > per packet: > > - 4 octets for header > - 8 octets for sequence number > - 8-16 octets for initialization vector (DTLS currently only > supports CBC mode) > - 10-20 octets for the MAC (10 if you use truncated MACs, > 20 if you use full HMAC-SHA1) > - 1-16 bytes of padding (depending on message alignment) > > The overhead of DTLS is 8 bytes longer than the overhead of TLS 1.1 > due to the explicit sequence number required to allow out-of-order > delivery. > > There is of course computational overhead associated with enciphering > the records. However, this overhead is typically small compared to > the speed of modern computers. A fast server should be able to > do gig-speed DTLS/TLS. Obviously, if you have a slow device > you won't be able to go as fast, but it's pretty common to see > TLS in low-powered devices such as Palms and phones so I don't > expect this to be a big problem. In any case, these costs > are inherent in the encrypting and MACing process so as long as > to secure the traffic you need to pay them whatever protocol > you chooce. > > best, > -Ekr > > > > > > > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jul 02 02:14:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DobGX-0004PD-LF; Sat, 02 Jul 2005 02:14:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DobGV-0004OT-QZ for isms@megatron.ietf.org; Sat, 02 Jul 2005 02:14:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27770 for ; Sat, 2 Jul 2005 02:14:10 -0400 (EDT) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dobgb-0005Uq-Ic for isms@ietf.org; Sat, 02 Jul 2005 02:41:11 -0400 Received: by romeo.rtfm.com (Postfix, from userid 1001) id C970717071; Fri, 1 Jul 2005 23:26:20 -0700 (PDT) To: "David T. Perkins" Subject: Re: FW: [Isms] Coming to consensus References: From: Eric Rescorla Date: Fri, 01 Jul 2005 23:26:20 -0700 In-Reply-To: (David T. Perkins's message of "Fri, 1 Jul 2005 22:58:22 -0700 (PDT)") Message-ID: <86irztbu5v.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: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org "David T. Perkins" writes: > I would say that the question to ask is the > 1) CPU > 2) space > of SNMPv3/USM vs SNMPv3/new_security_model over DTLS (v3oDTLS) > > After the session setup, I would guess that the computation > cost of v3oDTLS vs SNMPv3/USM would be the memcopy of the SNMP > message. In most of these systems the cost of the cryptography dominates the cost of the memcpy. > The message space difference between v3oDTLS vs > SNMPv3/USM is a little harder, since the IV and HMAC would > be "the same", but the rest of the fields in v3oDTLS would > be compared to the values of msgAuthoritativeEngineID > (5-20 octets long), msgAuthoritativeEngineBoots > INTEGER (0..2147483647), msgAuthoritativeEngineTime > INTEGER (0..2147483647), msgUserName (0-32 octets long). > Thus, using DTLS, the SNMP messages could be bigger, > depending on the size of the engineID and user name! So, the rest of the fields are: Header (5 bytes) Sequence number (8 bytes) Block padding (1-16 bytes) The only one of these that's unique to DTLS is the header. If you're going to have an anti-replay facility you need a sequence number--though you could get away with one smaller than 8 bytes. If you're going to use CBC mode then you need block padding. This is a function of the crypto, not DTLS. Though Note, however, that if the extra overhead from the padding is really significant, then it would be wise to use Counter mode rather than CBC, whatever the session encryption protocol you're using. TLS/DTLS don't define one but it would be easy to do so modelled on the IPsec Counter mode. I would imagine that it would be similarly easy to do so if one went the USM route. > Note that for each DTLS session, there is space info > that must be saved by each side. It takes some space > too. (But not that much.) Well, for DTLS (or TLS or SSH, for that matter) you need to store the sequence number and cipher and HMAC key schedules on each side. But this is just the minimum requirement to have a session-based cryptographic protocol. There shouldn't be much real difference between any of the likely candidates here. Best, -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jul 02 02:22:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DobOU-0000rn-7i; Sat, 02 Jul 2005 02:22:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DobOS-0000ri-8s for isms@megatron.ietf.org; Sat, 02 Jul 2005 02:22:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05639 for ; Sat, 2 Jul 2005 02:22:22 -0400 (EDT) Received: from i9b05.i.pppool.de ([85.73.155.5] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoboY-0005sJ-NZ for isms@ietf.org; Sat, 02 Jul 2005 02:49:23 -0400 Received: by boskop.local (Postfix, from userid 501) id 673B635482B; Sat, 2 Jul 2005 08:22:03 +0200 (CEST) Date: Sat, 2 Jul 2005 08:22:03 +0200 From: Juergen Schoenwaelder To: Eric Rescorla Subject: Re: FW: [Isms] Coming to consensus Message-ID: <20050702062203.GA1579@boskop.local> Mail-Followup-To: Eric Rescorla , "David T. Perkins" , isms@ietf.org References: <86irztbu5v.fsf@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86irztbu5v.fsf@romeo.rtfm.com> User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Fri, Jul 01, 2005 at 11:26:20PM -0700, Eric Rescorla wrote: > If you're going to have an anti-replay facility you need a sequence > number--though you could get away with one smaller than 8 bytes. USM does not use sequence numbers. USM uses loosely synchronized clocks and allows replay within a time window. This has the effect that a lost SNMP message does not block subsequent messages from getting processed while the manager times out and retransmits the lost message. Am I correct that this will be different with DTLS? Does DTLS enforce that messages are delivered in sequence, much as TCP does? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jul 02 02:56:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dobvo-0002lT-BP; Sat, 02 Jul 2005 02:56:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dobvl-0002hX-Ne for isms@megatron.ietf.org; Sat, 02 Jul 2005 02:56:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12417 for ; Sat, 2 Jul 2005 02:56:48 -0400 (EDT) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DocLt-0007EF-3g for isms@ietf.org; Sat, 02 Jul 2005 03:23:49 -0400 Received: by romeo.rtfm.com (Postfix, from userid 1001) id BFD8017058; Sat, 2 Jul 2005 00:09:00 -0700 (PDT) To: "David T. Perkins" Subject: Re: FW: [Isms] Coming to consensus References: <86irztbu5v.fsf@romeo.rtfm.com> <20050702062203.GA1579@boskop.local> From: Eric Rescorla Date: Sat, 02 Jul 2005 00:09:00 -0700 In-Reply-To: <20050702062203.GA1579@boskop.local> (Juergen Schoenwaelder's message of "Sat, 2 Jul 2005 08:22:03 +0200") Message-ID: <86d5q1bs6r.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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen Schoenwaelder writes: > On Fri, Jul 01, 2005 at 11:26:20PM -0700, Eric Rescorla wrote: > >> If you're going to have an anti-replay facility you need a sequence >> number--though you could get away with one smaller than 8 bytes. > > USM does not use sequence numbers. USM uses loosely synchronized clocks > and allows replay within a time window. This has the effect that a lost > SNMP message does not block subsequent messages from getting processed > while the manager times out and retransmits the lost message. Am I > correct that this will be different with DTLS? Does DTLS enforce that > messages are delivered in sequence, much as TCP does? No, it doesn't. DTLS messages have sequence numbers which allow the recipients to suppress duplicate records, the same way that IPsec does. However, data is delivered to the application in the order received, so there's no head of line blocking. -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jul 02 05:13:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Doe4G-0002Zy-Ar; Sat, 02 Jul 2005 05:13:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Doe4E-0002Vg-DS for isms@megatron.ietf.org; Sat, 02 Jul 2005 05:13:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24006 for ; Sat, 2 Jul 2005 05:13:39 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoeUM-0001kd-Hm for isms@ietf.org; Sat, 02 Jul 2005 05:40:42 -0400 Received: from pc6 (1Cust235.tnt105.lnd4.gbr.da.uu.net [213.116.58.235]) by blaster.systems.pipex.net (Postfix) with SMTP id C450FE000098; Sat, 2 Jul 2005 10:13:22 +0100 (BST) Message-ID: <00f401c57edd$dce08120$0601a8c0@pc6> From: "Tom Petch" To: "Fleischman, Eric" , References: <474EEBD229DF754FB83D256004D021080EC393@XCH-NW-6V1.nw.nos.boeing.com> Subject: Re: (D)TLS considered harmful: was Re: [Isms] Coming to consensus Date: Sat, 2 Jul 2005 09:37:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org No problem; yes, I would prefer DTLS/TLS as a reference to the two jointly. I sense a disagreement with you over the UDP/TCP question (which, unfortunately but inevitably, is bound up with the TLS, DTLS, SSH etc question). I agree that it would be nice if there were a choice of running SNMP over TCP or UDP but in practice, I don't see that choice in the marketplace (in the way I do for eg ftp). The port numbers are allocated but I don't see the products. Hence my question to Juergen. And I see confirmation of this in the fact that the RFC is Experimental. I believe it would need to be Standards Track for the work of isms to progress and that too raises issues of its availability Tom Petch ----- Original Message ----- From: "Fleischman, Eric" To: "Tom Petch" ; Sent: Friday, July 01, 2005 8:56 PM Subject: RE: (D)TLS considered harmful: was Re: [Isms] Coming to consensus Tom, I am sorry that my lazy typing "(D)TLS" was misleading. In the future, I could type DTLS/TLS, if that would be clearer or whatever reference mechanism you prefer. I have no problems with your characterizations of DTLS. I also recognize that its lower maturity means that there are more risks for us to leverage DTLS than there is adopting the mature TLS or SSH alternatives. However, I can't think of a UDP variant with stronger credentials (i.e., it is based upon TLS) and greater promise than DTLS. If anyone can name a better UDP candidate, please do so. However, if it is actually the case that DTLS is the only (or best) alternative enabling ISMS to support SNMP over UDP transports, then the next question for our WG is "how important is the preservation of a transport choice for SNMP?" My own conclusion is that it is important, because SNMP's performance differs as a partial function of its underlying transport, such that each alternative has differing performance behaviors more suited to different environments/uses. I value and leverage this distinction because I work in different environments. Individuals with a more uniform operating environment may perhaps not value this flexibility. That's fine, but, as I argued previously within this WG in regards to authentication infrastructures, I believe that we should enable greater flexibility to the fullest extent that we can because SNMP users operate in so many diverse environments. This is why I recommend an approach that could support both TCP and UDP. --Eric -----Original Message----- From: Tom Petch [mailto:nwnetworks@dial.pipex.com] Sent: Friday, July 01, 2005 10:22 AM To: Fleischman, Eric; isms@ietf.org Subject: (D)TLS considered harmful: was Re: [Isms] Coming to consensus I think the use of the term (D)TLS somewhat misleading. TLS, reliable transport based, a comprehensive set of I-Ds updating well established RFC, in turn building on extensive experience of the similar but differently named SSL, I regard as a mature standard, worthy of serious consideration for any security issue. DTLS is a single I-D, in the RFC editor queue (thanks for that), expects to achieve reliable transport with 64 bits of extra header. Its pedigree is impeccable but it is untested. Will it fly? will it prove vulnerable to some class of attacks, will it be widely available, will it go on being updated in parallel with TLS? So I see two very different protocols even if in their elements of security they share a common set of methods. To refer to them together as (D)TLS as if were something like FTP which can be configured to run over TCP or UDP I think misleading. Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jul 02 14:29:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Domjj-0008Ho-2Z; Sat, 02 Jul 2005 14:29:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Domjh-0008Hi-6z for isms@megatron.ietf.org; Sat, 02 Jul 2005 14:29:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15336 for ; Sat, 2 Jul 2005 14:29:03 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Don9t-0005RA-MG for isms@ietf.org; Sat, 02 Jul 2005 14:56:11 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j62ISsLb030113; Sat, 2 Jul 2005 11:28:54 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j62ISgx4021208; Sat, 2 Jul 2005 11:28:42 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j62ISaXm021190; Sat, 2 Jul 2005 11:28:36 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Sat, 2 Jul 2005 11:28:36 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Juergen Schoenwaelder Subject: Re: FW: [Isms] Coming to consensus In-Reply-To: <20050702062203.GA1579@boskop.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, THis is an interesting question.... When using DTLS, a manager sends a request message, but doesn't get back a response message. This could be due to 1) the request was not received (dropped by the net) 2) the response was not received (dropped by the net) 3) the agent has gone away (or rebooted) What does the manager do after the application level time out? 1) resend the original UDP packet 2) resend the original SNMP message as a new DTLS packet 3) bump the v3 sequence number in the message and send a new DTLS packet On Sat, 2 Jul 2005, Juergen Schoenwaelder wrote: > On Fri, Jul 01, 2005 at 11:26:20PM -0700, Eric Rescorla wrote: > > > If you're going to have an anti-replay facility you need a sequence > > number--though you could get away with one smaller than 8 bytes. > > USM does not use sequence numbers. USM uses loosely synchronized clocks > and allows replay within a time window. This has the effect that a lost > SNMP message does not block subsequent messages from getting processed > while the manager times out and retransmits the lost message. Am I > correct that this will be different with DTLS? Does DTLS enforce that > messages are delivered in sequence, much as TCP does? Note - the USM "loosely sync'ed clocks" provides both delay detection and reply detection. DTLS sequence numbers (I believe) provides replay detection. Does it provide delay detection, and if not, is this important? Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jul 02 16:55:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dop1U-0005Za-AR; Sat, 02 Jul 2005 16:55:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dop1S-0005X1-Dc for isms@megatron.ietf.org; Sat, 02 Jul 2005 16:55:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28855 for ; Sat, 2 Jul 2005 16:55:31 -0400 (EDT) Received: from ib3b1.i.pppool.de ([85.73.179.177] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DopRf-0004hH-VA for isms@ietf.org; Sat, 02 Jul 2005 17:22:41 -0400 Received: by boskop.local (Postfix, from userid 501) id 11A3B354952; Sat, 2 Jul 2005 22:55:12 +0200 (CEST) Date: Sat, 2 Jul 2005 22:55:12 +0200 From: Juergen Schoenwaelder To: Tom Petch Subject: Re: (D)TLS considered harmful: was Re: [Isms] Coming to consensus Message-ID: <20050702205512.GB1687@boskop.local> Mail-Followup-To: Tom Petch , "Fleischman, Eric" , isms@ietf.org References: <474EEBD229DF754FB83D256004D021080EC393@XCH-NW-6V1.nw.nos.boeing.com> <00f401c57edd$dce08120$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00f401c57edd$dce08120$0601a8c0@pc6> User-Agent: Mutt/1.5.8i 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: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Sat, Jul 02, 2005 at 09:37:04AM +0200, Tom Petch wrote: > And I see confirmation of this in the fact that the RFC is Experimental. I > believe it would need to be Standards Track for the work of isms to progress > and that too raises issues of its availability SNMP over TCP is SNMP over TCP. If someone specifies SNMP over SSH (or TLS) then this is SNMP over SSH (or TLS). I don't think you need SNMP over TCP to specify and implement SNMP over SSH (or TLS). /js P.S. Looking at the boxes I have access to, many do ssh. Some do TLS and none of them does DTLS or BEEP. (At least not that I am aware of this. Perhaps I am having the wrong boxes. ;-) -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jul 03 04:51:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp0Cc-0002J2-JT; Sun, 03 Jul 2005 04:51:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp0Cb-0002Ix-82 for isms@megatron.ietf.org; Sun, 03 Jul 2005 04:51:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22542 for ; Sun, 3 Jul 2005 04:51:47 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dp0cu-0003En-VH for isms@ietf.org; Sun, 03 Jul 2005 05:19:02 -0400 Received: from pc6 (1Cust98.tnt5.lnd4.gbr.da.uu.net [62.188.134.98]) by blaster.systems.pipex.net (Postfix) with SMTP id B9723E00004C; Sun, 3 Jul 2005 09:51:26 +0100 (BST) Message-ID: <003d01c57fa3$f5e74b60$0601a8c0@pc6> From: "Tom Petch" To: References: <474EEBD229DF754FB83D256004D021080EC393@XCH-NW-6V1.nw.nos.boeing.com> <00f401c57edd$dce08120$0601a8c0@pc6> <20050702205512.GB1687@boskop.local> Subject: Re: (D)TLS considered harmful: was Re: [Isms] Coming to consensus Date: Sun, 3 Jul 2005 09:49:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.2 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Tom Petch" Cc: "Fleischman, Eric" ; Sent: Saturday, July 02, 2005 10:55 PM Subject: Re: (D)TLS considered harmful: was Re: [Isms] Coming to consensus > On Sat, Jul 02, 2005 at 09:37:04AM +0200, Tom Petch wrote: > > > And I see confirmation of this in the fact that the RFC is Experimental. I > > believe it would need to be Standards Track for the work of isms to progress > > and that too raises issues of its availability > > SNMP over TCP is SNMP over TCP. If someone specifies SNMP over SSH (or TLS) > then this is SNMP over SSH (or TLS). I don't think you need SNMP over TCP > to specify and implement SNMP over SSH (or TLS). > Yeeeeees, I agree ... in protocol stack terms. But turning to the SSH I-D I quoted earlier, SSH needs a reliable transport. I did not say reliable equals TCP at that time, Eric was rather stronger in support of that. But if I have a choice of existing transports, and the RFC allow me the choice of TCP, UDP, Ethernet, OSI, IPX, Appletalk then I am likely to choose TCP for reliability. I then believe SNMP runs over SSH which runs over TCP which, I believe, needs a standards track document. Or do you see an isms I-D specifying both how SNMP maps onto SSH as a subsystem and the implications thereon of using TCP (currently only specified in your RFC)? Or do you see unsecured SNMP running over raw UDP while secured runs over SSH over TCP with no need for any specification about TCP? Or do you see UDP as reliable enough for SSH (seriously)? I cast this in terms of SSH but the questions are much the same with s/SSH/TLS/ > /js > > P.S. Looking at the boxes I have access to, many do ssh. Some do TLS and > none of them does DTLS or BEEP. (At least not that I am aware of this. > Perhaps I am having the wrong boxes. ;-) I find this information very helpful; it reinforces my more limited experience. > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jul 03 06:39:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp1sh-0002wn-Ek; Sun, 03 Jul 2005 06:39:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp1se-0002sv-IO for isms@megatron.ietf.org; Sun, 03 Jul 2005 06:39:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07196 for ; Sun, 3 Jul 2005 06:39:18 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dp2Iz-0004P0-LF for isms@ietf.org; Sun, 03 Jul 2005 07:06:34 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 03 Jul 2005 03:39:10 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j63Ad5od024593; Sun, 3 Jul 2005 03:39:05 -0700 (PDT) Received: from [212.254.247.3] (ams-clip-vpn-dhcp4171.cisco.com [10.61.80.74]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j63AcNnK019946; Sun, 3 Jul 2005 03:38:25 -0700 Message-ID: <42C7C048.8020902@cisco.com> Date: Sun, 03 Jul 2005 12:39:04 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0+ (Macintosh/20050531) MIME-Version: 1.0 To: Tom Petch , "Fleischman, Eric" , isms@ietf.org Subject: Re: (D)TLS considered harmful: was Re: [Isms] Coming to consensus References: <474EEBD229DF754FB83D256004D021080EC393@XCH-NW-6V1.nw.nos.boeing.com> <00f401c57edd$dce08120$0601a8c0@pc6> <20050702205512.GB1687@boskop.local> In-Reply-To: <20050702205512.GB1687@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1120387106.109908"; x:"432200"; a:"rsa-sha1"; b:"nofws:420"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"MEZ6HnEwYQlV1Qchj/cvKh6pNcS0gC1sOo8hIZ0y8RXKG3qKPJB8VVmbx9g774esRSpD6VHK" "GooyJRAUlFXpYvaQBkrSvIfaPrQVpTLSVKbjclGCnYtuoY5tnOJbnvuIJ8kK2lcCE4QrMzzj7q/" "WEW1HXDSCkJ9fHV0AfC/nHL8="; c:"Date: Sun, 03 Jul 2005 12:39:04 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: (D)TLS considered harmful: was Re: [Isms] Coming to con" "sensus" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen Schoenwaelder wrote: > P.S. Looking at the boxes I have access to, many do ssh. Some do TLS and > none of them does DTLS or BEEP. (At least not that I am aware of this. > Perhaps I am having the wrong boxes. ;-) This is a fair point, but it is not the only consideration. The flexibility we need today, pragmatically speaking, is for a way for either side to initiate queries through NATs, firewalls, and associated gook. You *could* implement this flexibility in SSH, but nobody has, so far as I know. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jul 03 11:26:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp6Mm-0005QJ-Rk; Sun, 03 Jul 2005 11:26:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp6Ml-0005QB-MQ for isms@megatron.ietf.org; Sun, 03 Jul 2005 11:26:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09057 for ; Sun, 3 Jul 2005 11:26:41 -0400 (EDT) Received: from i9063.i.pppool.de ([85.73.144.99] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dp6n9-0007R9-8m for isms@ietf.org; Sun, 03 Jul 2005 11:54:00 -0400 Received: by boskop.local (Postfix, from userid 501) id 67303355D45; Sun, 3 Jul 2005 17:26:25 +0200 (CEST) Date: Sun, 3 Jul 2005 17:26:24 +0200 From: Juergen Schoenwaelder To: Tom Petch Subject: Re: (D)TLS considered harmful: was Re: [Isms] Coming to consensus Message-ID: <20050703152624.GA2923@boskop.local> Mail-Followup-To: Tom Petch , "Fleischman, Eric" , isms@ietf.org References: <474EEBD229DF754FB83D256004D021080EC393@XCH-NW-6V1.nw.nos.boeing.com> <00f401c57edd$dce08120$0601a8c0@pc6> <20050702205512.GB1687@boskop.local> <003d01c57fa3$f5e74b60$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003d01c57fa3$f5e74b60$0601a8c0@pc6> User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Sun, Jul 03, 2005 at 09:49:47AM +0200, Tom Petch wrote: > I then believe SNMP runs over > SSH which runs over TCP which, I believe, needs a standards track document. SNMP over SSH would need a standards-track document - SSH usually runs over TCP - this may be mentioned in such an SNMP over SSH document but this is not the same as SNMP over TCP. > Or do you see an isms I-D specifying both how SNMP maps onto SSH as a > subsystem and the implications thereon of using TCP (currently only > specified in your RFC)? The SNMP over TCP RFC defines things such as port numbers to use, minimum required max message size, how the serialization and framing is done and so one. Some of this might apply to SNMP over SSH while other things do not. An example: SNMP over TCP says how SNMP messages are serialized and how the framing on a TCP connection works. This clearly does not apply to SNMP over SSH since SSH does the framing in a quite different way. The holds true if you s/SSH/TLS. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jul 03 15:35:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpAFJ-00006F-6t; Sun, 03 Jul 2005 15:35:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpAFH-00006A-A0 for isms@megatron.ietf.org; Sun, 03 Jul 2005 15:35:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03025 for ; Sun, 3 Jul 2005 15:35:13 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpAfh-0000ew-5M for isms@ietf.org; Sun, 03 Jul 2005 16:02:34 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2A59CE0063; Sun, 3 Jul 2005 15:35:17 -0400 (EDT) To: Eliot Lear Subject: Re: [Isms] Coming to consensus References: <200506302231.j5UMVOOU011505@ginger.cmf.nrl.navy.mil> <42C542E3.8090103@cisco.com> From: Sam Hartman Date: Sun, 03 Jul 2005 15:35:17 -0400 In-Reply-To: <42C542E3.8090103@cisco.com> (Eliot Lear's message of "Fri, 01 Jul 2005 15:19:31 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Eliot" == Eliot Lear writes: Eliot> Ken, My strong recommendation would be that if we are going Eliot> to do TCP+SASL it should be a BEEP profile. There are Eliot> substantial ancillary benefits for BEEP. For instance, the Eliot> ability to multiplex streams such as NETCONF, secure Eliot> SYSLOG, and the like come immediately to mind. Also, it Eliot> may simply configuration in these cases - you do one Eliot> authentication transaction and you're done (as per the BEEP Eliot> spec) for all the substrates. In addition BEEP offers the Eliot> ability for connection establishment to occur in either Eliot> direction, and that has benefits with regard to NATs and Eliot> firewalls. Eliot> In the coming weeks I will work with others to submit a Eliot> viable proposal along these lines. It is reasonably likely that the IESG will not be comfortable with the use of multiple protocols (netconf and snmp for example) over the same beep port. The standard firewall considerations that apply when deciding whether something needs its own port or can reuse port 80 apply. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jul 03 15:41:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpALd-0001kM-HN; Sun, 03 Jul 2005 15:41:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpALc-0001kH-Dx for isms@megatron.ietf.org; Sun, 03 Jul 2005 15:41:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03450 for ; Sun, 3 Jul 2005 15:41:46 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpAm3-00017s-9Y for isms@ietf.org; Sun, 03 Jul 2005 16:09:07 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 286ACE0063; Sun, 3 Jul 2005 15:41:51 -0400 (EDT) To: "Fleischman, Eric" References: <474EEBD229DF754FB83D256004D021080EC38D@XCH-NW-6V1.nw.nos.boeing.com> From: Sam Hartman Date: Sun, 03 Jul 2005 15:41:51 -0400 In-Reply-To: <474EEBD229DF754FB83D256004D021080EC38D@XCH-NW-6V1.nw.nos.boeing.com> (Eric Fleischman's message of "Thu, 30 Jun 2005 15:42:34 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: isms@ietf.org Subject: [Isms] TCP, UDP and the rest of the infrastructure X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Fleischman," == Fleischman, Eric writes: Fleischman,> Group: Don't both TLS and SSH require TCP transports Fleischman,> while only DTLS can support UDP? If this is true, Fleischman,> isn't our next decision point the evaluation of Fleischman,> whether SNMP shall continue to be supported over Fleischman,> either TCP or UDP or whether we only want it over Fleischman,> UDP? If the former, do we want one "secure session" Fleischman,> technology to be used for both UDP and TCP or do we Fleischman,> allow the UDP to have a different "secure session" Fleischman,> technology than TCP? Fleischman,> My own perspective (for whatever it is worth) is that Fleischman,> SNMP has had better performance in wireless and Fleischman,> bandwidth constrained environments using UDP than Fleischman,> TCP. Thus, the view from my knot-hole is that UDP is Fleischman,> important. I also would prefer a single generic Fleischman,> "secure session" approach. Can SSH support UDP? If Fleischman,> not, then I suggest that we use (D)TLS (i.e., TLS for Fleischman,> TCP and DTLS for UDP). As part of your review of TCP vs UDP you need to look at dependent infrastructure and clearly describe your reliability model. As I've pointed out when you start talking about PKI certificate verification,you tend to involve a lot of services that are fairly complicated on both sides of the SNMP exchange. Making SNMP work in an unreliable network may not be very useful if things it depends on for security do not work. So, you should be skeptical of an analysis of TCP vs UDP that does not include: * An explanation of what types of network failures are expected * An analysis of what services besides SNMP itself will be required to make ISMS work * An analysis of how the types of network failures that make UDP desirable effect these additional services. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jul 03 16:39:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpBF8-0007aT-Kb; Sun, 03 Jul 2005 16:39:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpBF7-0007aO-Lw for isms@megatron.ietf.org; Sun, 03 Jul 2005 16:39:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08250 for ; Sun, 3 Jul 2005 16:39:07 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpBfY-0004xl-2O for isms@ietf.org; Sun, 03 Jul 2005 17:06:29 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 03 Jul 2005 13:38:59 -0700 X-IronPort-AV: i="3.93,254,1115017200"; d="scan'208"; a="286269622:sNHT34756322" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j63Kcsod028682; Sun, 3 Jul 2005 13:38:54 -0700 (PDT) Received: from [212.254.247.4] (ams-clip-vpn-dhcp415.cisco.com [10.61.65.159]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j63Kc95c025216; Sun, 3 Jul 2005 13:38:10 -0700 Message-ID: <42C84CDC.7010505@cisco.com> Date: Sun, 03 Jul 2005 22:38:52 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0+ (Macintosh/20050531) MIME-Version: 1.0 To: Sam Hartman Subject: Re: [Isms] Coming to consensus References: <200506302231.j5UMVOOU011505@ginger.cmf.nrl.navy.mil> <42C542E3.8090103@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1120423092.104423"; x:"432200"; a:"rsa-sha1"; b:"nofws:1469"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"gww25NOwWJIFTRKu48mYG0k87kbwTI5faH1HrJ9sQLWWIUAOQGc5dQDJtTX4hPAi0bmVZ805" "HsbcoDxhGo4zvF9pGVYpn8b+qtk/508JWS6V4khnex+QLdElIzIEyfJBbXSt+4iHQdv2NhpPrK7" "CMzIOtzGFocW3pc+hoReLGSU="; c:"Date: Sun, 03 Jul 2005 22:38:52 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] Coming to consensus" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) 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 List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Sam, > It is reasonably likely that the IESG will not be comfortable with the > use of multiple protocols (netconf and snmp for example) over the same > beep port. The standard firewall considerations that apply when > deciding whether something needs its own port or can reuse port 80 > apply. In general I would agree with concerns about sharing a port for disparate uses, as discussed in RFC 3205 (BCP 56), Section 3. However, I don't think we're in that situation. The question from that document is this: does addition of one of the two protocols in question represent a substantially new service? The answer is clearly not. We know this because the whole point of ISMS is to integrate the security model with that of the rest of the administrative model on the device, which is what NETCONF is expected to use. We further know this because the sort of data the protocols are meant to carry are substantially similar. What's more, there are two substantial benefits of combining the two: - Improved network performance and fairness through the use of a shared TCP window (Gettys / Mogul SIGCOMM 97). This may be a minor or major point, but it's a bit early to say. - Simplified configuration and improved performance on firewalls, and potentially on end devices as well. It's one less port to have to keep track of, and it's one less port check to have to process. What's more, suppose we specify two different BEEP ports. Arguably there's no way to enforce a ban on implementations sharing ports. And really you have the same issue with SSH. I wonder how many {anything}/ssh will really be restricted to specific ports in the implementations. For this reason I don't even think it's a great idea to assign a separate port for netconf, but well, wrong wg. Have a happy 4th. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 04 16:35:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpXet-0005l4-50; Mon, 04 Jul 2005 16:35:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpXer-0005kz-Db for isms@megatron.ietf.org; Mon, 04 Jul 2005 16:35:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10038 for ; Mon, 4 Jul 2005 16:35:11 -0400 (EDT) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpY5U-000165-8Q for isms@ietf.org; Mon, 04 Jul 2005 17:02:45 -0400 Received: by romeo.rtfm.com (Postfix, from userid 1001) id BF44917058; Mon, 4 Jul 2005 13:47:02 -0700 (PDT) To: "David T. Perkins" Subject: Re: FW: [Isms] Coming to consensus References: From: Eric Rescorla Date: Mon, 04 Jul 2005 13:47:02 -0700 In-Reply-To: (David T. Perkins's message of "Sat, 2 Jul 2005 11:28:36 -0700 (PDT)") Message-ID: <861x6eb8op.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: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org "David T. Perkins" writes: > THis is an interesting question.... > > When using DTLS, a manager sends a request message, but doesn't > get back a response message. This could be due to > 1) the request was not received (dropped by the net) > 2) the response was not received (dropped by the net) > 3) the agent has gone away (or rebooted) > > What does the manager do after the application level time out? > 1) resend the original UDP packet > 2) resend the original SNMP message as a new DTLS packet > 3) bump the v3 sequence number in the message and send a > new DTLS packet My general view--and I think the one that's most consistent with the way that TLS is used--is for protocols which live above DTLS to act as much as possible as if DTLS wasn't there. This implies to me that you shouldn't do (1). Whether you do (2) or (3) would depend on what you do now if the transport is UDP. -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 04 17:31:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpYXX-0000jN-66; Mon, 04 Jul 2005 17:31:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpYXV-0000jI-Tj for isms@megatron.ietf.org; Mon, 04 Jul 2005 17:31:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17602 for ; Mon, 4 Jul 2005 17:31:39 -0400 (EDT) Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpYyA-0005ao-23 for isms@ietf.org; Mon, 04 Jul 2005 17:59:14 -0400 Received: from h-68-165-6-198.snvacaid.dynamic.covad.net ([68.165.6.198] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DpYXT-0003Kk-00 for isms@ietf.org; Mon, 04 Jul 2005 17:31:39 -0400 Message-ID: <000901c580e0$54de1f80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <861x6eb8op.fsf@romeo.rtfm.com> Subject: Re: FW: [Isms] Coming to consensus Date: Mon, 4 Jul 2005 14:35:42 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Eric Rescorla" > To: "David T. Perkins" > Cc: > Sent: Monday, July 04, 2005 1:47 PM > Subject: Re: FW: [Isms] Coming to consensus > > "David T. Perkins" writes: > > THis is an interesting question.... > > > > When using DTLS, a manager sends a request message, but doesn't > > get back a response message. This could be due to > > 1) the request was not received (dropped by the net) > > 2) the response was not received (dropped by the net) > > 3) the agent has gone away (or rebooted) > > > > What does the manager do after the application level time out? > > 1) resend the original UDP packet > > 2) resend the original SNMP message as a new DTLS packet > > 3) bump the v3 sequence number in the message and send a > > new DTLS packet > > My general view--and I think the one that's most consistent with > the way that TLS is used--is for protocols which live above > DTLS to act as much as possible as if DTLS wasn't there. This > implies to me that you shouldn't do (1). Whether you do > (2) or (3) would depend on what you do now if the transport > is UDP. > > -Ekr By "v3 sequence number" do you mean the request-id (RFC 3416) or the msgID (RFC 3412)? Assuming it's the latter, RFC 3412 is clear: "If a request is retransmitted, a new msgID value SHOULD be used for each retransmission." Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 05 01:07:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpfei-0004UP-Un; Tue, 05 Jul 2005 01:07:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpfeh-0004UH-54 for isms@megatron.ietf.org; Tue, 05 Jul 2005 01:07:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19279 for ; Tue, 5 Jul 2005 01:07:34 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpg5O-0006xM-Kc for isms@ietf.org; Tue, 05 Jul 2005 01:35:11 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 Jul 2005 22:07:24 -0700 X-IronPort-AV: i="3.93,259,1115017200"; d="scan'208"; a="288798220:sNHT88787884" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6557MVX011926; Mon, 4 Jul 2005 22:07:22 -0700 (PDT) Received: from [212.254.247.4] (ams-clip-vpn-dhcp4160.cisco.com [10.61.80.63]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j6556VZS030253; Mon, 4 Jul 2005 22:06:32 -0700 Message-ID: <42CA1587.7060200@cisco.com> Date: Tue, 05 Jul 2005 07:07:19 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0+ (Macintosh/20050531) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: FW: [Isms] Coming to consensus References: <861x6eb8op.fsf@romeo.rtfm.com> <000901c580e0$54de1f80$7f1afea9@oemcomputer> In-Reply-To: <000901c580e0$54de1f80$7f1afea9@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1120539992.858824"; x:"432200"; a:"rsa-sha1"; b:"nofws:1544"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"iynx/H6iU5ad9rn6yhET8yTNN2gqSrHJkD9jfhQGF4mB83PDHz2zy96MGSNO+VwLMbt1ynAf" "Z4afWaFaHrpBGZApDMSiJl3XCdFDki85hC9oSH97T2pxbTMZzlf03+EEv3Tl+IHupIlFT4UXaMo" "hNbCbu9rExBjaoCURMq4vqTI="; c:"Date: Tue, 05 Jul 2005 07:07:19 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: FW: [Isms] Coming to consensus" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Perhaps this is why the authors used a SHOULD? In this case there are good technical reasons NOT to use a new ID. If the underlying transport protocol is TCP then the application is likely not even to know that the "request" got retransmitted. And that is as it should be. Eliot Randy Presuhn wrote: > Hi - > > >>From: "Eric Rescorla" >>To: "David T. Perkins" >>Cc: >>Sent: Monday, July 04, 2005 1:47 PM >>Subject: Re: FW: [Isms] Coming to consensus >> >>"David T. Perkins" writes: >> >>>THis is an interesting question.... >>> >>>When using DTLS, a manager sends a request message, but doesn't >>>get back a response message. This could be due to >>>1) the request was not received (dropped by the net) >>>2) the response was not received (dropped by the net) >>>3) the agent has gone away (or rebooted) >>> >>>What does the manager do after the application level time out? >>>1) resend the original UDP packet >>>2) resend the original SNMP message as a new DTLS packet >>>3) bump the v3 sequence number in the message and send a >>> new DTLS packet >> >>My general view--and I think the one that's most consistent with >>the way that TLS is used--is for protocols which live above >>DTLS to act as much as possible as if DTLS wasn't there. This >>implies to me that you shouldn't do (1). Whether you do >>(2) or (3) would depend on what you do now if the transport >>is UDP. >> >>-Ekr > > > By "v3 sequence number" do you mean the request-id (RFC 3416) > or the msgID (RFC 3412)? Assuming it's the latter, RFC 3412 is > clear: "If a request is retransmitted, a new msgID value SHOULD > be used for each retransmission." > > Randy > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 05 09:43:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpniR-0002xi-DN; Tue, 05 Jul 2005 09:43:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpniP-0002s7-4o for isms@megatron.ietf.org; Tue, 05 Jul 2005 09:43:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26529 for ; Tue, 5 Jul 2005 08:51:19 -0400 (EDT) Message-Id: <200507051251.IAA26529@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpmAK-0002ai-3Z for isms@ietf.org; Tue, 05 Jul 2005 08:04:40 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc13) with SMTP id <20050705113650016000jvude>; Tue, 5 Jul 2005 11:36:50 +0000 From: "David B Harrington" To: "'Eliot Lear'" , "'Sam Hartman'" Subject: RE: [Isms] Coming to consensus Date: Tue, 5 Jul 2005 07:36:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-reply-to: <42C84CDC.7010505@cisco.com> Thread-Index: AcWAD6KN+T7DseE3T+q0Xz9O3kAxhgBQRkPQ X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Eliot, > > The question from that document is this: does addition of one > of the two > protocols in question represent a substantially new service? > The answer > is clearly not. We know this because the whole point of ISMS is to > integrate the security model with that of the rest of the > administrative > model on the device, which is what NETCONF is expected to use. We > further know this because the sort of data the protocols are meant to > carry are substantially similar. I am a supporter of efforts to provide improved integration between the various network mangement protocols, but I have to disagree with your analysis here. I agree that a large subset of the data the two protocols are meant to carry is substantially similar, which argues for integration of the data models used by the two protocols. I disagree with your assertion that the two protocols [do not] represent a substantially new service. The "world tour" of data gathering and the IAB Network Management Workshop reached the conclusion that most operators utilize SNMP as a fault and performance monitoring service, but not as a device configuration service. Netconf is focused on providing a device configuration service. NETCONF and SNMP protocols provide different services within the network management umbrella, even though much of the data they utilize is (or could be) common to both protocols. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 05 18:39:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpw52-0007I0-Cd; Tue, 05 Jul 2005 18:39:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpw50-0007FR-TC for isms@megatron.ietf.org; Tue, 05 Jul 2005 18:39:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10232 for ; Tue, 5 Jul 2005 18:39:47 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpwVe-00059i-Qc for isms@ietf.org; Tue, 05 Jul 2005 19:07:23 -0400 Received: from h-64-105-137-251.snvacaid.dynamic.covad.net ([64.105.137.251] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dpw4d-0002Q2-00 for isms@ietf.org; Tue, 05 Jul 2005 18:39:27 -0400 Message-ID: <007401c581b2$f8089140$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <861x6eb8op.fsf@romeo.rtfm.com> <000901c580e0$54de1f80$7f1afea9@oemcomputer> <42CA1587.7060200@cisco.com> Subject: Re: FW: [Isms] Coming to consensus Date: Tue, 5 Jul 2005 15:43:17 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Eliot Lear" > To: "Randy Presuhn" > Cc: > Sent: Monday, July 04, 2005 10:07 PM > Subject: Re: FW: [Isms] Coming to consensus > > Perhaps this is why the authors used a SHOULD? In this case there are > good technical reasons NOT to use a new ID. If the underlying transport > protocol is TCP then the application is likely not even to know that the > "request" got retransmitted. And that is as it should be. The context for the question was DTLS, not TCP. In the TCP case, the receiving application will not know that there has been any transport-layer retransmission, and will see the message exactly once, unless the connection failed, in which case it might not see it at all. In any case, Since the SNMP engine receiving the message may suppress duplicates, if the application generating the request is at all interested in the response, it will need to generate a request with a fresh request-id and msgID. The one case where one *might* want to re-transmit the SNMP message without changing the request-id or msgID is when the request is a SetRequest with side effects such that exactly-once execution is desired, and there are no other guards in place (e.g. TestAndIncr, though it's not perfect) to allow the application to determine whether it was the request or the response that was lost. Even in this case, there's no guarantee that the receiving engine would suppress the duplicate. Randy > Eliot > > > Randy Presuhn wrote: > > Hi - > > > > > >>From: "Eric Rescorla" > >>To: "David T. Perkins" > >>Cc: > >>Sent: Monday, July 04, 2005 1:47 PM > >>Subject: Re: FW: [Isms] Coming to consensus > >> > >>"David T. Perkins" writes: > >> > >>>THis is an interesting question.... > >>> > >>>When using DTLS, a manager sends a request message, but doesn't > >>>get back a response message. This could be due to > >>>1) the request was not received (dropped by the net) > >>>2) the response was not received (dropped by the net) > >>>3) the agent has gone away (or rebooted) > >>> > >>>What does the manager do after the application level time out? > >>>1) resend the original UDP packet > >>>2) resend the original SNMP message as a new DTLS packet > >>>3) bump the v3 sequence number in the message and send a > >>> new DTLS packet > >> > >>My general view--and I think the one that's most consistent with > >>the way that TLS is used--is for protocols which live above > >>DTLS to act as much as possible as if DTLS wasn't there. This > >>implies to me that you shouldn't do (1). Whether you do > >>(2) or (3) would depend on what you do now if the transport > >>is UDP. > >> > >>-Ekr > > > > > > By "v3 sequence number" do you mean the request-id (RFC 3416) > > or the msgID (RFC 3412)? Assuming it's the latter, RFC 3412 is > > clear: "If a request is retransmitted, a new msgID value SHOULD > > be used for each retransmission." > > > > Randy > > > > > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 05 20:06:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpxQt-0003au-Ok; Tue, 05 Jul 2005 20:06:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpxQs-0003a4-VU for isms@megatron.ietf.org; Tue, 05 Jul 2005 20:06:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22465 for ; Tue, 5 Jul 2005 20:06:25 -0400 (EDT) Received: from i9589.i.pppool.de ([85.73.149.137] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpxqg-0000EZ-N5 for isms@ietf.org; Tue, 05 Jul 2005 20:33:12 -0400 Received: by boskop.local (Postfix, from userid 501) id EC8853589DA; Wed, 6 Jul 2005 02:05:06 +0200 (CEST) Date: Wed, 6 Jul 2005 02:05:06 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20050706000506.GC6281@boskop.local> Mail-Followup-To: isms@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Isms] DSSH - possible? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi. Stupid question to the security experts: Will it be possible to invent a datagram ssh (DSSH) in similar ways as it was possible to invent DTLS? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 05 20:23:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpxhP-0008Qb-JA; Tue, 05 Jul 2005 20:23:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpxhN-0008Ow-OC for isms@megatron.ietf.org; Tue, 05 Jul 2005 20:23:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24706 for ; Tue, 5 Jul 2005 20:23:30 -0400 (EDT) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpxzG-0000xG-2A for isms@ietf.org; Tue, 05 Jul 2005 20:42:03 -0400 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 6E4C41705B; Tue, 5 Jul 2005 17:26:17 -0700 (PDT) To: isms@ietf.org Subject: Re: [Isms] DSSH - possible? References: <20050706000506.GC6281@boskop.local> From: Eric Rescorla Date: Tue, 05 Jul 2005 17:26:17 -0700 In-Reply-To: <20050706000506.GC6281@boskop.local> (Juergen Schoenwaelder's message of "Wed, 6 Jul 2005 02:05:06 +0200") Message-ID: <86pstw93va.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: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen Schoenwaelder writes: > Stupid question to the security experts: Will it be possible to invent > a datagram ssh (DSSH) in similar ways as it was possible to invent DTLS? Yes. Well, sort of. SSL/TLS is purely a secure channel protocol. SSH is really a suite of protocols. One of these is a secure channel protocol and the others (e.g. remote login, SCP, SFTP, etc.) run on top of that secure channel. You could certainly build a datagram capable version of SSH's secure channel protocol, but this wouldn't necessarily get you what you want, since you couldn't use e.g., SFTP without also building a datagram-capable version of that, which starts to entail a very substantial amount of reinvention. -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 05 20:59:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpyFg-0002OD-3D; Tue, 05 Jul 2005 20:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpyCT-0000Hj-2S for isms@megatron.ietf.org; Tue, 05 Jul 2005 20:55:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28167 for ; Tue, 5 Jul 2005 20:55:39 -0400 (EDT) Received: from i9589.i.pppool.de ([85.73.149.137] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpyYq-0003tk-Ha for isms@ietf.org; Tue, 05 Jul 2005 21:18:48 -0400 Received: by boskop.local (Postfix, from userid 501) id 3F3EE358A50; Wed, 6 Jul 2005 02:50:50 +0200 (CEST) Date: Wed, 6 Jul 2005 02:50:50 +0200 From: Juergen Schoenwaelder To: Eric Rescorla Subject: Re: [Isms] DSSH - possible? Message-ID: <20050706005050.GA6373@boskop.local> Mail-Followup-To: Eric Rescorla , isms@ietf.org References: <20050706000506.GC6281@boskop.local> <86pstw93va.fsf@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86pstw93va.fsf@romeo.rtfm.com> User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Tue, Jul 05, 2005 at 05:26:17PM -0700, Eric Rescorla wrote: > Juergen Schoenwaelder writes: > > Stupid question to the security experts: Will it be possible to invent > > a datagram ssh (DSSH) in similar ways as it was possible to invent DTLS? > > Yes. Well, sort of. > > SSL/TLS is purely a secure channel protocol. SSH is really a suite of > protocols. One of these is a secure channel protocol and the others > (e.g. remote login, SCP, SFTP, etc.) run on top of that secure > channel. You could certainly build a datagram capable version of SSH's > secure channel protocol, but this wouldn't necessarily get you what > you want, since you couldn't use e.g., SFTP without also building a > datagram-capable version of that, which starts to entail a very > substantial amount of reinvention. I think DTLS was not invented to replace HTTPS and I doubt DSSH would be designed to replace SSH or SFTP. I was simply wondering whether a datagram version of SSH would be feasible so that UDP based protocols could leverage the SSH secure channel protocol and more important probably the authentication protocols running on top... /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 06 14:16:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqEOX-0002yE-3R; Wed, 06 Jul 2005 14:13:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqEOR-0002vM-RV for isms@megatron.ietf.org; Wed, 06 Jul 2005 14:13:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01400 for ; Wed, 6 Jul 2005 14:13:04 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqEgy-00017F-R9 for isms@ietf.org; Wed, 06 Jul 2005 14:32:19 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 6B17EE0065; Wed, 6 Jul 2005 14:04:31 -0400 (EDT) To: "Fleischman, Eric" References: <474EEBD229DF754FB83D256004D021080EC3A4@XCH-NW-6V1.nw.nos.boeing.com> From: Sam Hartman Date: Wed, 06 Jul 2005 14:04:30 -0400 In-Reply-To: <474EEBD229DF754FB83D256004D021080EC3A4@XCH-NW-6V1.nw.nos.boeing.com> (Eric Fleischman's message of "Wed, 6 Jul 2005 10:48:08 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: isms@ietf.org Subject: [Isms] Re: TCP, UDP and the rest of the infrastructure X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Fleischman," == Fleischman, Eric writes: Fleischman,> From: Sam Hartman [mailto:hartmans-ietf@mit.edu] Fleischman,> wrote: >> Making SNMP work in an unreliable network may not be very >> useful if things it depends on for security do not work. Fleischman,> I thoroughly agree. However, is there any reason why Fleischman,> you (or anyone else) believe that DTLS doesn't Fleischman,> provide the necessary capabilities to permit Fleischman,> ISMS-secured SNMP over UDP use? The SNMP part of the connection will be over UDP. What about CRL retrieval? What about OCSP? What about DNS lookups for all of the above? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 06 14:16:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqEOV-0002wk-4A; Wed, 06 Jul 2005 14:13:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqEOS-0002vQ-0B for isms@megatron.ietf.org; Wed, 06 Jul 2005 14:13:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01393 for ; Wed, 6 Jul 2005 14:13:04 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqEgz-00016s-E1 for isms@ietf.org; Wed, 06 Jul 2005 14:32:21 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA29056; Wed, 6 Jul 2005 11:04:02 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j66I47126734; Wed, 6 Jul 2005 11:04:07 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 11:04:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: (D)TLS considered harmful: was Re: [Isms] Coming to consensus Date: Wed, 6 Jul 2005 11:04:06 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC3A6@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: (D)TLS considered harmful: was Re: [Isms] Coming to consensus Thread-Index: AcV/rGkMn3WrdZfoRE668Asn0x1TCACp9CVA From: "Fleischman, Eric" To: "Tom Petch" , X-OriginalArrivalTime: 06 Jul 2005 18:04:06.0896 (UTC) FILETIME=[19F0A700:01C58255] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 >> SNMP over TCP is SNMP over TCP. If someone specifies SNMP over SSH (or=20 >> TLS) then this is SNMP over SSH (or TLS). I don't think you need SNMP >> over TCP to specify and implement SNMP over SSH (or TLS). > >Yeeeeees, I agree ... in protocol stack terms. But turning to=20 >the SSH I-D I quoted earlier, SSH needs a reliable transport. =20 >I did not say reliable equals TCP at that time, Eric was rather=20 >stronger in support of that. I am sorry to have implied that reliable transport equals TCP. I am aware of SCTP but not SCTP use under SNMP.=20 My own arguments are to support flexibility due to the large number of different environments in which SNMP is deployed. Current SNMP applications support both UDP and TCP. I note that some in our WG apparently prefer to limit this to TCP only for ISMS in order to cleanly support SSH or TLS. However, are there advocates in our WG that believe that we should support other transports in addition to current SNMP use? If there are, would they please explain the issue they are trying to address? Thanks. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 06 14:43:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqEs2-0002DG-2Y; Wed, 06 Jul 2005 14:43:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqEs0-0002Bk-Cb for isms@megatron.ietf.org; Wed, 06 Jul 2005 14:43:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03393 for ; Wed, 6 Jul 2005 14:43:39 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqFJ1-0004up-PE for isms@ietf.org; Wed, 06 Jul 2005 15:11:37 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 21180E0063; Wed, 6 Jul 2005 14:43:44 -0400 (EDT) To: "Fleischman, Eric" References: <474EEBD229DF754FB83D256004D021080EC3A7@XCH-NW-6V1.nw.nos.boeing.com> From: Sam Hartman Date: Wed, 06 Jul 2005 14:43:44 -0400 In-Reply-To: <474EEBD229DF754FB83D256004D021080EC3A7@XCH-NW-6V1.nw.nos.boeing.com> (Eric Fleischman's message of "Wed, 6 Jul 2005 11:23:48 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: isms@ietf.org Subject: [Isms] Re: TCP, UDP and the rest of the infrastructure X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Fleischman," == Fleischman, Eric writes: Fleischman,> From: Sam Hartman [mailto:hartmans-ietf@mit.edu] >> Fleischman,> From: Sam Hartman [mailto:hartmans-ietf@mit.edu] >> Fleischman,> wrote: >>>> Making SNMP work in an unreliable network may not be very >>>> useful if things it depends on for security do not work. >> Fleischman,> I thoroughly agree. However, is there any reason >> why Fleischman,> you (or anyone else) believe that DTLS doesn't >> Fleischman,> provide the necessary capabilities to permit >> Fleischman,> ISMS-secured SNMP over UDP use? >> The SNMP part of the connection will be over UDP. What about >> CRL retrieval? What about OCSP? What about DNS lookups for Fleischman,> all of the above? Um, no. Most of these are not defined for UDP. These issues are not unique to ISMS. These issues do influence how likely it is that UDP makes sense for ISMS. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 06 14:56:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqF49-0004zV-Bh; Wed, 06 Jul 2005 14:56:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqF47-0004xw-BY for isms@megatron.ietf.org; Wed, 06 Jul 2005 14:56:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04589 for ; Wed, 6 Jul 2005 14:56:10 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqFV8-0006H2-Mg for isms@ietf.org; Wed, 06 Jul 2005 15:24:07 -0400 Received: from romeo.rtfm.com ([198.144.203.242]) by mx2.foretec.com with esmtp (Exim 4.24) id 1DqEbC-0002mq-Ao for isms@ietf.org; Wed, 06 Jul 2005 14:26:18 -0400 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 1F5AC1705C; Wed, 6 Jul 2005 11:38:35 -0700 (PDT) To: Sam Hartman Subject: Re: [Isms] Re: TCP, UDP and the rest of the infrastructure References: <474EEBD229DF754FB83D256004D021080EC3A4@XCH-NW-6V1.nw.nos.boeing.com> From: Eric Rescorla Date: Wed, 06 Jul 2005 11:38:35 -0700 In-Reply-To: (Sam Hartman's message of "Wed, 06 Jul 2005 14:04:30 -0400") Message-ID: <86zmsz7pas.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: b19722fc8d3865b147c75ae2495625f2 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Sam Hartman writes: >>>>>> "Fleischman," == Fleischman, Eric writes: > > Fleischman,> From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Fleischman,> wrote: > >> Making SNMP work in an unreliable network may not be very > >> useful if things it depends on for security do not work. > > Fleischman,> I thoroughly agree. However, is there any reason why > Fleischman,> you (or anyone else) believe that DTLS doesn't > Fleischman,> provide the necessary capabilities to permit > Fleischman,> ISMS-secured SNMP over UDP use? > > The SNMP part of the connection will be over UDP. What about CRL > retrieval? What about OCSP? Of course, in the vast majority of SSL/TLS implementations don't really do any of this stuff. They just accept certificates if they're transitively signed by some trust anchor. That said, how important this consideration is rather depends on the reasons for using UDP. In most of the environments I'm familiar with, UDP is used because it has different performance properties (for a broad definition of performance), mostly in terms of timeliness, not because TCP isn't available. In the specific case of certificate-based handshakes where status checking is being used, one would presumably use TCP to do the status checking during the handshake, but this wouldn't be relevant after the session is completed. -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 06 14:56:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqF4s-0005kd-Th; Wed, 06 Jul 2005 14:56:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqF4q-0005hQ-SC for isms@megatron.ietf.org; Wed, 06 Jul 2005 14:56:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04712 for ; Wed, 6 Jul 2005 14:56:55 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqFVs-0006Kq-2j for isms@ietf.org; Wed, 06 Jul 2005 15:24:53 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by mx2.foretec.com with esmtp (Exim 4.24) id 1DqEZU-0002fb-IK for isms@ietf.org; Wed, 06 Jul 2005 14:24:32 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA03480; Wed, 6 Jul 2005 13:23:52 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j66INpv18562; Wed, 6 Jul 2005 13:23:51 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 11:23:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jul 2005 11:23:48 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC3A7@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: TCP, UDP and the rest of the infrastructure Thread-Index: AcWCVf7HTBC2V+yDTVWgD8unYBpmsgAANT3Q From: "Fleischman, Eric" To: "Sam Hartman" X-OriginalArrivalTime: 06 Jul 2005 18:23:49.0013 (UTC) FILETIME=[DA896450:01C58257] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org Subject: [Isms] RE: TCP, UDP and the rest of the infrastructure X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 >Fleischman,> From: Sam Hartman [mailto:hartmans-ietf@mit.edu] >Fleischman,> wrote: >>> Making SNMP work in an unreliable network may not be very >>> useful if things it depends on for security do not work. >Fleischman,> I thoroughly agree. However, is there any reason why >Fleischman,> you (or anyone else) believe that DTLS doesn't >Fleischman,> provide the necessary capabilities to permit >Fleischman,> ISMS-secured SNMP over UDP use? >The SNMP part of the connection will be over UDP. =20 >What about CRL retrieval? What about OCSP? What about DNS lookups for all of the above? These issues will be handled in PKI environments in accordance with however that infrastructure has configured their PKI deployment.=20 If ISMS SNMP over UDP uses PKI, then I fail to understand why you believe that there are unique issues which aren't common for other UDP-based PKI systems. Could you please explain the nature of your concern (i.e., why do you believe that SNMP is unique among UDP systems)? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 06 15:06:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqFES-0005Ro-CV; Wed, 06 Jul 2005 15:06:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqFEP-0005OQ-S0 for isms@megatron.ietf.org; Wed, 06 Jul 2005 15:06:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06086 for ; Wed, 6 Jul 2005 15:06:48 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqFfQ-0007Qg-7n for isms@ietf.org; Wed, 06 Jul 2005 15:34:46 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 06 Jul 2005 12:06:38 -0700 X-IronPort-AV: i="3.93,265,1115017200"; d="scan'208"; a="291712669:sNHT28442990" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j66J6ZVX012935; Wed, 6 Jul 2005 12:06:36 -0700 (PDT) Received: from [212.254.247.4] (ams-clip-vpn-dhcp4436.cisco.com [10.61.81.83]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j66J5aVN011059; Wed, 6 Jul 2005 12:05:37 -0700 Message-ID: <42CC2BB6.8050207@cisco.com> Date: Wed, 06 Jul 2005 21:06:30 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: EKR Subject: Re: [Isms] Re: TCP, UDP and the rest of the infrastructure References: <474EEBD229DF754FB83D256004D021080EC3A4@XCH-NW-6V1.nw.nos.boeing.com> <86zmsz7pas.fsf@romeo.rtfm.com> In-Reply-To: <86zmsz7pas.fsf@romeo.rtfm.com> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1120676740.505553"; x:"432200"; a:"rsa-sha1"; b:"nofws:332"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"kaJW99IqEFfXVwOjqmzAvG+6d8KvflLUev0vL4PPfAiZ20QcSUYxBe+1TsXTuQYrvEmZ4jmD" "R+GTCMhCIbWZr79zyYyVrHc7GUFfoCMQCc6DXrgdTFz/ZD4yDDv4pFGczGrHGRI5BuvWA6DOv/e" "1Z3Hmtl3cB4+8GKChP0G5pwc="; c:"Date: Wed, 06 Jul 2005 21:06:30 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] Re: TCP, UDP and the rest of the infrastructure" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Eric Rescorla wrote: > In the specific > case of certificate-based handshakes where status checking is being > used, one would presumably use TCP to do the status checking during > the handshake, but this wouldn't be relevant after the session is > completed. Right. Even if one uses DTLS for SNMP, that doesn't mean it's necessary to use UDP for the other support services (it probably isn't). Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 06 15:08:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqFGM-00078l-AJ; Wed, 06 Jul 2005 15:08:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqFGK-00077P-5d for isms@megatron.ietf.org; Wed, 06 Jul 2005 15:08:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01754 for ; Wed, 6 Jul 2005 14:13:34 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqEaY-0000bD-DH for isms@ietf.org; Wed, 06 Jul 2005 14:25:40 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA18578; Wed, 6 Jul 2005 10:57:20 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j66HvOv15184; Wed, 6 Jul 2005 12:57:25 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 10:57:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: (D)TLS considered harmful: was Re: [Isms] Coming to consensus Date: Wed, 6 Jul 2005 10:57:23 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC3A5@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: (D)TLS considered harmful: was Re: [Isms] Coming to consensus Thread-Index: AcV/u3MqvaZCF/64RVW28W3vHghU/QCl5LQw From: "Fleischman, Eric" To: "Eliot Lear" , "Tom Petch" , X-OriginalArrivalTime: 06 Jul 2005 17:57:23.0956 (UTC) FILETIME=[29C4E340:01C58254] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org ----Original Message----- From: Eliot Lear [mailto:lear@cisco.com]=20 >Juergen Schoenwaelder wrote: >> P.S. Looking at the boxes I have access to, many do ssh. Some do TLS and=20 >> none of them does DTLS or BEEP. (At least not that I am aware of this. >> Perhaps I am having the wrong boxes. ;-) >This is a fair point, but it is not the only consideration. The=20 >flexibility we need today, pragmatically speaking, is for a way for=20 >either side to initiate queries through NATs, firewalls, and associated >gook. You *could* implement this flexibility in SSH, but nobody has, so=20 >far as I know. Eliot, This is a good observation but I become lost when I try to follow your point "into the details." The "firewall" reference ultimately appears to me to be a red herring because corporations will establish whatever firewall policies we see fit, so whatever ISMS will decide will ultimately be subject to firewall policies -- and that is a good thing. You know a whole lot more about NATs than I, but isn't it possible to build NAT responses on Transport Layer protocols? For example, didn't Christian Huetima have an ID about UDP over NATs? Regardless, my ignorant question to you is "isn't all this 'associated gook' handled by the 'gook' itself such that whatever approach ISMS comes up with (whether BEEP, or SSH, or TLS or DTLS) is ultimately orthogonal to 'gook' behavior? That is, is any of this really a problem for our WG and, if so, why is it our problem? --Eric _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 06 16:08:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqGC5-0002E2-1u; Wed, 06 Jul 2005 16:08:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqGC3-0002DN-8r for isms@megatron.ietf.org; Wed, 06 Jul 2005 16:08:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17136 for ; Wed, 6 Jul 2005 16:08:25 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqGd4-0005Zi-Kq for isms@ietf.org; Wed, 06 Jul 2005 16:36:24 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA01269; Wed, 6 Jul 2005 13:08:00 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j66K7x109196; Wed, 6 Jul 2005 13:08:00 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 13:07:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jul 2005 13:07:57 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC3A8@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: TCP, UDP and the rest of the infrastructure Thread-Index: AcWCWqNEVAnALpzXToGIhLiFAKICFgACdL1g From: "Fleischman, Eric" To: "Sam Hartman" X-OriginalArrivalTime: 06 Jul 2005 20:07:57.0569 (UTC) FILETIME=[66F75F10:01C58266] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org Subject: [Isms] RE: TCP, UDP and the rest of the infrastructure X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 >>>>>> "Fleischman," =3D=3D Fleischman, Eric = =20 >>>>>> writes: >Fleischman,> From: Sam Hartman [mailto:hartmans-ietf@mit.edu] >>> Fleischman,> From: Sam Hartman [mailto:hartmans-ietf@mit.edu] >>> Fleischman,> wrote: >>>>> Making SNMP work in an unreliable network may not be very >>>>> useful if things it depends on for security do not work. >>> Fleischman,> I thoroughly agree. However, is there any reason >>> why Fleischman,> you (or anyone else) believe that DTLS doesn't >>> Fleischman,> provide the necessary capabilities to permit >>> Fleischman,> ISMS-secured SNMP over UDP use? >>> The SNMP part of the connection will be over UDP. What about >>> CRL retrieval? What about OCSP? What about DNS lookups for >Fleischman,> all of the above? >Um, no. Most of these are not defined for UDP. >These issues are not unique to ISMS. These issues do=20 >influence how likely it is that UDP makes sense for ISMS. Sam, I am perplexed -- are we talking past each other or am I failing to see something that is obvious to you? That is, from my knothole: 1) It's been years since I've looked into this in detail, but I recall that Transport protocols usually do not worry about CRL or perform these other PKI-related activities. Rather, they use the PKI crypto identity as the "seed" for their session key establishment (e.g., for Diffie-Hellman exchanges). Therefore, I do not understand your concern as to why UDP is any different from TCP in this regards since neither does OCSP or CRL. 2) Rather, these PKI activities are either performed at the application-layer, or, more usually, within the applications themselves. For example, think of how code or document signing works -- it is an application-concept. 3) A natural issue (to my mind at least) is concerning the difference between authentication at the transport layer and authentication at the application layer. I imagine that protocols can integrate the two together, but I am much more familiar with the two layers behaving independently from each other: If both layers use PKI for authentication, then the fact that the Transport Layer doesn't do CRL is not a concern, because the application layer will. --Eric _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 06 16:28:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqGVi-0002wJ-5I; Wed, 06 Jul 2005 16:28:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqGVf-0002rn-Ea for isms@megatron.ietf.org; Wed, 06 Jul 2005 16:28:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23527 for ; Wed, 6 Jul 2005 16:28:41 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqGwh-0003AT-Hs for isms@ietf.org; Wed, 06 Jul 2005 16:56:40 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j66KSPLb013723; Wed, 6 Jul 2005 13:28:25 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j66KSK9b019334; Wed, 6 Jul 2005 13:28:20 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j66KSJD4019316; Wed, 6 Jul 2005 13:28:20 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 6 Jul 2005 13:28:18 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Sam Hartman Subject: Re: [Isms] Re: TCP, UDP and the rest of the infrastructure In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, Sam - you highlight a huge frustration that I (and probably others) have with the IETF security community. It appears that the "rules" are always being changed. The major goal of the ISMS WG is to use existing security infrastructures. If a system has a X.509 cert and it is being used for something else (like a a WEB server), and now the SNMP agent also wants to use a X.509 cert, it seems like you are saying with the below, that this cannot be done, since the "dirty little secret of using X.509 certs (which is revocation)" has not been solved, and it must be before SNMP can use certs. Is this what you are saying? Or I'm I reading too much inbetween the lines? On Wed, 6 Jul 2005, Sam Hartman wrote: > >>>>> "Fleischman," == Fleischman, Eric writes: > > Fleischman,> From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Fleischman,> wrote: > >> Making SNMP work in an unreliable network may not be very > >> useful if things it depends on for security do not work. > > Fleischman,> I thoroughly agree. However, is there any reason why > Fleischman,> you (or anyone else) believe that DTLS doesn't > Fleischman,> provide the necessary capabilities to permit > Fleischman,> ISMS-secured SNMP over UDP use? > > The SNMP part of the connection will be over UDP. What about CRL > retrieval? What about OCSP? What about DNS lookups for all of the > above? > Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 06 16:39:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqGfy-0008Ii-Ss; Wed, 06 Jul 2005 16:39:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqGfx-0008Cj-At for isms@megatron.ietf.org; Wed, 06 Jul 2005 16:39:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25106 for ; Wed, 6 Jul 2005 16:39:16 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqH6k-0005Z1-Aw for isms@ietf.org; Wed, 06 Jul 2005 17:07:04 -0400 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 j66Kctdd007786 for ; Wed, 6 Jul 2005 16:38:56 -0400 (EDT) Message-Id: <200507062038.j66Kctdd007786@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Re: TCP, UDP and the rest of the infrastructure In-Reply-To: X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Wed, 06 Jul 2005 16:38:55 -0400 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: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >The major goal of the ISMS WG is to use existing security >infrastructures. If a system has a X.509 cert and it is >being used for something else (like a a WEB server), and >now the SNMP agent also wants to use a X.509 cert, it seems >like you are saying with the below, that this cannot be >done, since the "dirty little secret of using X.509 certs >(which is revocation)" has not been solved, and it must be >before SNMP can use certs. I don't believe that Sam is saying that. I think what he's trying to say is, "Hey, let's consider what the backend authentication protocol is doing when we ask if we want UDP or TCP". For example ... some people say that they want UDP because it scales better, or it performs better on lossy networks. What I've interpreted Sam's comments to mean is "Maybe you should ask yourself this question: if my SNMP protocol can traverse a lossy network fine, but to authenticate I need to use TCP to talk to some backend server (e.g., to fetch a CRL, talk to my LDAP server), is that useful?" --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 06 16:46:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqGn8-0006U0-4G; Wed, 06 Jul 2005 16:46:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqGn3-0006SR-I6 for isms@megatron.ietf.org; Wed, 06 Jul 2005 16:46:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27332 for ; Wed, 6 Jul 2005 16:46:39 -0400 (EDT) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqHE5-00084O-KT for isms@ietf.org; Wed, 06 Jul 2005 17:14:39 -0400 Received: by romeo.rtfm.com (Postfix, from userid 1001) id EF3F21705B; Wed, 6 Jul 2005 13:58:51 -0700 (PDT) To: Ken Hornstein Subject: Re: [Isms] Re: TCP, UDP and the rest of the infrastructure References: <200507062038.j66Kctdd007786@ginger.cmf.nrl.navy.mil> From: Eric Rescorla Date: Wed, 06 Jul 2005 13:58:51 -0700 In-Reply-To: <200507062038.j66Kctdd007786@ginger.cmf.nrl.navy.mil> (Ken Hornstein's message of "Wed, 06 Jul 2005 16:38:55 -0400") Message-ID: <86vf3n7it0.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: b19722fc8d3865b147c75ae2495625f2 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Ken Hornstein writes: >>The major goal of the ISMS WG is to use existing security >>infrastructures. If a system has a X.509 cert and it is >>being used for something else (like a a WEB server), and >>now the SNMP agent also wants to use a X.509 cert, it seems >>like you are saying with the below, that this cannot be >>done, since the "dirty little secret of using X.509 certs >>(which is revocation)" has not been solved, and it must be >>before SNMP can use certs. > > I don't believe that Sam is saying that. I think what he's trying to > say is, "Hey, let's consider what the backend authentication protocol > is doing when we ask if we want UDP or TCP". > > For example ... some people say that they want UDP because it scales > better, or it performs better on lossy networks. What I've interpreted > Sam's comments to mean is "Maybe you should ask yourself this question: > if my SNMP protocol can traverse a lossy network fine, but to > authenticate I need to use TCP to talk to some backend server (e.g., to > fetch a CRL, talk to my LDAP server), is that useful?" Well, obviously this depends on the reason you want to use UDP. However, the scaling arguments about UDP vs TCP usually focus on the need with TCP to keep a whole bunch of TCP connections open at once. Without making an argument about whether that's true or not, if you use TCP for OCSP or CRL fetching, these would be short-lived connections so the same arguments wouldn't apply. -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 06 16:48:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqGob-0007W5-TQ; Wed, 06 Jul 2005 16:48:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqGoW-0007QZ-9C for isms@megatron.ietf.org; Wed, 06 Jul 2005 16:48:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27434 for ; Wed, 6 Jul 2005 16:48:10 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqHFY-00088C-OT for isms@ietf.org; Wed, 06 Jul 2005 17:16:09 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id CD15DE0063; Wed, 6 Jul 2005 16:48:17 -0400 (EDT) To: "David T. Perkins" Subject: Re: [Isms] Re: TCP, UDP and the rest of the infrastructure References: From: Sam Hartman Date: Wed, 06 Jul 2005 16:48:17 -0400 In-Reply-To: (David T. Perkins's message of "Wed, 6 Jul 2005 13:28:18 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "David" == David T Perkins writes: David> HI, Sam - you highlight a huge frustration that I (and David> probably others) have with the IETF security community. It David> appears that the "rules" are always being changed. Well, security is still evolving so the rules will change. However they have not done so in the way you claim--at least I'm not proposing such a change. But with every new effort we need to learn from the mistakes of the past and to do a somewhat better job than we have done in the past. If that's what you are frustrated by in terms of rules changing, I can understand your frustration although I expect to contribute to it. That said, it is important not to change the rules too much. Creating pressure for evolution is good in my mind. Creating so much pressure that we do not accomplish our goals is not. David> The major goal of the ISMS WG is to use existing security David> infrastructures. If a system has a X.509 cert and it is David> being used for something else (like a a WEB server), and David> now the SNMP agent also wants to use a X.509 cert, it seems David> like you are saying with the below, that this cannot be David> done, since the "dirty little secret of using X.509 certs David> (which is revocation)" has not been solved, and it must be David> before SNMP can use certs. David> Is this what you are saying? Or I'm I reading too much David> inbetween the lines? I think you are reading way too much in between the lines;) All I wanted to say is that you should consider that there may be other services SNMP depends on from a security standpoint. The set of services will grow over time. This may influence whether UDP is a requirement. I did not intend to say that I expect you to require OCSP, CRL retrieval etc any more than any other use of PKI. I do expect these services to be used in the future. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 13 17:13:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsoY9-0001qZ-8B; Wed, 13 Jul 2005 17:13:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsoY7-0001qF-2M for isms@megatron.ietf.org; Wed, 13 Jul 2005 17:13:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14251 for ; Wed, 13 Jul 2005 17:13:45 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsp0X-0002bD-6e for isms@ietf.org; Wed, 13 Jul 2005 17:43:10 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E44D7E0049; Wed, 13 Jul 2005 17:13:36 -0400 (EDT) To: Eric Rescorla Subject: Re: [Isms] DSSH - possible? References: <20050706000506.GC6281@boskop.local> <86pstw93va.fsf@romeo.rtfm.com> <20050706005050.GA6373@boskop.local> From: Sam Hartman Date: Wed, 13 Jul 2005 17:13:36 -0400 In-Reply-To: <20050706005050.GA6373@boskop.local> (Juergen Schoenwaelder's message of "Wed, 6 Jul 2005 02:50:50 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org One problem I see with dssh is that the authentication protocols take advantage of the full reliable transport nature of the ssh transport. Setting things up so that you had reuse of authentication would probably involve allowing some services to require reliable transport and others not to do so. That seems complicated. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 13 17:28:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsomH-0004iD-Tx; Wed, 13 Jul 2005 17:28:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsomH-0004i8-GH for isms@megatron.ietf.org; Wed, 13 Jul 2005 17:28:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15485 for ; Wed, 13 Jul 2005 17:28:23 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DspEk-00039G-Mo for isms@ietf.org; Wed, 13 Jul 2005 17:57:51 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 9878EE0049; Wed, 13 Jul 2005 17:28:17 -0400 (EDT) To: isms@ietf.org From: Sam Hartman Date: Wed, 13 Jul 2005 17:28:17 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Isms] TLS and DTLS should not be considered together X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi. Just a reminder that the natural way to do authentication with TLS (TLS+SASL) is not such a good option with DTLS. You can design an approach where DTLS and TLS are used (DTLS for UDP, TLS for TCP). You have two approaches for what to do with TLS. You can use the same set of authentication available with DTLS. Or you can use SASL+TLS like the application protocols. You need to carefully consider these tradeoffs and understand exactly what you are getting with a DTLS+TLS approach. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 14 03:57:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsyb7-0000p7-H0; Thu, 14 Jul 2005 03:57:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsyb6-0000p2-84 for isms@megatron.ietf.org; Thu, 14 Jul 2005 03:57:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14855 for ; Thu, 14 Jul 2005 03:57:30 -0400 (EDT) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsz3e-0005Ga-LP for isms@ietf.org; Thu, 14 Jul 2005 04:27:04 -0400 Received: by romeo.rtfm.com (Postfix, from userid 1001) id F3FF9170ED; Thu, 14 Jul 2005 00:56:07 -0700 (PDT) To: Sam Hartman Subject: Re: [Isms] TLS and DTLS should not be considered together References: From: Eric Rescorla Date: Thu, 14 Jul 2005 00:56:07 -0700 In-Reply-To: (Sam Hartman's message of "Wed, 13 Jul 2005 17:28:17 -0400") Message-ID: <86ackpddns.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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Sam Hartman writes: > Hi. Just a reminder that the natural way to do authentication with > TLS (TLS+SASL) is not such a good option with DTLS. It's absolutely true that SASL over DTLS is not straightforward. However, it seems to me that this is a generic observation about any datagram approach, no? I.e., the problem is that SASL wasn't designed to work over unreliable channels. So, if you're going to do inband keying and you want an unreliable channel, you've got to face this... (I'm not qualified to have an opinion about whether you *should* want to use UDP, just saying that if you do want to...) -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 14 12:06:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt6E2-00027l-Qx; Thu, 14 Jul 2005 12:06:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt6E1-00027M-6G for isms@megatron.ietf.org; Thu, 14 Jul 2005 12:06:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25178 for ; Thu, 14 Jul 2005 12:06:10 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt6gd-0008OY-V4 for isms@ietf.org; Thu, 14 Jul 2005 12:35:49 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 68A41E0049; Thu, 14 Jul 2005 12:06:01 -0400 (EDT) To: EKR Subject: Re: [Isms] TLS and DTLS should not be considered together References: <86ackpddns.fsf@romeo.rtfm.com> From: Sam Hartman Date: Thu, 14 Jul 2005 12:06:01 -0400 In-Reply-To: <86ackpddns.fsf@romeo.rtfm.com> (Eric Rescorla's message of "Thu, 14 Jul 2005 00:56:07 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Eric" == Eric Rescorla writes: Eric> Sam Hartman writes: >> Hi. Just a reminder that the natural way to do authentication >> with TLS (TLS+SASL) is not such a good option with DTLS. Eric> It's absolutely true that SASL over DTLS is not Eric> straightforward. Yes, but I don't know of any other datagram approaches being considered. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 15 12:18:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtStu-00074X-NR; Fri, 15 Jul 2005 12:18:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtStt-00074S-Pm for isms@megatron.ietf.org; Fri, 15 Jul 2005 12:18:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22560 for ; Fri, 15 Jul 2005 12:18:54 -0400 (EDT) Message-Id: <200507151618.MAA22560@ietf.org> Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtTMk-0007vu-CC for isms@ietf.org; Fri, 15 Jul 2005 12:48:46 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <2005071516184801400mkhode>; Fri, 15 Jul 2005 16:18:48 +0000 From: "David B Harrington" To: Date: Fri, 15 Jul 2005 12:18:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWJWN7Lhhz/1s8dQ6C91o4e6IXLdg== X-Spam-Score: 0.1 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] Comments on the BTSMS proposal X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, This draft was obviously done quickly to get it in under the deadline, so understandably has some things not well described yet. Here are a few comments: 1) What do BTSM (from the filename) and BTSMS (the title abbreviation) stand for? Is that BEEP Transport Mapping Security Model? If so, the acronym is wrong. It should be BTMSM. Or is it BEEP Transport Security Model? It obviously isn't an acronym for "A BEEP Profile for SNMPv3 PDUs" 2) Make the transport security selection transparent, not opaque. I don't feel comfortable having one BEEP transport mapping that might use only TLS or might user TLS with SASL or some other combination of underlying protocols. I think TLS and SASL-over-TLS probably meet different security requirements, so should be considered different BEEP profiles, different SNMP transport mappings, and different SNMP security models. SNMP-over-BEEP seems too opaque to be useful for security purposes. 3) Separate the transport issues from the security-mapping issues. I suggest breaking your proposal into two proposals: 1) an SNMP transport mapping for SNMP over BEEP, which gives you flexible ways to transport SNMP messages, that subsequently use USM or other authentication security model to determine the SNMP securityName and securityLevel, and 2) a TMSM security model that uses the SNMP-over-BEEP transport, and in addition maps the authenticated identity from the BEEP transport to an SNMP securityName and securityLevel. Doing this would help separate the issues of a BEEP transport, such as session establishment and channel initiation and response to a lost session, from the issues of mapping transport security to SNMP securityName and securitylevel. 4) Identify certain requirements for each securityLevel. For SNMP access control to function properly, the security mechanism must establish a security model identifier, a securityLevel, and a securityName. The document does not discuss how to determine the securitylevel. The SNMPv1/SNMPv2c security model uses plain text passwords, so the securitylevel is noAuthNoPriv. Given the wide variation of options supported by BEEP, how does one determine the securityLevel for SNMP purposes? There needs to be a mechanism by which the BEEP TMSM (as compared to the BEEP profile or the SNMP-over-BEEP transport mapping) identifies the securityLevel used for the message. This will probably require a set of clearly defined requirements to qualify for each securityLevel (and might be better in a generic TMSM document rather than being BEEP-specific). 5) Identify the source for the securityName. For SNMP access control to function properly, the security mechanism must establish a security model identifier, a securityLevel, and a securityName. The document does not discuss how to determine the securityName. How is the translation from a mechanisms-specific authenticated identity to a securityName done? What BEEP interface will provide this translation from TLS or from SASL to SNMP? If this translation is done as per the TLS cache approach of the TMSM design, then what benefit does BEEP add to a direct SNMP-over-TLS solution or a direct SNMP-over-SASL solution? 6) I am concerned about the discussion of using engineID as an identifier rather than securityName. First, this does not seem consistent with RFC3411 architecture, where engineID is never used as the principal, and second, the engineID is not authenticated. It may be possible to authenticate the engineID or provide a mapping between the authenticated identity and an engineID (why use this rarther than securityname?), but this will require much more discussion about the implications of such an architectural change. 7) The requirements for compliance need to be unambiguous. The specification needs to provide more MUSTs and fewer SHOULDS/options so we can assess how secure the resulting solution is. If I select an SNMP-over-SASL BEEP profile (and transport mapping and TMSM), then I'd like to know whether that means DIGEST or PLAIN security will be used; vendors shouldn't be allowed to implement a wide array of options that make it impossible to assess the security characteristics of the solution. Maybe this will require defining specific "profiles" of the BEEP TMSM (as compared to the BEEP profiles or SNMP transport mappings) for various combinations of options. 8) Auto-discovery should be supported. There should be a mechanism for SNMP managers to auto-discover SNMP-capable devices; this was one of the killers of SNMPv2 party security. We cannot make this secure in a manner that prevents existing applications that provide autodiscovery from having an approach to continue providing this feature. Obviously the mechanism can change, but no application vendor will be willing to move to the new approach if they are burdened with telling their customers that auto-discovery is discontinued, and operators will now have to manually "discover" the SNMP agents, and manually configure their topology maps. That simply won't fly. This is a topic that requires further discussion for any TMSM model or any new security model, but will need to be discussed by each proposed model. If a BEEP transport mapping can accommodate not only a secure channel over TLS or SASL, but also a non-secure NoAuthNoPriv option for autodiscovery, possibly over UDP, I think that would be a good thing. Maybe a BEEP transport mapping could use two different BEEP profiles to accomplish this. Of course, two different transport mappings (SNMP-over-UDP and SNMP-over-BEEP) might accomplish the same thing more simply. 9) How will SNMP-over-BEEP impact the SNMPv3 message fields? Since the BEEP transport simply carries SNMPv3 messages in ASN.1 format, there needs to be some discussion of how the SNMPv3 message fields get filled in, and what they mean. How do they impact the Elements of Procedure discussed in RFC3412 and elsewhere? In particular, how will the securityParameters be impacted? How will the BEEP TMSM handle msgFlags? 10) How will SNMP-over-BEEP impact the SNMPv3 Elements of Procedure? Is there an authoritative engine that still applies? (This is a generic TMSM issue). What information needs to be securityStateReference cached for incoming and outgoing messages? When can the cache be discarded? 11) Coexistence needs to be discussed. For any new security model, we will need to discuss how the new security model will coexist with SNMPv1 and SNMPv2c (and SNMPv3). See RFC 3584 for an example. Since the BEEP transport simply carries SNMPv3 messages in ASN.1 format, it could presumably be used to carry ASN.1 messages in the SNMPv1 and SNMPv2 formats. Since the BEEP TMSM provides the mapping to authenticate the principal and securityLevel, can this be used to provide an authenticated principal for SNMPv1 and SNMPv2c messages, so that SNMPv1 and SNMPv2c can now be used reasonably with VACM or other SNMPv2 access control? -- Hope this is enough to start the discussion, David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jul 16 14:16:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrDA-0006Yb-Cn; Sat, 16 Jul 2005 14:16:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrD8-0006Y0-7d for isms@megatron.ietf.org; Sat, 16 Jul 2005 14:16:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19314 for ; Sat, 16 Jul 2005 14:16:21 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtpcH-0007Ki-CK for isms@ietf.org; Sat, 16 Jul 2005 12:34:19 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 16 Jul 2005 09:04:07 -0700 X-IronPort-AV: i="3.93,295,1115017200"; d="scan'208"; a="198722327:sNHT31388780" Received: from kaushik-w2k03.cisco.com (sjc-vpn6-566.cisco.com [10.21.122.54]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6GG446q006981; Sat, 16 Jul 2005 09:04:05 -0700 (PDT) Message-Id: <6.2.0.14.0.20050716085654.050846a8@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sat, 16 Jul 2005 09:03:55 -0700 To: dbharrington@comcast.net From: Kaushik Narayan Subject: Re: [Isms] Comments on the BTSMS proposal In-Reply-To: <200507151618.MAA22560@ietf.org> References: <200507151618.MAA22560@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI David, Thanks for your comments. Some clarifications inline. At 09:18 AM 7/15/2005, David B Harrington wrote: >Hi, > >This draft was obviously done quickly to get it in under the deadline, >so understandably has some things not well described yet. Here are a >few comments: > >1) What do BTSM (from the filename) and BTSMS (the title abbreviation) >stand for? Is that BEEP Transport Mapping Security Model? If so, the >acronym is wrong. It should be BTMSM. Or is it BEEP Transport Security >Model? It obviously isn't an acronym for "A BEEP Profile for SNMPv3 >PDUs" The draft specifies a BEEP Transport Mapping Security Model, ideally we would have liked the file name to btmsm but since -00 version was already submitted with btsm, we thought it would be too painful to change the file name. >2) Make the transport security selection transparent, not opaque. > >I don't feel comfortable having one BEEP transport mapping that might >use only TLS or might user TLS with SASL or some other combination of >underlying protocols. I think TLS and SASL-over-TLS probably meet >different security requirements, so should be considered different >BEEP profiles, different SNMP transport mappings, and different SNMP >security models. SNMP-over-BEEP seems too opaque to be useful for >security purposes. We were planning to define a single BEEP profile that uses TLS + SASL, with TLS for channel protection and SASL for authentication only, we do not plan to use SASL for channel protection. We haven't thought about more than one BEEP profile but I would not like to preclude that without some more consideration. >3) Separate the transport issues from the security-mapping issues. > >I suggest breaking your proposal into two proposals: >1) an SNMP transport mapping for SNMP over BEEP, which gives you >flexible ways to transport SNMP messages, that subsequently use USM or >other authentication security model to determine the SNMP securityName >and securityLevel, and >2) a TMSM security model that uses the SNMP-over-BEEP transport, and >in addition maps the authenticated identity from the BEEP transport to >an SNMP securityName and securityLevel. > >Doing this would help separate the issues of a BEEP transport, such as >session establishment and channel initiation and response to a lost >session, from the issues of mapping transport security to SNMP >securityName and securitylevel. Do you believe that there is value in a BEEP transport mapping with USM ? I always thought BEEP was interesting as a transport since it provided the security services and integration with authentication systems that does not exist with USM. >4) Identify certain requirements for each securityLevel. > >For SNMP access control to function properly, the security mechanism >must establish a security model identifier, a securityLevel, and a >securityName. The document does not discuss how to determine the >securitylevel. > >The SNMPv1/SNMPv2c security model uses plain text passwords, so the >securitylevel is noAuthNoPriv. Given the wide variation of options >supported by BEEP, how does one determine the securityLevel for SNMP >purposes? > >There needs to be a mechanism by which the BEEP TMSM (as compared to >the BEEP profile or the SNMP-over-BEEP transport mapping) identifies >the securityLevel used for the message. This will probably require a >set of clearly defined requirements to qualify for each securityLevel >(and might be better in a generic TMSM document rather than being >BEEP-specific). I believe that the management of securityLevel must happen within the TMSM framework and TMSP needs to be able flag an error if the underlying transport layer cannot meet the securityLevel as specified in the SNMP message. >5) Identify the source for the securityName. > >For SNMP access control to function properly, the security mechanism >must establish a security model identifier, a securityLevel, and a >securityName. The document does not discuss how to determine the >securityName. > >How is the translation from a mechanisms-specific authenticated >identity to a securityName done? What BEEP interface will provide this >translation from TLS or from SASL to SNMP? > >If this translation is done as per the TLS cache approach of the TMSM >design, then what benefit does BEEP add to a direct SNMP-over-TLS >solution or a direct SNMP-over-SASL solution? We are still working on the interfaces between the TMSP and MPSP for the BEEP TMSM. >6) I am concerned about the discussion of using engineID as an >identifier rather than securityName. First, this does not seem >consistent with RFC3411 architecture, where engineID is never used as >the principal, and second, the engineID is not authenticated. > >It may be possible to authenticate the engineID or provide a mapping >between the authenticated identity and an engineID (why use this >rarther than securityname?), but this will require much more >discussion about the implications of such an architectural change. I would like to clarify that the draft discusses the use of the engineID as an identifier in addition to the use of the securityName. The SNMP securityName identifies the client principal, in addition the TLS channel will need to be authenticated and SNMP engine acting as the TLS server will require to be identified. >7) The requirements for compliance need to be unambiguous. > >The specification needs to provide more MUSTs and fewer >SHOULDS/options so we can assess how secure the resulting solution is. >If I select an SNMP-over-SASL BEEP profile (and transport mapping and >TMSM), then I'd like to know whether that means DIGEST or PLAIN >security will be used; vendors shouldn't be allowed to implement a >wide array of options that make it impossible to assess the security >characteristics of the solution. > >Maybe this will require defining specific "profiles" of the BEEP TMSM >(as compared to the BEEP profiles or SNMP transport mappings) for >various combinations of options. We would like to make SASL DIGEST mandatory but as stated in the Security Considerations of the -01 draft, MD5 digest authentication is not supported by most RADIUS implementations and we need to rely on PLAIN (RADIUS PAP). >8) Auto-discovery should be supported. > >There should be a mechanism for SNMP managers to auto-discover >SNMP-capable devices; this was one of the killers of SNMPv2 party >security. We cannot make this secure in a manner that prevents >existing applications that provide autodiscovery from having an >approach to continue providing this feature. Obviously the mechanism >can change, but no application vendor will be willing to move to the >new approach if they are burdened with telling their customers that >auto-discovery is discontinued, and operators will now have to >manually "discover" the SNMP agents, and manually configure their >topology maps. That simply won't fly. > >This is a topic that requires further discussion for any TMSM model or >any new security model, but will need to be discussed by each proposed >model. > >If a BEEP transport mapping can accommodate not only a secure channel >over TLS or SASL, but also a non-secure NoAuthNoPriv option for >autodiscovery, possibly over UDP, I think that would be a good thing. >Maybe a BEEP transport mapping could use two different BEEP profiles >to accomplish this. Of course, two different transport mappings >(SNMP-over-UDP and SNMP-over-BEEP) might accomplish the same thing >more simply. > >9) How will SNMP-over-BEEP impact the SNMPv3 message fields? > >Since the BEEP transport simply carries SNMPv3 messages in ASN.1 >format, there needs to be some discussion of how the SNMPv3 message >fields get filled in, and what they mean. How do they impact the >Elements of Procedure discussed in RFC3412 and elsewhere? > >In particular, how will the securityParameters be impacted? > >How will the BEEP TMSM handle msgFlags? > >10) How will SNMP-over-BEEP impact the SNMPv3 Elements of Procedure? > >Is there an authoritative engine that still applies? (This is a >generic TMSM issue). > >What information needs to be securityStateReference cached for >incoming and outgoing messages? When can the cache be discarded? Handling of SNMPv3 message fields and definition of the stateReference attributes passed between the TMSP and MPSP will be specified in the next revision. >11) Coexistence needs to be discussed. > >For any new security model, we will need to discuss how the new >security model will coexist with SNMPv1 and SNMPv2c (and SNMPv3). See >RFC 3584 for an example. > >Since the BEEP transport simply carries SNMPv3 messages in ASN.1 >format, it could presumably be used to carry ASN.1 messages in the >SNMPv1 and SNMPv2 formats. Since the BEEP TMSM provides the mapping to >authenticate the principal and securityLevel, can this be used to >provide an authenticated principal for SNMPv1 and SNMPv2c messages, so >that SNMPv1 and SNMPv2c can now be used reasonably with VACM or other >SNMPv2 access control? Isn't the coexistence issue something that we need to discuss in the overall TMSM context. regards, kaushik! >-- >Hope this is enough to start the discussion, >David Harrington >dbharrington@comcast.net > > > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 20 12:23:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvHMG-0005K5-5x; Wed, 20 Jul 2005 12:23:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvHME-0005Jx-QY for isms@megatron.ietf.org; Wed, 20 Jul 2005 12:23:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06605 for ; Wed, 20 Jul 2005 12:23:37 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvHq2-0007ep-8v for isms@ietf.org; Wed, 20 Jul 2005 12:54:32 -0400 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j6KGLoV29622 for ; Wed, 20 Jul 2005 12:21:50 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jul 2005 12:23:14 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B404315C78@zcarhxm2.corp.nortel.com> Thread-Topic: Reading List for Paris? thread-index: AcWNR1R1a1aTMp0/QHaMMhSP/FmtNg== From: "Sharon Chisholm" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Isms] Reading List for Paris? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org hi I've seen the Beep stuff go by and assume that the Transport Mapping Security Model stuff is still active. So, is this our list of active documents or are more still in play? http://www.ietf.org/internet-drafts/draft-kaushik-isms-btsm-01.txt http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-02.txt Sharon Chisholm Nortel=20 Ottawa, Ontario Canada _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 22 16:01:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw3iS-0005uL-UD; Fri, 22 Jul 2005 16:01:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw3iQ-0005t3-PC for isms@megatron.ietf.org; Fri, 22 Jul 2005 16:01:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18153 for ; Fri, 22 Jul 2005 16:01:47 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw4Ci-0004dX-QN for isms@ietf.org; Fri, 22 Jul 2005 16:33:09 -0400 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id E2652DC08 for ; Fri, 22 Jul 2005 22:01:22 +0200 (CEST) Received: from [10.1.1.171] ([10.1.1.171]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jul 2005 22:01:22 +0200 Date: Fri, 22 Jul 2005 22:01:29 +0200 From: Juergen Quittek To: isms@ietf.org Message-ID: <62335A94F69AF6FC5BA2CEA8@[10.1.1.171]> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2005 20:01:22.0838 (UTC) FILETIME=[224C3360:01C58EF8] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] draft agenda for Paris X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dear all, Below please find a draft agenda for our session in Paris. Please comment and suggest changes. I assume that we will have presenters for TLSM and BTSM. Can the presenters confirm this? Would someone be willing to prepare a few slides for starting the transport protocol selection discussion? Preferably by listing differences, advantages, and disadvantages of the protocols that are being discussed on the mailing list. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de ============================================= Integrated Security Model for SNMP WG (isms) IETF #63 Thursday August 4, 2005 : 1030-1230 ============================================ Chairs: Ken Hornstein Juergen Quittek AGENDA: 1) Agenda bashing, WG Status ( 5 min) 2) Update of the TLSM proposal (15 min) - draft-schoenw-snmp-tlsm-02.txt 5) A BEEP Profile for SNMPv3 PDUs (20 min) - draft-kaushik-isms-btsm-01.txt 3) Selection of the ISMS transport protocol (60 min) 4) Charter discussion (optional) (15 min) 6) Wrap up ( 5 min) - action points, schedule for charter INTERNET DRAFTS: Transport Layer Security Model (TLSM) for the Simple Network Management Protocol version 3 (SNMPv3) http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-02.txt A BEEP Profile for SNMPv3 PDUs http://www.ietf.org/internet-drafts/draft-kaushik-isms-btsm-01.txt _______________________________________________ isms mailing list isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 22 16:39:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw4J6-0001bf-Kd; Fri, 22 Jul 2005 16:39:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw4J5-0001bY-1C for isms@megatron.ietf.org; Fri, 22 Jul 2005 16:39:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25099 for ; Fri, 22 Jul 2005 16:39:40 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw4nN-0007U8-8U for isms@ietf.org; Fri, 22 Jul 2005 17:11:02 -0400 Received: from pc6 (1Cust247.tnt106.lnd4.gbr.da.uu.net [213.116.60.247]) by astro.systems.pipex.net (Postfix) with SMTP id 2B08FE000172 for ; Fri, 22 Jul 2005 21:39:17 +0100 (BST) Message-ID: <089201c58ef4$ef6eaf20$0601a8c0@pc6> From: "Tom Petch" To: References: <3DEC199BD7489643817ECA151F7C59290103F269@pysmsx401.amr.corp.intel.com> <025501c54a7d$663bf520$0601a8c0@pc6> Date: Fri, 22 Jul 2005 21:37:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] securityName X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org When we were debating which approach to take, one issue that kept surfacing was the use of securityName; I do not think that choosing an approach has solved that problem. We may have a secure pipe from Command Generator to Command Responder so a securityName can be safely transmitted from one party to another but I do not see how that can then be used. I take (model independent) securityName as a given, from SNMPv3 Architecture and from VACM (both of which the charter requires us to adhere to). So within an agent (a low powered, low function, remote Command Responder), there must be a securityName which is used to index into the vacmSecurityToGroupTable. If that information is stored permanently within the agent, then we have the maintenance problem that led to the need for isms in the first place. (I see this as particularly acute when there is a need speedily to remove security credentials from a principal across a network with thousands of agents). If the information is stored dynamically, then part of session setup needs to create the relevant entries in the agent which then need to be safely removed at end of session (whatever a session might be). Or the information can be obtained as and when needed by the agent from a security server but what does this require the agent to have in the way of extra protocol support? The preference I expressed earlier was to have predefined generic entries in the agent with the manager (which I assume has got all the necessary access to the security infrastructure) providing a mapping from the securityName it knows which is sent over the secure pipe, but I recognise that that could be construed as not integrating adequately with existing security infrastructure. So, regardless of SSH or TLS or ... I do not see a good solution to this problem. Any ideas? Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 22 18:31:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw634-0003kY-J8; Fri, 22 Jul 2005 18:31:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw632-0003jd-NJ for isms@megatron.ietf.org; Fri, 22 Jul 2005 18:31:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07496 for ; Fri, 22 Jul 2005 18:31:13 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw6XK-00042a-0d for isms@ietf.org; Fri, 22 Jul 2005 19:02:36 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Jul 2005 15:31:03 -0700 Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6MMV1JM019416; Fri, 22 Jul 2005 15:31:01 -0700 (PDT) Message-Id: <6.2.0.14.0.20050722152729.0411f7f8@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 22 Jul 2005 15:31:01 -0700 To: Tom Petch From: Kaushik Narayan Subject: Re: [Isms] securityName In-Reply-To: <089201c58ef4$ef6eaf20$0601a8c0@pc6> References: <3DEC199BD7489643817ECA151F7C59290103F269@pysmsx401.amr.corp.intel.com> <025501c54a7d$663bf520$0601a8c0@pc6> <089201c58ef4$ef6eaf20$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Tom, I think the assumption at least in my mind has been that the securityName would be stored part of a session object that is created after a successful security context has been created at the transport layer. This session object MUST be managed by the new security model which would be responsible for clean up as sessions are invalidated. regards, kaushik! At 12:37 PM 7/22/2005, Tom Petch wrote: >When we were debating which approach to take, one issue that kept >surfacing was >the use of securityName; I do not think that choosing an approach has solved >that problem. We may have a secure pipe from Command Generator to Command >Responder >so a securityName can be safely transmitted from one party to another but I do >not see how that can then be used. > >I take (model independent) securityName as a given, from SNMPv3 >Architecture and >from VACM (both of which the charter requires us to adhere to). So within an >agent (a low powered, low function, remote Command Responder), there must be a >securityName which is used to index into the vacmSecurityToGroupTable. > >If that information is stored permanently within the agent, then we have the >maintenance problem that led to the need for isms in the first place. (I see >this as particularly acute when there is a need speedily to remove security >credentials from a principal across a network with thousands of agents). > >If the information is stored dynamically, then part of session setup needs to >create the relevant entries in the agent which then need to be safely >removed at >end of session (whatever a session might be). > >Or the information can be obtained as and when needed by the agent from a >security server but what does this require the agent to have in the way of >extra >protocol support? > >The preference I expressed earlier was to have predefined generic entries >in the >agent with the manager (which I assume has got all the necessary access to the >security infrastructure) providing a mapping from the securityName it knows >which is sent >over the secure pipe, but I recognise that that could be construed as not >integrating adequately with existing security infrastructure. > >So, regardless of SSH or TLS or ... I do not see a good solution to this >problem. > >Any ideas? > >Tom Petch > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 22 19:24:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw6sf-0000tt-2h; Fri, 22 Jul 2005 19:24:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw6sd-0000to-5I for isms@megatron.ietf.org; Fri, 22 Jul 2005 19:24:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11096 for ; Fri, 22 Jul 2005 19:24:31 -0400 (EDT) Message-Id: <200507222324.TAA11096@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw7Mx-0005s9-Rv for isms@ietf.org; Fri, 22 Jul 2005 19:55:56 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc12) with SMTP id <2005072223242501200a0qqre>; Fri, 22 Jul 2005 23:24:25 +0000 From: "David B Harrington" To: "'Tom Petch'" , Subject: RE: [Isms] securityName Date: Fri, 22 Jul 2005 19:24:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWO/hoPkSoP3QGHRpiSrJN+otSoQwABhiqw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <089201c58ef4$ef6eaf20$0601a8c0@pc6> X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Tom, There is not necessarily a need to statically store the securityName on the system. A MIB is made available for specifying the mapping from a model-dependent name to a model-independent name, because some models may require a static mapping function. In USM, the mapping function is not really needed - the mapping function simply uses the model-specific name as the securityName. Of course, the USM model-dependent name (and implicitly the securityName) is already stored statically on the system, which is the concern ISMS is trying to resolve. If a security model can provide a dynamic identity mapping, such as translating from the authenticated transport identity (e.g. SSH user) to securityName, then the mapping may not need to be stored in a MIB module. It might be a desirable to store the dynamic mapping in a MIB module to enable monitoring of the authentications, or even to support static mappings to a single securityName from multiple model-dependent identities, such as a USM user and an SNMPv1 communityname and an SSH username, for example. That said, ISMS is not addressing the problem of having a static mapping from securityName to access control policies. I expect that once we resolve the need to use static storage of model-dependent identities to map to securityName, we will then start work to resolve the need to have static mappings from securityName to access control policies, and we will need to decide if having mappings from multiple security model identities to a common securityName is still desired. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Tom Petch > Sent: Friday, July 22, 2005 3:38 PM > To: isms@ietf.org > Subject: [Isms] securityName > > When we were debating which approach to take, one issue that > kept surfacing was > the use of securityName; I do not think that choosing an > approach has solved > that problem. We may have a secure pipe from Command > Generator to Command > Responder > so a securityName can be safely transmitted from one party to > another but I do > not see how that can then be used. > > I take (model independent) securityName as a given, from > SNMPv3 Architecture and > from VACM (both of which the charter requires us to adhere > to). So within an > agent (a low powered, low function, remote Command > Responder), there must be a > securityName which is used to index into the vacmSecurityToGroupTable. > > If that information is stored permanently within the agent, > then we have the > maintenance problem that led to the need for isms in the > first place. (I see > this as particularly acute when there is a need speedily to > remove security > credentials from a principal across a network with thousands > of agents). > > If the information is stored dynamically, then part of > session setup needs to > create the relevant entries in the agent which then need to > be safely removed at > end of session (whatever a session might be). > > Or the information can be obtained as and when needed by the > agent from a > security server but what does this require the agent to have > in the way of extra > protocol support? > > The preference I expressed earlier was to have predefined > generic entries in the > agent with the manager (which I assume has got all the > necessary access to the > security infrastructure) providing a mapping from the > securityName it knows > which is sent > over the secure pipe, but I recognise that that could be > construed as not > integrating adequately with existing security infrastructure. > > So, regardless of SSH or TLS or ... I do not see a good > solution to this > problem. > > Any ideas? > > Tom Petch > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 22 19:31:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw6zZ-0003Um-9U; Fri, 22 Jul 2005 19:31:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw6zX-0003Uh-Cv for isms@megatron.ietf.org; Fri, 22 Jul 2005 19:31:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11356 for ; Fri, 22 Jul 2005 19:31:39 -0400 (EDT) Message-Id: <200507222331.TAA11356@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw7Ts-00062Z-7B for isms@ietf.org; Fri, 22 Jul 2005 20:03:04 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005072223313401100kik0ce>; Fri, 22 Jul 2005 23:31:34 +0000 From: "David B Harrington" To: "'Juergen Quittek'" , Subject: RE: [Isms] draft agenda for Paris Date: Fri, 22 Jul 2005 19:31:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWO+IaHG/c1gEhrQeeSSQ8z1lLSqQACimFA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <62335A94F69AF6FC5BA2CEA8@[10.1.1.171]> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I will not be in Paris. TLSM/TMSM has been presented at earlier meetings. I'm not sure it has changed that much. I do intend to monitor via streaming audio, and participate via Jabber, so I can answer questions about TMSM. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen Quittek > Sent: Friday, July 22, 2005 4:01 PM > To: isms@ietf.org > Subject: [Isms] draft agenda for Paris > > Dear all, > > Below please find a draft agenda for our session in Paris. > > Please comment and suggest changes. > > I assume that we will have presenters for TLSM and BTSM. > Can the presenters confirm this? > > Would someone be willing to prepare a few slides for starting > the transport protocol selection discussion? > Preferably by listing differences, advantages, and disadvantages > of the protocols that are being discussed on the mailing list. > > Thanks, > > Juergen > -- > Juergen Quittek quittek@netlab.nec.de Tel: +49 > 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 > 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > http://www.netlab.nec.de > > > ============================================= > Integrated Security Model for SNMP WG (isms) > IETF #63 > Thursday August 4, 2005 : 1030-1230 > ============================================ > > Chairs: > Ken Hornstein > Juergen Quittek > > AGENDA: > > 1) Agenda bashing, WG Status ( 5 min) > > 2) Update of the TLSM proposal (15 min) > - draft-schoenw-snmp-tlsm-02.txt > > 5) A BEEP Profile for SNMPv3 PDUs (20 min) > - draft-kaushik-isms-btsm-01.txt > > 3) Selection of the ISMS transport protocol (60 min) > > 4) Charter discussion (optional) (15 min) > > 6) Wrap up ( 5 min) > - action points, schedule for charter > > > INTERNET DRAFTS: > > Transport Layer Security Model (TLSM) for the Simple Network > Management Protocol version 3 (SNMPv3) > http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-02.txt > > A BEEP Profile for SNMPv3 PDUs > http://www.ietf.org/internet-drafts/draft-kaushik-isms-btsm-01.txt > > > _______________________________________________ > isms mailing list > isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jul 23 02:32:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwDZ8-0002zv-Bl; Sat, 23 Jul 2005 02:32:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwDZ5-0002z8-2G for isms@megatron.ietf.org; Sat, 23 Jul 2005 02:32:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05475 for ; Sat, 23 Jul 2005 02:32:49 -0400 (EDT) Received: from ib74a.i.pppool.de ([85.73.183.74] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwE3T-0001Sh-Cb for isms@ietf.org; Sat, 23 Jul 2005 03:04:15 -0400 Received: by boskop.local (Postfix, from userid 501) id 18492392B7E; Sat, 23 Jul 2005 08:32:34 +0200 (CEST) Date: Sat, 23 Jul 2005 08:32:34 +0200 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Isms] draft agenda for Paris Message-ID: <20050723063234.GB21724@boskop.local> Mail-Followup-To: David B Harrington , 'Juergen Quittek' , isms@ietf.org References: <62335A94F69AF6FC5BA2CEA8@[10.1.1.171]> <200507222331.TAA11356@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200507222331.TAA11356@ietf.org> User-Agent: Mutt/1.5.9i 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: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Fri, Jul 22, 2005 at 07:31:28PM -0400, David B Harrington wrote: > I will not be in Paris. > > TLSM/TMSM has been presented at earlier meetings. I'm not sure it has > changed that much. I will be in Paris at the ISMS meeting. However, I agree with David that we should not waste valuable time on too many presentations. Instead, I believe it would be much more valuable if we can work through a list of well phrased open questions and ideally such a list would be created on the mailing list well in advance of the face to face meeting so that one can make effective use of the face to face time. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jul 23 10:36:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwL7E-0005br-8L; Sat, 23 Jul 2005 10:36:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwL7C-0005ba-Qm for isms@megatron.ietf.org; Sat, 23 Jul 2005 10:36:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29408 for ; Sat, 23 Jul 2005 10:36:32 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwLbe-00074q-Ft for isms@ietf.org; Sat, 23 Jul 2005 11:08:02 -0400 Received: from pc6 (1Cust188.tnt102.lnd4.gbr.da.uu.net [213.116.52.188]) by astro.systems.pipex.net (Postfix) with SMTP id 484C8E0000F5; Sat, 23 Jul 2005 15:36:16 +0100 (BST) Message-ID: <00dc01c58f8b$61132d40$0601a8c0@pc6> From: "Tom Petch" To: "Kaushik Narayan" References: <3DEC199BD7489643817ECA151F7C59290103F269@pysmsx401.amr.corp.intel.com> <025501c54a7d$663bf520$0601a8c0@pc6> <089201c58ef4$ef6eaf20$0601a8c0@pc6> <6.2.0.14.0.20050722152729.0411f7f8@email.cisco.com> Subject: Re: [Isms] securityName Date: Sat, 23 Jul 2005 15:26:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Kaushik Narayan" To: "Tom Petch" Sent: Saturday, July 23, 2005 12:31 AM > > I think the assumption at least in my mind has been that the > securityName would be stored part of a session object that > is created after a successful security context has been > created at the transport layer. This session object MUST be > managed by the new security model which would be responsible > for clean up as sessions are invalidated. > > kaushik! > Two queries. 1) I see a secure pipe between manager and agent over which PDU from multiple securityName are multiplexed; when you say session, is that per securityName or per manager-agent pair? eg SSH has a host key which can be used to create a secure pipe but I did not envisage that as fine enough granularity to differentiate separate securityName 2) when does the entry in the vacmSecurityToGroupTable get created, when destroyed w.r.t. a session? I see maintenance of that table as a problem. > > At 12:37 PM 7/22/2005, Tom Petch wrote: > >When we were debating which approach to take, one issue that kept > >surfacing was > >the use of securityName; I do not think that choosing an approach has solved > >that problem. We may have a secure pipe from Command Generator to Command > >Responder > >so a securityName can be safely transmitted from one party to another but I do > >not see how that can then be used. > > > >I take (model independent) securityName as a given, from SNMPv3 > >Architecture and > >from VACM (both of which the charter requires us to adhere to). So within an > >agent (a low powered, low function, remote Command Responder), there must be a > >securityName which is used to index into the vacmSecurityToGroupTable. > > > >If that information is stored permanently within the agent, then we have the > >maintenance problem that led to the need for isms in the first place. (I see > >this as particularly acute when there is a need speedily to remove security > >credentials from a principal across a network with thousands of agents). > > > >If the information is stored dynamically, then part of session setup needs to > >create the relevant entries in the agent which then need to be safely > >removed at > >end of session (whatever a session might be). > > > >Or the information can be obtained as and when needed by the agent from a > >security server but what does this require the agent to have in the way of > >extra > >protocol support? > > > >The preference I expressed earlier was to have predefined generic entries > >in the > >agent with the manager (which I assume has got all the necessary access to the > >security infrastructure) providing a mapping from the securityName it knows > >which is sent > >over the secure pipe, but I recognise that that could be construed as not > >integrating adequately with existing security infrastructure. > > > >So, regardless of SSH or TLS or ... I do not see a good solution to this > >problem. > > > >Any ideas? > > > >Tom Petch > > > > > >_______________________________________________ > >Isms mailing list > >Isms@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jul 23 10:36:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwL7E-0005cF-FT; Sat, 23 Jul 2005 10:36:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwL7C-0005bZ-Of for isms@megatron.ietf.org; Sat, 23 Jul 2005 10:36:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29405 for ; Sat, 23 Jul 2005 10:36:31 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwLbc-00074l-5K for isms@ietf.org; Sat, 23 Jul 2005 11:08:02 -0400 Received: from pc6 (1Cust188.tnt102.lnd4.gbr.da.uu.net [213.116.52.188]) by astro.systems.pipex.net (Postfix) with SMTP id 526F2E00005D; Sat, 23 Jul 2005 15:36:13 +0100 (BST) Message-ID: <00db01c58f8b$60176820$0601a8c0@pc6> From: "Tom Petch" To: , "David B Harrington" References: <62335A94F69AF6FC5BA2CEA8@[10.1.1.171]><200507222331.TAA11356@ietf.org> <20050723063234.GB21724@boskop.local> Subject: Re: [Isms] draft agenda for Paris Date: Sat, 23 Jul 2005 15:16:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "David B Harrington" Cc: Sent: Saturday, July 23, 2005 8:32 AM Subject: Re: [Isms] draft agenda for Paris > On Fri, Jul 22, 2005 at 07:31:28PM -0400, David B Harrington wrote: > > > I will not be in Paris. > > > > TLSM/TMSM has been presented at earlier meetings. I'm not sure it has > > changed that much. > > I will be in Paris at the ISMS meeting. However, I agree with David that > we should not waste valuable time on too many presentations. Instead, > I believe it would be much more valuable if we can work through a list > of well phrased open questions and ideally such a list would be created > on the mailing list well in advance of the face to face meeting so that > one can make effective use of the face to face time. > I would go further, or less far, and say that producing a list of well-phrased open questions would be a most productive output to have from the face-to-face time in Paris. Listening to presentations on I-Ds I could have read months ago has never seemed worth travelling for. Tom _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jul 23 12:15:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwMbj-0005bc-RJ; Sat, 23 Jul 2005 12:12:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwMbh-0005aY-N1 for isms@megatron.ietf.org; Sat, 23 Jul 2005 12:12:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05727 for ; Sat, 23 Jul 2005 12:12:06 -0400 (EDT) Received: from i8ecb.i.pppool.de ([85.73.142.203] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwN6A-0001nV-5j for isms@ietf.org; Sat, 23 Jul 2005 12:43:39 -0400 Received: by boskop.local (Postfix, from userid 501) id CEC10393410; Sat, 23 Jul 2005 18:11:52 +0200 (CEST) Date: Sat, 23 Jul 2005 18:11:52 +0200 From: Juergen Schoenwaelder To: Tom Petch Subject: Re: [Isms] securityName Message-ID: <20050723161152.GA22952@boskop.local> Mail-Followup-To: Tom Petch , Kaushik Narayan , isms@ietf.org References: <3DEC199BD7489643817ECA151F7C59290103F269@pysmsx401.amr.corp.intel.com> <025501c54a7d$663bf520$0601a8c0@pc6> <089201c58ef4$ef6eaf20$0601a8c0@pc6> <6.2.0.14.0.20050722152729.0411f7f8@email.cisco.com> <00dc01c58f8b$61132d40$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00dc01c58f8b$61132d40$0601a8c0@pc6> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Sat, Jul 23, 2005 at 03:26:47PM +0200, Tom Petch wrote: > Two queries. > > 1) I see a secure pipe between manager and agent over which PDU from multiple > securityName are multiplexed; when you say session, is that per securityName or > per manager-agent pair? eg SSH has a host key which can be used to create a > secure pipe but I did not envisage that as fine enough granularity to > differentiate separate securityName I think the securityName comes from the authentication protocol which usually in my environment authenticates a user identity. Yes, this requires to have different ssh connections if different identities access a device. But I think this is also how you get into most CLIs as a different user. > 2) when does the entry in the vacmSecurityToGroupTable get created, when > destroyed w.r.t. a session? I see maintenance of that table as a problem. For me, the vacmSecurityToGroupTable belongs to the access control configuration on the device and I therefore believe this is out of scope for ISMS at this point in time. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jul 23 14:38:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwOt0-0000JJ-JL; Sat, 23 Jul 2005 14:38:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwOsy-0000Ik-Av for isms@megatron.ietf.org; Sat, 23 Jul 2005 14:38:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12840 for ; Sat, 23 Jul 2005 14:38:06 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwPNS-0005UN-5O for isms@ietf.org; Sat, 23 Jul 2005 15:09:39 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 23 Jul 2005 11:37:58 -0700 X-IronPort-AV: i="3.95,137,1120460400"; d="scan'208"; a="200186445:sNHT29293864" Received: from kaushik-w2k03.cisco.com (sjc-vpn5-102.cisco.com [10.21.88.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6NIbs6q018242; Sat, 23 Jul 2005 11:37:56 -0700 (PDT) Message-Id: <6.2.0.14.0.20050723112817.04129828@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sat, 23 Jul 2005 11:37:54 -0700 To: "Tom Petch" From: Kaushik Narayan Subject: Re: [Isms] securityName In-Reply-To: <00dc01c58f8b$61132d40$0601a8c0@pc6> References: <3DEC199BD7489643817ECA151F7C59290103F269@pysmsx401.amr.corp.intel.com> <025501c54a7d$663bf520$0601a8c0@pc6> <089201c58ef4$ef6eaf20$0601a8c0@pc6> <6.2.0.14.0.20050722152729.0411f7f8@email.cisco.com> <00dc01c58f8b$61132d40$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Tom, Please find reply inline. >Two queries. > >1) I see a secure pipe between manager and agent over which PDU from multiple >securityName are multiplexed; when you say session, is that per >securityName or >per manager-agent pair? eg SSH has a host key which can be used to create a >secure pipe but I did not envisage that as fine enough granularity to >differentiate separate securityName That's not accurate, there will need to be multiple secure pipes, one for each securityName since the channel is negotiated for a specific securityName. >2) when does the entry in the vacmSecurityToGroupTable get created, when >destroyed w.r.t. a session? I see maintenance of that table as a problem. I am not sure we need to use existing VACM MIB objects to hold ISMS session state information, we should probably look at new MIB objects for ISMS, i.e. the securityName to group mapping would be dynamic and won't be part of the MIB for ISMS security models. The other parts of VACM such as views, groups etc. will be managed via the VACM MIB. regards, kaushik! > > > > At 12:37 PM 7/22/2005, Tom Petch wrote: > > >When we were debating which approach to take, one issue that kept > > >surfacing was > > >the use of securityName; I do not think that choosing an approach has > solved > > >that problem. We may have a secure pipe from Command Generator to Command > > >Responder > > >so a securityName can be safely transmitted from one party to another > but I >do > > >not see how that can then be used. > > > > > >I take (model independent) securityName as a given, from SNMPv3 > > >Architecture and > > >from VACM (both of which the charter requires us to adhere to). So > within an > > >agent (a low powered, low function, remote Command Responder), there > must be >a > > >securityName which is used to index into the vacmSecurityToGroupTable. > > > > > >If that information is stored permanently within the agent, then we > have the > > >maintenance problem that led to the need for isms in the first > place. (I see > > >this as particularly acute when there is a need speedily to remove > security > > >credentials from a principal across a network with thousands of agents). > > > > > >If the information is stored dynamically, then part of session setup > needs to > > >create the relevant entries in the agent which then need to be safely > > >removed at > > >end of session (whatever a session might be). > > > > > >Or the information can be obtained as and when needed by the agent from a > > >security server but what does this require the agent to have in the way of > > >extra > > >protocol support? > > > > > >The preference I expressed earlier was to have predefined generic entries > > >in the > > >agent with the manager (which I assume has got all the necessary access to >the > > >security infrastructure) providing a mapping from the securityName it > knows > > >which is sent > > >over the secure pipe, but I recognise that that could be construed as not > > >integrating adequately with existing security infrastructure. > > > > > >So, regardless of SSH or TLS or ... I do not see a good solution to this > > >problem. > > > > > >Any ideas? > > > > > >Tom Petch > > > > > > > > >_______________________________________________ > > >Isms mailing list > > >Isms@lists.ietf.org > > >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jul 24 05:32:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwcqi-0007Ek-Pp; Sun, 24 Jul 2005 05:32:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwcqg-0007Ea-PK for isms@megatron.ietf.org; Sun, 24 Jul 2005 05:32:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14984 for ; Sun, 24 Jul 2005 05:32:40 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwdLH-00056Y-8I for isms@ietf.org; Sun, 24 Jul 2005 06:04:21 -0400 Received: from pc6 (1Cust33.tnt105.lnd4.gbr.da.uu.net [213.116.58.33]) by blaster.systems.pipex.net (Postfix) with SMTP id 0B93CE00007C; Sun, 24 Jul 2005 10:32:22 +0100 (BST) Message-ID: <002301c5902a$17920980$0601a8c0@pc6> From: "Tom Petch" To: "Kaushik Narayan" References: <3DEC199BD7489643817ECA151F7C59290103F269@pysmsx401.amr.corp.intel.com> <025501c54a7d$663bf520$0601a8c0@pc6> <089201c58ef4$ef6eaf20$0601a8c0@pc6> <6.2.0.14.0.20050722152729.0411f7f8@email.cisco.com> <00dc01c58f8b$61132d40$0601a8c0@pc6> <6.2.0.14.0.20050723112817.04129828@email.cisco.com> Subject: Re: [Isms] securityName and eg SSH Date: Sun, 24 Jul 2005 10:09:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Kaushik Narayan" To: "Tom Petch" Cc: Sent: Saturday, July 23, 2005 8:37 PM Subject: Re: [Isms] securityName > > > > >Two queries. > > > >1) I see a secure pipe between manager and agent over which PDU from multiple > >securityName are multiplexed; when you say session, is that per > >securityName or > >per manager-agent pair? eg SSH has a host key which can be used to create a > >secure pipe but I did not envisage that as fine enough granularity to > >differentiate separate securityName > > That's not accurate, there will need to be multiple secure pipes, one for each > securityName since the channel is negotiated for a specific securityName. > > Just to be clear about SSH; what I hear is that there can only be one ssh-userauth per ssh-transport so while there can be multiple ssh-connection, they all relate to the same ssh-userauth. Yes? The consequence then: either, if ssh-userauth corresponds to a principal and securityName, then, as you say, there must be multiple transports, one per principal; or ssh-userauth, like host key, is on a per box basis in which case we could have one principal per ssh-connection but ssh will not provide authentication of them. How does this interact with other uses of ssh such as telnet? Does each telnet user set up a separate transport? If the same principal were to use telnet and isms, would they use the same transport with different ssh-connections? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jul 24 05:32:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwcqi-0007Eo-Vm; Sun, 24 Jul 2005 05:32:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwcqg-0007Ef-V7 for isms@megatron.ietf.org; Sun, 24 Jul 2005 05:32:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14988 for ; Sun, 24 Jul 2005 05:32:40 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwdLI-00056j-FV for isms@ietf.org; Sun, 24 Jul 2005 06:04:21 -0400 Received: from pc6 (1Cust33.tnt105.lnd4.gbr.da.uu.net [213.116.58.33]) by blaster.systems.pipex.net (Postfix) with SMTP id 4A161E00010A; Sun, 24 Jul 2005 10:32:25 +0100 (BST) Message-ID: <002401c5902a$187d05c0$0601a8c0@pc6> From: "Tom Petch" To: , References: <20050722232427.7131818000081@grand.systems.pipex.net> Subject: Re: [Isms] securityName Date: Sun, 24 Jul 2005 10:21:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "David B Harrington" To: "'Tom Petch'" ; Sent: Saturday, July 23, 2005 1:24 AM Subject: RE: [Isms] securityName > > There is not necessarily a need to statically store the securityName > on the system. A MIB is made available for specifying the mapping from > a model-dependent name to a model-independent name, because some > models may require a static mapping function. > > In USM, the mapping function is not really needed - the mapping > function simply uses the model-specific name as the securityName. Of > course, the USM model-dependent name (and implicitly the securityName) > is already stored statically on the system, which is the concern ISMS > is trying to resolve. > > If a security model can provide a dynamic identity mapping, such as > translating from the authenticated transport identity (e.g. SSH user) > to securityName, then the mapping may not need to be stored in a MIB > module. It might be a desirable to store the dynamic mapping in a MIB > module to enable monitoring of the authentications, or even to support > static mappings to a single securityName from multiple model-dependent > identities, such as a USM user and an SNMPv1 communityname and an SSH > username, for example. I was rather assuming that if ssh-userauth authenticated a principal, then although that is a model dependent name to isms, it would be the same principal identifier as is used in other security systems in the organisation and would be the same as the securityName. I don't see the merit in having a separate principal identifier and securityName, given that one of our aims is to integrate better with existing security systems. > > That said, ISMS is not addressing the problem of having a static > mapping from securityName to access control policies. I expect that > once we resolve the need to use static storage of model-dependent > identities to map to securityName, we will then start work to resolve > the need to have static mappings from securityName to access control > policies, and we will need to decide if having mappings from multiple > security model identities to a common securityName is still desired. > I take this as the same point Juergen made, that VACM is outside our scope. But if we eliminate the need for separate maintenance of security credentials in the security model but leave it in place in VACM, in the shape of the vacmSecurityToGroupTable, then I do not see how we have achieved our objectives, hence my concern about this (while recognising that VACM is a given, not to be changed as a result of isms). > David Harrington > dbharrington@comcast.net > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Tom Petch > > Sent: Friday, July 22, 2005 3:38 PM > > To: isms@ietf.org > > Subject: [Isms] securityName > > > > When we were debating which approach to take, one issue that > > kept surfacing was > > the use of securityName; I do not think that choosing an > > approach has solved > > that problem. We may have a secure pipe from Command > > Generator to Command > > Responder > > so a securityName can be safely transmitted from one party to > > another but I do > > not see how that can then be used. > > > > I take (model independent) securityName as a given, from > > SNMPv3 Architecture and > > from VACM (both of which the charter requires us to adhere > > to). So within an > > agent (a low powered, low function, remote Command > > Responder), there must be a > > securityName which is used to index into the > vacmSecurityToGroupTable. > > > > If that information is stored permanently within the agent, > > then we have the > > maintenance problem that led to the need for isms in the > > first place. (I see > > this as particularly acute when there is a need speedily to > > remove security > > credentials from a principal across a network with thousands > > of agents). > > > > If the information is stored dynamically, then part of > > session setup needs to > > create the relevant entries in the agent which then need to > > be safely removed at > > end of session (whatever a session might be). > > > > Or the information can be obtained as and when needed by the > > agent from a > > security server but what does this require the agent to have > > in the way of extra > > protocol support? > > > > The preference I expressed earlier was to have predefined > > generic entries in the > > agent with the manager (which I assume has got all the > > necessary access to the > > security infrastructure) providing a mapping from the > > securityName it knows > > which is sent > > over the secure pipe, but I recognise that that could be > > construed as not > > integrating adequately with existing security infrastructure. > > > > So, regardless of SSH or TLS or ... I do not see a good > > solution to this > > problem. > > > > Any ideas? > > > > Tom Petch > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jul 24 07:15:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DweSC-0000xM-Vb; Sun, 24 Jul 2005 07:15:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DweSB-0000uZ-Gi for isms@megatron.ietf.org; Sun, 24 Jul 2005 07:15:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20900 for ; Sun, 24 Jul 2005 07:15:28 -0400 (EDT) Received: from ia8e8.i.pppool.de ([85.73.168.232] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwewo-0007ek-0w for isms@ietf.org; Sun, 24 Jul 2005 07:47:11 -0400 Received: by boskop.local (Postfix, from userid 501) id E68833938BA; Sun, 24 Jul 2005 13:15:12 +0200 (CEST) Date: Sun, 24 Jul 2005 13:15:12 +0200 From: Juergen Schoenwaelder To: Tom Petch Subject: Re: [Isms] securityName Message-ID: <20050724111512.GA24019@boskop.local> Mail-Followup-To: Tom Petch , isms@ietf.org References: <20050722232427.7131818000081@grand.systems.pipex.net> <002401c5902a$187d05c0$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002401c5902a$187d05c0$0601a8c0@pc6> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Sun, Jul 24, 2005 at 10:21:11AM +0200, Tom Petch wrote: > I take this as the same point Juergen made, that VACM is outside our > scope. But if we eliminate the need for separate maintenance of > security credentials in the security model but leave it in place > in VACM, in the shape of the vacmSecurityToGroupTable, then I do > not see how we have achieved our objectives, hence my concern about > this (while recognising that VACM is a given, not to be > changed as a result of isms). I am not sure I can follow you here. Please take a look at the diagram in section 3.1 of RFC 3415. It shows quite clearly what the input for a VACM access control decision is. Obviously, the "who" is identified by the securityName. I fail to see how one can eliminate that from the access control decision or how it can be dynamic. Somehow, the security administrator has to specify to whom access is granted. The ISMS charter basically boils down to the requirement that ISMS has to provide the securityModel, securityName and securityLevel triple needed by access control models such as VACM. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jul 24 13:16:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwk5V-0006GZ-Bp; Sun, 24 Jul 2005 13:16:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwk5U-0006GU-CI for isms@megatron.ietf.org; Sun, 24 Jul 2005 13:16:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09437 for ; Sun, 24 Jul 2005 13:16:24 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwka9-0008NC-Ka for isms@ietf.org; Sun, 24 Jul 2005 13:48:11 -0400 Received: from pc6 (1Cust149.tnt103.lnd4.gbr.da.uu.net [213.116.54.149]) by blaster.systems.pipex.net (Postfix) with SMTP id 93844E00010A; Sun, 24 Jul 2005 18:16:06 +0100 (BST) Message-ID: <033c01c5906a$df78dba0$0601a8c0@pc6> From: "Tom Petch" To: References: <20050722232427.7131818000081@grand.systems.pipex.net> <002401c5902a$187d05c0$0601a8c0@pc6> <20050724111512.GA24019@boskop.local> Subject: Re: [Isms] securityName Date: Sun, 24 Jul 2005 18:14:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Tom Petch" Cc: Sent: Sunday, July 24, 2005 1:15 PM Subject: Re: [Isms] securityName > On Sun, Jul 24, 2005 at 10:21:11AM +0200, Tom Petch wrote: > > > I take this as the same point Juergen made, that VACM is outside our > > scope. But if we eliminate the need for separate maintenance of > > security credentials in the security model but leave it in place > > in VACM, in the shape of the vacmSecurityToGroupTable, then I do > > not see how we have achieved our objectives, hence my concern about > > this (while recognising that VACM is a given, not to be > > changed as a result of isms). > > I am not sure I can follow you here. Please take a look at the diagram > in section 3.1 of RFC 3415. It shows quite clearly what the input for > a VACM access control decision is. Obviously, the "who" is identified > by the securityName. I fail to see how one can eliminate that from > the access control decision or how it can be dynamic. Somehow, the > security administrator has to specify to whom access is granted. > > The ISMS charter basically boils down to the requirement that ISMS > has to provide the securityModel, securityName and securityLevel > triple needed by access control models such as VACM. > > /js The problem I see is more a VACM one but one that if neglected could undermine the work of isms, namely that isms may eliminate the need for a SNMP-specific security system for the security model in the 'agent' but that the maintenance of eg vacmSecurityToGroupTable with entries indexed by securityName still requires organisations to maintain a database in every 'agent' of everyone in the organisation with authority to perform some level of access to the MIB; which may be sufficient hassle for SNMPv3 still to be regarded as unacceptable. Hence my queries as to whether eg that table is kept up-to-date at all times, or only when access is being checked. So a principal with a high level of access loses that access; does the security of SNMPv3 depend on that table being updated immediately in all 'agents' in the network? Having a secure pipe from 'manager' to 'agent' does allow us to do things in different places or to look again at the semantics of securityName if that gets round the problem (if there is a problem:-) tom _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jul 24 15:31:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwmC8-0000Ih-Hk; Sun, 24 Jul 2005 15:31:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwmC7-0000Ic-8o for isms@megatron.ietf.org; Sun, 24 Jul 2005 15:31:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17870 for ; Sun, 24 Jul 2005 15:31:25 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwmgo-0003Rk-7p for isms@ietf.org; Sun, 24 Jul 2005 16:03:11 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 24 Jul 2005 12:31:17 -0700 Received: from kaushik-w2k03.cisco.com (sjc-vpn5-102.cisco.com [10.21.88.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6OJVA6q009114; Sun, 24 Jul 2005 12:31:12 -0700 (PDT) Message-Id: <6.2.0.14.0.20050724122134.0412b420@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sun, 24 Jul 2005 12:31:10 -0700 To: "Tom Petch" From: Kaushik Narayan Subject: Re: [Isms] securityName and eg SSH In-Reply-To: <002301c5902a$17920980$0601a8c0@pc6> References: <3DEC199BD7489643817ECA151F7C59290103F269@pysmsx401.amr.corp.intel.com> <025501c54a7d$663bf520$0601a8c0@pc6> <089201c58ef4$ef6eaf20$0601a8c0@pc6> <6.2.0.14.0.20050722152729.0411f7f8@email.cisco.com> <00dc01c58f8b$61132d40$0601a8c0@pc6> <6.2.0.14.0.20050723112817.04129828@email.cisco.com> <002301c5902a$17920980$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Tom, >Just to be clear about SSH; what I hear is that there can only be one >ssh-userauth per ssh-transport so while there can be multiple ssh-connection, >they all relate to the same ssh-userauth. Yes? > >The consequence then: either, if ssh-userauth corresponds to a principal and >securityName, then, as you say, there must be multiple transports, one per >principal; or ssh-userauth, like host key, is on a per box basis in which case >we could have one principal per ssh-connection but ssh will not provide >authentication of them. > >How does this interact with other uses of ssh such as telnet? Does each >telnet >user set up a separate transport? If the same principal were to use >telnet and >isms, would they use the same transport with different ssh-connections? To answer your question, each SSH user will use a separate transport. The question of whether the telnet (NetConf, Syslog) and isms can share a single underlying transport session and leverage multiple connections within the same session is an open item for the WG to discuss. regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jul 24 23:16:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtRo-0006eN-C5; Sun, 24 Jul 2005 23:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtRl-0006eH-5U for isms@megatron.ietf.org; Sun, 24 Jul 2005 23:16:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17299 for ; Sun, 24 Jul 2005 23:16:02 -0400 (EDT) Message-Id: <200507250316.XAA17299@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwtwV-0007ax-UM for isms@ietf.org; Sun, 24 Jul 2005 23:47:53 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc12) with SMTP id <2005072503155301200a1i60e>; Mon, 25 Jul 2005 03:15:53 +0000 From: "David B Harrington" To: "'Tom Petch'" , Subject: RE: [Isms] securityName Date: Sun, 24 Jul 2005 23:15:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWQc3ulUuUXDKptSrugAVqwZaiPUgASSjuA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <033c01c5906a$df78dba0$0601a8c0@pc6> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Tom, Let me provide some historical background before I address your concerns: SNMPv3 was deliberately made modular so different portions of the SNMPv3 standard could be upgraded independently of other pieces. From RFC 3411: "This modularity allows, for example, Security Models, authenication and privacy mechanisms, and message formats to be upgraded and supplemented as the need arises." The authentication subsystem has been deliberately kept separate from the access control subsystem. They are related only in that the output of the authentication subsystem is securityModel, securityName, and securityLevel, and the input to the access control subsystem is securityModel, securityName, and securityLevel. In the same way, the application subsystem has been kept separate from the access control subsystem. They are related via the IsAccessAllowed() ASI. The access control model does not know which application is asking the question, and the application does not know the details of how the answer to the IsAccessAllowed() question is arrived at. The SNMPv3 standard was developed with a set of initial models for each subsystem, to prove that the pieces could be developed following the modularity rules, and so the system could be implemented and "put to the test" so we could determine what problems needed to be resolved, and then resolve those problems by the development of other models for those subsystems. The initial models all have proven to be usable (to varying degrees), but not convenient, especially for large networks. The single largest complaint is that all the initial models require configuration via SNMP MIB modules (which can be populated via the SNMP protocol or via other means within the instrumentation). This ia a problems for a number of reasons - 1) many implementations do not support SNMP SETs, 2) many deployments do not allow SNMP SETs, and 3) many have considered the use of SNMP MIB modules to be "static" configuration that is hard to keep synchronized with other existing infrastructure. Many have expressed the desire that SNMPv3 standard models be developed that automate the configuration by leveraging existing non-SNMP infrastructure to make the dynamic information available to SNMP entities, rather than populating MIB modules dynamically via SNMP. Some of the reported problems with the initial models: 1) Using USM for SNMPv3 authentication requires SNMP "static" configuration. 2) Using VACM for access control requires SNMP "static" configuration. 3) Using the SNMP-TARGET-MIB (RFC 3413) requires SNMP static configuration. 4) Using the SNMP-NOTIFICATION-MIB (RFC 3413) requires static configuration. 5) Using the SNMP-PROXY-MIB (RFC 3413) requires static configuration. **These are separable problems and, by SNMPv3 architectural design, separate problems.** To address your concerns: 1) ISMS has currently been chartered to resolve the problem that using USM for SNMPv3 authentication requires SNMP static configuration. 2) ISMS has explicitly NOT been chartered to resolve the problem that using VACM for access control requires static configuration. And concerns that you might get around to considering as well: 3) ISMS has NOT been chartered to resolve the problem that using the SNMP-TARGET-MIB (RFC 3413) requires static configuration. 4) ISMS has NOT been chartered to resolve the problem that using the SNMP-NOTIFICATION-MIB (RFC 3413) requires static configuration. 5) ISMS has NOT been chartered to resolve the problem that using SNMP-PROXY-MIB (RFC 3413) requires static configuration. I don't think anybody believes that simply solving the problem that using USM for SNMPv3 authentication requires static configuration will make SNMPv3 imminently deployable. The VACM problam also needs to be resolved. Once these two problems are solved, SNMPv3 might be more deployable, but the other problems of static configuration will probably need to be resolved as well. ISMS needs to stay focused on solving the problems of one subsystem at a time. We should consider the ramifications to other subsystems, but solving the problems of those other subsystems is not in scope. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Tom Petch > Sent: Sunday, July 24, 2005 12:15 PM > To: j.schoenwaelder@iu-bremen.de > Cc: isms@ietf.org > Subject: Re: [Isms] securityName > > > Tom Petch > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "Tom Petch" > Cc: > Sent: Sunday, July 24, 2005 1:15 PM > Subject: Re: [Isms] securityName > > > > On Sun, Jul 24, 2005 at 10:21:11AM +0200, Tom Petch wrote: > > > > > I take this as the same point Juergen made, that VACM is > outside our > > > scope. But if we eliminate the need for separate maintenance of > > > security credentials in the security model but leave it in place > > > in VACM, in the shape of the vacmSecurityToGroupTable, then I do > > > not see how we have achieved our objectives, hence my > concern about > > > this (while recognising that VACM is a given, not to be > > > changed as a result of isms). > > > > I am not sure I can follow you here. Please take a look at > the diagram > > in section 3.1 of RFC 3415. It shows quite clearly what the > input for > > a VACM access control decision is. Obviously, the "who" is > identified > > by the securityName. I fail to see how one can eliminate that from > > the access control decision or how it can be dynamic. Somehow, the > > security administrator has to specify to whom access is granted. > > > > The ISMS charter basically boils down to the requirement that ISMS > > has to provide the securityModel, securityName and securityLevel > > triple needed by access control models such as VACM. > > > > /js > > The problem I see is more a VACM one but one that if > neglected could undermine > the work of isms, namely that isms may eliminate the need for > a SNMP-specific > security system for the security model in the 'agent' but > that the maintenance > of eg vacmSecurityToGroupTable with entries indexed by > securityName still > requires organisations to maintain a database in every > 'agent' of everyone in > the organisation with authority to perform some level of > access to the MIB; > which may be sufficient hassle for SNMPv3 still to be > regarded as unacceptable. > Hence my queries as to whether eg that table is kept > up-to-date at all times, or > only when access is being checked. > > So a principal with a high level of access loses that access; > does the security > of SNMPv3 depend on that table being updated immediately in > all 'agents' in the > network? > > Having a secure pipe from 'manager' to 'agent' does allow us > to do things in > different places or to look again at the semantics of > securityName if that gets > round the problem (if there is a problem:-) > > tom > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 25 10:00:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx3VZ-0008Dv-4Y; Mon, 25 Jul 2005 10:00:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx3VY-0008AR-7Y for isms@megatron.ietf.org; Mon, 25 Jul 2005 10:00:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21393 for ; Mon, 25 Jul 2005 10:00:38 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx40O-0003QW-A0 for isms@ietf.org; Mon, 25 Jul 2005 10:32:33 -0400 Received: from pc6 (1Cust206.tnt8.lnd4.gbr.da.uu.net [62.188.137.206]) by galaxy.systems.pipex.net (Postfix) with SMTP id C0EC1E000220; Mon, 25 Jul 2005 15:00:19 +0100 (BST) Message-ID: <02cf01c59118$b00b4b60$0601a8c0@pc6> From: "Tom Petch" To: "Kaushik Narayan" References: <3DEC199BD7489643817ECA151F7C59290103F269@pysmsx401.amr.corp.intel.com> <025501c54a7d$663bf520$0601a8c0@pc6> <089201c58ef4$ef6eaf20$0601a8c0@pc6> <6.2.0.14.0.20050722152729.0411f7f8@email.cisco.com> <00dc01c58f8b$61132d40$0601a8c0@pc6> <6.2.0.14.0.20050723112817.04129828@email.cisco.com> <002301c5902a$17920980$0601a8c0@pc6> <6.2.0.14.0.20050724122134.0412b420@email.cisco.com> Date: Mon, 25 Jul 2005 14:58:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: [Isms] Port numbers X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Kaushik Narayan" To: "Tom Petch" Cc: Sent: Sunday, July 24, 2005 9:31 PM Subject: Re: [Isms] securityName and eg SSH > To answer your question, each SSH user will use a separate transport. > > The question of whether the telnet (NetConf, Syslog) and isms can share a single > underlying transport session and leverage multiple connections within the same > session is an open item for the WG to discuss. > > kaushik! > Funny you should say that. Another question that I have is what ports isms should use? Some time ago, there was a discussion about the use of ports when an application started using security, should the port be that of the application or of the security protocol or something else; as I recall, this was on the main IETF list although I cannot find it at present. I notice netconf over ssh has gone for something else, asking for a new port from IANA (I know, there isn't a netconf native application port per se). tom _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 25 10:00:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx3VZ-0008F5-Db; Mon, 25 Jul 2005 10:00:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx3VY-0008B7-CX for isms@megatron.ietf.org; Mon, 25 Jul 2005 10:00:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21395 for ; Mon, 25 Jul 2005 10:00:38 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx40P-0003QX-DT for isms@ietf.org; Mon, 25 Jul 2005 10:32:34 -0400 Received: from pc6 (1Cust206.tnt8.lnd4.gbr.da.uu.net [62.188.137.206]) by galaxy.systems.pipex.net (Postfix) with SMTP id 0688DE000210; Mon, 25 Jul 2005 15:00:23 +0100 (BST) Message-ID: <02d001c59118$b1071080$0601a8c0@pc6> From: "Tom Petch" To: References: <20050725031555.497EAE000085@robin.systems.pipex.net> Subject: Re: [Isms] securityName Date: Mon, 25 Jul 2005 14:59:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "David B Harrington" To: "'Tom Petch'" ; Cc: Sent: Monday, July 25, 2005 5:15 AM Subject: RE: [Isms] securityName > Hi Tom, > > Let me provide some historical background before I address your > concerns: > > SNMPv3 was deliberately made modular so different portions of the > SNMPv3 standard could be upgraded independently of other pieces. From > RFC 3411: "This modularity allows, for example, Security Models, > authenication and privacy mechanisms, and message formats to be > upgraded and supplemented as the need arises." > > The authentication subsystem has been deliberately kept separate from > the access control subsystem. They are related only in that the output > of the authentication subsystem is securityModel, securityName, and > securityLevel, and the input to the access control subsystem is > securityModel, securityName, and securityLevel. > > In the same way, the application subsystem has been kept separate from > the access control subsystem. They are related via the > IsAccessAllowed() ASI. The access control model does not know which > application is asking the question, and the application does not know > the details of how the answer to the IsAccessAllowed() question is > arrived at. > > The SNMPv3 standard was developed with a set of initial models for > each subsystem, to prove that the pieces could be developed following > the modularity rules, and so the system could be implemented and "put > to the test" so we could determine what problems needed to be > resolved, and then resolve those problems by the development of other > models for those subsystems. The initial models all have proven to be > usable (to varying degrees), but not convenient, especially for large > networks. > > The single largest complaint is that all the initial models require > configuration via SNMP MIB modules (which can be populated via the > SNMP protocol or via other means within the instrumentation). This ia > a problems for a number of reasons - 1) many implementations do not > support SNMP SETs, 2) many deployments do not allow SNMP SETs, and 3) > many have considered the use of SNMP MIB modules to be "static" > configuration that is hard to keep synchronized with other existing > infrastructure. Many have expressed the desire that SNMPv3 standard > models be developed that automate the configuration by leveraging > existing non-SNMP infrastructure to make the dynamic information > available to SNMP entities, rather than populating MIB modules > dynamically via SNMP. > > Some of the reported problems with the initial models: > 1) Using USM for SNMPv3 authentication requires SNMP "static" > configuration. > 2) Using VACM for access control requires SNMP "static" configuration. > 3) Using the SNMP-TARGET-MIB (RFC 3413) requires SNMP static > configuration. > 4) Using the SNMP-NOTIFICATION-MIB (RFC 3413) requires static > configuration. > 5) Using the SNMP-PROXY-MIB (RFC 3413) requires static configuration. > > **These are separable problems and, by SNMPv3 architectural design, > separate problems.** > > To address your concerns: > 1) ISMS has currently been chartered to resolve the problem that using > USM for SNMPv3 authentication requires SNMP static configuration. > 2) ISMS has explicitly NOT been chartered to resolve the problem that > using VACM for access control requires static configuration. > > And concerns that you might get around to considering as well: > 3) ISMS has NOT been chartered to resolve the problem that using the > SNMP-TARGET-MIB (RFC 3413) requires static configuration. > 4) ISMS has NOT been chartered to resolve the problem that using the > SNMP-NOTIFICATION-MIB (RFC 3413) requires static configuration. > 5) ISMS has NOT been chartered to resolve the problem that using > SNMP-PROXY-MIB (RFC 3413) requires static configuration. > > I don't think anybody believes that simply solving the problem that > using USM for SNMPv3 authentication requires static configuration will > make SNMPv3 imminently deployable. The VACM problam also needs to be > resolved. Once these two problems are solved, SNMPv3 might be more > deployable, but the other problems of static configuration will > probably need to be resolved as well. > Mmmm I think I was hoping for rather more from isms. Reminding myself of the charter, it identifies two problems as inhibiting the deployment of SNMPv3: - distributing and maintaining VACM rules is difficult in large-scale environments. - addition of yet another authentication system specific to SNMPv3 that needs to be maintained across all networking devices so my hope was that we would fix the second and SNMPv3 would be imminently deployable except where fine-grained access control was also needed. (I do not have concerns about the static configuration of the TARGET-, PROXY- and NOTIFICATION- MIB; need fixing but less urgent for me so you won't hear me mentioning them again:-). _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 25 10:40:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx48J-0002oO-7O; Mon, 25 Jul 2005 10:40:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx48H-0002gM-Ms for isms@megatron.ietf.org; Mon, 25 Jul 2005 10:40:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26135 for ; Mon, 25 Jul 2005 10:40:40 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx4d3-00050C-Bo for isms@ietf.org; Mon, 25 Jul 2005 11:12:36 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 25 Jul 2005 07:40:25 -0700 X-IronPort-AV: i="3.95,140,1120460400"; d="scan'208"; a="650504942:sNHT31725932" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6PEeOJL006736; Mon, 25 Jul 2005 07:40:24 -0700 (PDT) Received: from [144.254.23.220] (dhcp-data-vlan10-23-220.cisco.com [144.254.23.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j6PEcIQX027179; Mon, 25 Jul 2005 07:38:19 -0700 Message-ID: <42E4F9D6.3090007@cisco.com> Date: Mon, 25 Jul 2005 16:40:22 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Petch Subject: Re: [Isms] Port numbers References: <3DEC199BD7489643817ECA151F7C59290103F269@pysmsx401.amr.corp.intel.com> <025501c54a7d$663bf520$0601a8c0@pc6> <089201c58ef4$ef6eaf20$0601a8c0@pc6> <6.2.0.14.0.20050722152729.0411f7f8@email.cisco.com> <00dc01c58f8b$61132d40$0601a8c0@pc6> <6.2.0.14.0.20050723112817.04129828@email.cisco.com> <002301c5902a$17920980$0601a8c0@pc6> <6.2.0.14.0.20050724122134.0412b420@email.cisco.com> <02cf01c59118$b00b4b60$0601a8c0@pc6> In-Reply-To: <02cf01c59118$b00b4b60$0601a8c0@pc6> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1122302300.1979"; x:"432200"; a:"rsa-sha1"; b:"nofws:676"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"qoeESZNBQXUG/FHmELwLdTfQek+Vkq8cppwn9s6MdWzJjo74HEJ1sSr7cxJgQDLfZ/IpcPgX" "LfBTVjGEOal+S5kesajxBjcMh61gnb8iiZG+B5zDGfPC93nDOoAZPumCIvi4W0ezgRqwkpNEkSp" "HL2fJndjgx/M8BYnWBrhpMtE="; c:"Date: Mon, 25 Jul 2005 16:40:22 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] Port numbers" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch wrote: > Some time ago, there was a discussion about the use of ports when an application > started using security, should the port be that of the application or of the > security protocol or something else; as I recall, this was on the main IETF > list although I cannot find it at present. > > I notice netconf over ssh has gone for something else, asking for a new port > from IANA (I know, there isn't a netconf native application port per se). See the analysis in Kaushik's draft about this. It boils down to intended use. I personally think ISMS and NETCONF should share a port. The reason SSH does not share a port in NETCONF is that it is possible for SSH to be used for non-administrative purposes (like users logging in to read mail) and one might want a different firewall policy for one versus the other. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 25 14:28:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx7hD-0002Kq-Ju; Mon, 25 Jul 2005 14:28:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx7hC-0002Kg-3Y for isms@megatron.ietf.org; Mon, 25 Jul 2005 14:28:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12667 for ; Mon, 25 Jul 2005 14:28:57 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx8C5-0003wq-60 for isms@ietf.org; Mon, 25 Jul 2005 15:00:54 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 25 Jul 2005 11:28:48 -0700 X-IronPort-AV: i="3.95,140,1120460400"; d="scan'208"; a="650582757:sNHT32244050" 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 j6PISful000923; Mon, 25 Jul 2005 11:28:41 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] securityName Date: Mon, 25 Jul 2005 11:33:19 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905944731@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Isms] securityName Thread-Index: AcWPof5tq9+2QzdfQ9+7EvIAI9qCfQBo47og From: "Salowey, Joe" To: , "Tom Petch" 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org =20 > I think the securityName comes from the authentication=20 > protocol which usually in my environment authenticates a user=20 > identity. Yes, this requires to have different ssh=20 > connections if different identities access a device. But I=20 > think this is also how you get into most CLIs as a different user. > =20 [Joe] There is typically be a mapping function between the securityName and an authenticated identity. This mapping could be from one authenticated identity to many securityNames, however the mapping needs to be authorized in order for this to be secure. The securityName may be implicitly derived (such as equivalent to the authenticated name or some well defined porcessing of the authenticated name) or it can be explicitly defined in an SNMP PDU or as a SASL authorization ID. The authorized mapping rules between authenticated identity and security name can be maintained locally or remotely. =20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 25 15:27:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx8bh-0005MV-PY; Mon, 25 Jul 2005 15:27:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx8bf-0005MN-RO for isms@megatron.ietf.org; Mon, 25 Jul 2005 15:27:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17196 for ; Mon, 25 Jul 2005 15:27:18 -0400 (EDT) Received: from i89cc.i.pppool.de ([85.73.137.204] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx96Y-0005UZ-GM for isms@ietf.org; Mon, 25 Jul 2005 15:59:16 -0400 Received: by boskop.local (Postfix, from userid 501) id B8CBE396502; Mon, 25 Jul 2005 21:26:57 +0200 (CEST) Date: Mon, 25 Jul 2005 21:26:57 +0200 From: Juergen Schoenwaelder To: "Salowey, Joe" Subject: Re: [Isms] securityName Message-ID: <20050725192657.GB26065@boskop.local> Mail-Followup-To: "Salowey, Joe" , Tom Petch , isms@ietf.org References: <7210B31550AC934A8637D6619739CE6905944731@e2k-sea-xch2.sea-alpha.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7210B31550AC934A8637D6619739CE6905944731@e2k-sea-xch2.sea-alpha.cisco.com> User-Agent: Mutt/1.5.9i 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 Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Mon, Jul 25, 2005 at 11:33:19AM -0700, Salowey, Joe wrote: > > > > I think the securityName comes from the authentication > > protocol which usually in my environment authenticates a user > > identity. Yes, this requires to have different ssh > > connections if different identities access a device. But I > > think this is also how you get into most CLIs as a different user. > > > > [Joe] There is typically be a mapping function between the securityName > and an authenticated identity. This mapping could be from one > authenticated identity to many securityNames, however the mapping needs > to be authorized in order for this to be secure. The securityName may > be implicitly derived (such as equivalent to the authenticated name or > some well defined porcessing of the authenticated name) or it can be > explicitly defined in an SNMP PDU or as a SASL authorization ID. In the USM case, there is the usmUserName (which is the USM specific identity) which makes to the securityName (which is the security model agnostic identity). In this particular case, the default mapping is a one-to-one transformation. I am less sure whether N:1 or 1:M mappings are feasible or desirable. > The authorized mapping rules between authenticated identity and security > name can be maintained locally or remotely. What do you mean when you say "remotely"? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 25 15:38:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx8mD-0007GL-H0; Mon, 25 Jul 2005 15:38:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx8mC-0007GA-2g for isms@megatron.ietf.org; Mon, 25 Jul 2005 15:38:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18049 for ; Mon, 25 Jul 2005 15:38:10 -0400 (EDT) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx9H5-0005zw-6H for isms@ietf.org; Mon, 25 Jul 2005 16:10:08 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j6PJc0Qr004853 for ; Mon, 25 Jul 2005 19:38:00 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j6PJbxYd007772 for ; Mon, 25 Jul 2005 19:38:00 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005072512380022125 for ; Mon, 25 Jul 2005 12:38:00 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 12:37:52 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 12:37:52 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 15:37:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] securityName Date: Mon, 25 Jul 2005 15:34:42 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C59290186EE54@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] securityName Thread-Index: AcWRT0QL2IbUkG5hSQGtO+CJFS7aiQAAAzng From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 25 Jul 2005 19:37:47.0251 (UTC) FILETIME=[55C80430:01C59150] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org For several reasons, it makes sense to make Security Model responsible for providing the mapping between SNMP-specific securityName that appears in at least in two components (Access Control Model and Security Model), and security model-specific way to identify the authenticated principal (user@realm, PK OID, hash(fingerprint), whatever). For example, other components may not know the identity that newSM used to perform principal authentication. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Monday, July 25, 2005 3:27 PM To: Salowey, Joe Cc: isms@ietf.org Subject: Re: [Isms] securityName On Mon, Jul 25, 2005 at 11:33:19AM -0700, Salowey, Joe wrote: > =20 >=20 > > I think the securityName comes from the authentication=20 > > protocol which usually in my environment authenticates a user=20 > > identity. Yes, this requires to have different ssh=20 > > connections if different identities access a device. But I=20 > > think this is also how you get into most CLIs as a different user. > > =20 >=20 > [Joe] There is typically be a mapping function between the securityName > and an authenticated identity. This mapping could be from one > authenticated identity to many securityNames, however the mapping needs > to be authorized in order for this to be secure. The securityName may > be implicitly derived (such as equivalent to the authenticated name or > some well defined porcessing of the authenticated name) or it can be > explicitly defined in an SNMP PDU or as a SASL authorization ID. =20 In the USM case, there is the usmUserName (which is the USM specific identity) which makes to the securityName (which is the security model agnostic identity). In this particular case, the default mapping is a one-to-one transformation. I am less sure whether N:1 or 1:M mappings are feasible or desirable. > The authorized mapping rules between authenticated identity and security > name can be maintained locally or remotely. What do you mean when you say "remotely"? /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@lists.ietf.org Mon Jul 25 16:01:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx98T-0004HD-GS; Mon, 25 Jul 2005 16:01:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx98R-0004H8-IT for isms@megatron.ietf.org; Mon, 25 Jul 2005 16:01:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19852 for ; Mon, 25 Jul 2005 16:01:09 -0400 (EDT) Message-Id: <200507252001.QAA19852@ietf.org> Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx9dL-0006o1-8K for isms@ietf.org; Mon, 25 Jul 2005 16:33:08 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <2005072520005401400k4vnae>; Mon, 25 Jul 2005 20:00:54 +0000 From: "David B Harrington" To: "'Salowey, Joe'" , , "'Tom Petch'" Subject: RE: [Isms] securityName Date: Mon, 25 Jul 2005 16:00:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWPof5tq9+2QzdfQ9+7EvIAI9qCfQBo47ogAALJOTA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <7210B31550AC934A8637D6619739CE6905944731@e2k-sea-xch2.sea-alpha.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Joe, The SNMPv3/USM design foresaw the need for mappings from multiple model-dependent identities (e.g. USM and Community models) to a model-independent identity, so the same user utilizing different securityModels could be mapped to one securityName, for expected use by the access control subsystem. This is identified by the tuple { securityModel, securityName }. Under what circumstances do you envision needing the ability to map from one model-specific identity to multiple securityNames, and how would you know which mapping applied? David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Salowey, Joe > Sent: Monday, July 25, 2005 2:33 PM > To: j.schoenwaelder@iu-bremen.de; Tom Petch > Cc: isms@ietf.org > Subject: RE: [Isms] securityName > > > > > I think the securityName comes from the authentication > > protocol which usually in my environment authenticates a user > > identity. Yes, this requires to have different ssh > > connections if different identities access a device. But I > > think this is also how you get into most CLIs as a different user. > > > > [Joe] There is typically be a mapping function between the > securityName > and an authenticated identity. This mapping could be from one > authenticated identity to many securityNames, however the > mapping needs > to be authorized in order for this to be secure. The securityName may > be implicitly derived (such as equivalent to the authenticated name or > some well defined porcessing of the authenticated name) or it can be > explicitly defined in an SNMP PDU or as a SASL authorization ID. The > authorized mapping rules between authenticated identity and security > name can be maintained locally or remotely. > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 25 16:04:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx9Bd-0005VS-Uj; Mon, 25 Jul 2005 16:04:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx9Bb-0005VI-On for isms@megatron.ietf.org; Mon, 25 Jul 2005 16:04:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20059 for ; Mon, 25 Jul 2005 16:04:26 -0400 (EDT) Message-Id: <200507252004.QAA20059@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx9gV-0006tQ-IE for isms@ietf.org; Mon, 25 Jul 2005 16:36:24 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc13) with SMTP id <20050725200132013006sd8je>; Mon, 25 Jul 2005 20:01:32 +0000 From: "David B Harrington" To: "'Blumenthal, Uri'" , Subject: RE: [Isms] securityName Date: Mon, 25 Jul 2005 16:01:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWRT0QL2IbUkG5hSQGtO+CJFS7aiQAAAzngAACJsOA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <3DEC199BD7489643817ECA151F7C59290186EE54@pysmsx401.amr.corp.intel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Uri, Were you answering a question? If so, which question? I'm not sure where your comment fits into the discussion and want to understand the context of your comment. Is this in response to the local versus remote comment by Joe? David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Blumenthal, Uri > Sent: Monday, July 25, 2005 3:35 PM > To: isms@ietf.org > Subject: RE: [Isms] securityName > > For several reasons, it makes sense to make Security Model responsible > for providing the mapping between SNMP-specific securityName that > appears in at least in two components (Access Control Model > and Security > Model), and security model-specific way to identify the authenticated > principal (user@realm, PK OID, hash(fingerprint), whatever). For > example, other components may not know the identity that newSM used to > perform principal authentication. > > > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] > On Behalf Of Juergen Schoenwaelder > Sent: Monday, July 25, 2005 3:27 PM > To: Salowey, Joe > Cc: isms@ietf.org > Subject: Re: [Isms] securityName > > On Mon, Jul 25, 2005 at 11:33:19AM -0700, Salowey, Joe wrote: > > > > > > > I think the securityName comes from the authentication > > > protocol which usually in my environment authenticates a user > > > identity. Yes, this requires to have different ssh > > > connections if different identities access a device. But I > > > think this is also how you get into most CLIs as a different user. > > > > > > > [Joe] There is typically be a mapping function between the > securityName > > and an authenticated identity. This mapping could be from one > > authenticated identity to many securityNames, however the mapping > needs > > to be authorized in order for this to be secure. The > securityName may > > be implicitly derived (such as equivalent to the > authenticated name or > > some well defined porcessing of the authenticated name) or it can be > > explicitly defined in an SNMP PDU or as a SASL authorization ID. > > In the USM case, there is the usmUserName (which is the USM specific > identity) which makes to the securityName (which is the security model > agnostic identity). In this particular case, the default mapping is a > one-to-one transformation. I am less sure whether N:1 or 1:M mappings > are feasible or desirable. > > > The authorized mapping rules between authenticated identity and > security > > name can be maintained locally or remotely. > > What do you mean when you say "remotely"? > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, > Germany > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 25 16:59:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxA2t-0007vx-Bo; Mon, 25 Jul 2005 16:59:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxA2o-0007ue-R6 for isms@megatron.ietf.org; Mon, 25 Jul 2005 16:59:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22994 for ; Mon, 25 Jul 2005 16:59:24 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxAXj-0008QG-Oh for isms@ietf.org; Mon, 25 Jul 2005 17:31:24 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 25 Jul 2005 13:59:01 -0700 X-IronPort-AV: i="3.95,140,1120460400"; d="scan'208"; a="325874233:sNHT1635764578" 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 j6PKwsul020261; Mon, 25 Jul 2005 13:58:55 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] securityName Date: Mon, 25 Jul 2005 14:03:32 -0700 Message-ID: <7210B31550AC934A8637D6619739CE69059447EC@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Isms] securityName Thread-Index: AcWPof5tq9+2QzdfQ9+7EvIAI9qCfQBo47ogAALJOTAAAmPMcA== From: "Salowey, Joe" To: , , "Tom Petch" X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org =20 > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Monday, July 25, 2005 1:01 PM > To: Salowey, Joe; j.schoenwaelder@iu-bremen.de; 'Tom Petch' > Cc: isms@ietf.org > Subject: RE: [Isms] securityName >=20 > Hi Joe, >=20 > The SNMPv3/USM design foresaw the need for mappings from=20 > multiple model-dependent identities (e.g. USM and Community=20 > models) to a model-independent identity, so the same user=20 > utilizing different securityModels could be mapped to one=20 > securityName, for expected use by the access control=20 > subsystem. This is identified by the tuple { securityModel,=20 > securityName }. >=20 > Under what circumstances do you envision needing the ability=20 > to map from one model-specific identity to multiple=20 > securityNames, and how would you know which mapping applied? >=20 [Joe] One example that is often cited is to allow for an application proxy where the application proxy authenticates to the device and the requests to act as a certain user. In SASL name to be used for authorization is communicated using the authorization identity so it is explicitly communicated, in other cases it is directly requested as part of the application protocol. =20 > David Harrington > dbharrington@comcast.net >=20 >=20 >=20 > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Salowey, Joe > > Sent: Monday, July 25, 2005 2:33 PM > > To: j.schoenwaelder@iu-bremen.de; Tom Petch > > Cc: isms@ietf.org > > Subject: RE: [Isms] securityName > >=20 > > =20 > >=20 > > > I think the securityName comes from the authentication protocol=20 > > > which usually in my environment authenticates a user=20 > identity. Yes,=20 > > > this requires to have different ssh connections if different=20 > > > identities access a device. But I think this is also how you get=20 > > > into most CLIs as a different user. > > > =20 > >=20 > > [Joe] There is typically be a mapping function between the=20 > > securityName and an authenticated identity. This mapping could be=20 > > from one authenticated identity to many securityNames, however the=20 > > mapping needs to be authorized in order for this to be secure. The=20 > > securityName > may > > be implicitly derived (such as equivalent to the authenticated name > or > > some well defined porcessing of the authenticated name) or=20 > it can be=20 > > explicitly defined in an SNMP PDU or as a SASL authorization ID. > The > > authorized mapping rules between authenticated identity and=20 > security=20 > > name can be maintained locally or remotely. > >=20 > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > >=20 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 25 19:22:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxCGz-0007oE-RW; Mon, 25 Jul 2005 19:22:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxCGy-0007o9-L2 for isms@megatron.ietf.org; Mon, 25 Jul 2005 19:22:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06216 for ; Mon, 25 Jul 2005 19:22:09 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxClu-0005DM-9Q for isms@ietf.org; Mon, 25 Jul 2005 19:54:11 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 25 Jul 2005 16:22:02 -0700 X-IronPort-AV: i="3.95,141,1120460400"; d="scan'208"; a="325937344:sNHT30360952" 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 j6PNJqul005116; Mon, 25 Jul 2005 16:19:52 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] securityName Date: Mon, 25 Jul 2005 16:24:31 -0700 Message-ID: <7210B31550AC934A8637D6619739CE69059448B6@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Isms] securityName Thread-Index: AcWRT4PaZiRxvk2SQVC7n2z5CRPh7wADJQmQ From: "Salowey, Joe" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >=20 > > The authorized mapping rules between authenticated identity and=20 > > security name can be maintained locally or remotely. >=20 > What do you mean when you say "remotely"? > [Joe] The binding between an authenticated identity and a securityName can either be rooted in locally maintained information or from a third party. For example a AAA server may return the security name to be used with the result of the authentication. It is also possible to have the binding originated by a third party and maintained by the entity referred to by the security name if authentication mechanism allows (for example a field in a certificate or kerberos ticket). =20 =20 > /js >=20 > --=20 > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 25 20:21:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxDCk-0002tx-4p; Mon, 25 Jul 2005 20:21:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxDCh-0002rL-OE for isms@megatron.ietf.org; Mon, 25 Jul 2005 20:21:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09806 for ; Mon, 25 Jul 2005 20:21:50 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxDhe-0006vl-0f for isms@ietf.org; Mon, 25 Jul 2005 20:53:51 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 65BC1E0049; Mon, 25 Jul 2005 20:21:00 -0400 (EDT) To: Tom Petch Subject: Re: [Isms] securityName References: <20050722232427.7131818000081@grand.systems.pipex.net> <002401c5902a$187d05c0$0601a8c0@pc6> From: Sam Hartman Date: Mon, 25 Jul 2005 20:21:00 -0400 In-Reply-To: <002401c5902a$187d05c0$0601a8c0@pc6> (Tom Petch's message of "Sun, 24 Jul 2005 10:21:11 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Tom" == Tom Petch writes: Tom> I was rather assuming that if ssh-userauth authenticated a Tom> principal, then although that is a model dependent name to Tom> isms, it would be the same principal identifier as is used in Tom> other security systems in the organisation and would be the Tom> same as the securityName. I don't see the merit in having a Tom> separate principal identifier and securityName, given that Tom> one of our aims is to integrate better with existing security Tom> systems. I'm not at all sure this is true. In general, SASL and other application protocols have found it useful to separate the identifier authenticated by a security model from the identifier (authorization ID for SASL) used to make authorization decisions. IN many cases there is a simple mapping that can be overridden. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 26 14:58:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxUdN-0004Qm-T2; Tue, 26 Jul 2005 14:58:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxUdM-0004Qh-Ef for isms@megatron.ietf.org; Tue, 26 Jul 2005 14:58:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14666 for ; Tue, 26 Jul 2005 14:58:31 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxV8R-0006rM-Er for isms@ietf.org; Tue, 26 Jul 2005 15:30:41 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id AE9AFE0049; Tue, 26 Jul 2005 14:57:43 -0400 (EDT) To: dbharrington@comcast.net Subject: Re: [Isms] Comments on the BTSMS proposal References: <200507151618.MAA22560@ietf.org> From: Sam Hartman Date: Tue, 26 Jul 2005 14:57:43 -0400 In-Reply-To: <200507151618.MAA22560@ietf.org> (David B. Harrington's message of "Fri, 15 Jul 2005 12:18:44 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "David" == David B Harrington writes: David> 2) Make the transport security selection transparent, not David> opaque. David> I don't feel comfortable having one BEEP transport mapping David> that might use only TLS or might user TLS with SASL or some David> other combination of underlying protocols. I think TLS and David> SASL-over-TLS probably meet different security David> requirements, so should be considered different BEEP David> profiles, different SNMP transport mappings, and different David> SNMP security models. SNMP-over-BEEP seems too opaque to be David> useful for security purposes. I have not yet read the document but based on your comments I disagree. The security provided by TLS, SASL and any combination will depend on the specific mechanisms in use, ciphers used by those mechanisms and possibly by properties of external authentication infrastructures. If you try and expose this information to SNMP, you will complicate the mapping significantly. In addition, you will probably find that several deployments do not fit your mapping. I don't think there is a lot to be gained from treating for example SASL+TLS differently from just TLS. I do think that exposing properties like whether there is integrity, whether there is confidentiality and whether there is mutual authentication is useful. I do believe that allowing implementations to expose additional information for the purpose of making security policy decisions is reasonable. I suspect based on some comments here that what I'm proposing may not be entirely consistent with the SNMP architecture. If so, I'd recommend that the WG seriously consider the possibility that the SNMP architecture is wrong in this regard. We've got significant experience in the applications area that exposing this information is not necessary. If the working group does decide to split these into separate profiles, I'd recommend explaining why SNMP's requirements are different than other applications that use similar security models. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 26 20:35:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxZtr-0007sM-87; Tue, 26 Jul 2005 20:35:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxZtp-0007s3-7p for isms@megatron.ietf.org; Tue, 26 Jul 2005 20:35:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07627 for ; Tue, 26 Jul 2005 20:35:51 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxaOy-0007o4-A6 for isms@ietf.org; Tue, 26 Jul 2005 21:08:04 -0400 Received: from h-68-166-189-173.snvacaid.dynamic.covad.net ([68.166.189.173] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DxZtm-0007L2-00 for isms@ietf.org; Tue, 26 Jul 2005 20:35:50 -0400 Message-ID: <002f01c59243$3b9aec00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <3DEC199BD7489643817ECA151F7C59290103F269@pysmsx401.amr.corp.intel.com><025501c54a7d$663bf520$0601a8c0@pc6><089201c58ef4$ef6eaf20$0601a8c0@pc6><6.2.0.14.0.20050722152729.0411f7f8@email.cisco.com><00dc01c58f8b$61132d40$0601a8c0@pc6> <20050723161152.GA22952@boskop.local> Subject: Re: [Isms] securityName Date: Tue, 26 Jul 2005 17:36:30 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Juergen Schoenwaelder" > To: "Tom Petch" > Cc: > Sent: Saturday, July 23, 2005 9:11 AM > Subject: Re: [Isms] securityName >> On Sat, Jul 23, 2005 at 03:26:47PM +0200, Tom Petch wrote: ... > > 2) when does the entry in the vacmSecurityToGroupTable get created, when > > destroyed w.r.t. a session? I see maintenance of that table as a problem. > > For me, the vacmSecurityToGroupTable belongs to the access control > configuration on the device and I therefore believe this is out of > scope for ISMS at this point in time. ... However, I'd like to remind folks what we wrote in section 3.3 of http://www.ietf.org/internet-drafts/draft-ietf-isms-proposal-comparison-00.txt Dynamic authentication of users is not operationally sufficient, given how VACM works. Requiring security administrators to pre-configure the vacmSecurityToGroupTable [RFC3415] for dynamically authenticated users would defeat the whole purpose of doing dynamic authentication. Consequently, the evaluation team recommends the inclusion of something similar to the EUSM proposal's mechanism for conveying user-to-group mappings from the AAA-server-equivalent. This should not be confused with full-scale configuration of VACM, which is out of scope for this working group. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 26 23:14:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxcMq-0001Ky-L6; Tue, 26 Jul 2005 23:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxcMn-0001Kt-Mg for isms@megatron.ietf.org; Tue, 26 Jul 2005 23:13:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15807 for ; Tue, 26 Jul 2005 23:13:54 -0400 (EDT) Message-Id: <200507270313.XAA15807@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxcry-0003SV-6C for isms@ietf.org; Tue, 26 Jul 2005 23:46:10 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <2005072703134301300h4do6e>; Wed, 27 Jul 2005 03:13:43 +0000 From: "David B Harrington" To: "'Randy Presuhn'" , Subject: RE: [Isms] securityName Date: Tue, 26 Jul 2005 23:13:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <002f01c59243$3b9aec00$7f1afea9@oemcomputer> thread-index: AcWSQ1QEAsZXbcjsRdaBV+CY7qQB1gADX3RQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Randy, I have serious concerns with the EUSM dynamic population of the vacmSecurityToGroupTable. The SNMPv3 architecture separates authentication from access control so that subsystems can be updated with new models independent of other subsystems. We need to make a decision about which subsystem defines the user-to-group mappings or the architectural modularity goes to hell. The SNMPv3 WG decided this should be done in the access control subsystem. As I recall, the consensus of the SNMPv3 WG was that not all access control models would necessarily support a security-to-group mapping. VACM represented one approach to access control, but there were supporters of other approaches as well, especially for purposes of leveraging existing access control mechanisms. We need to be careful we don't limit future access control models to accommodate the VACM approach in this case. The EUSM approach of dynamically configuring the vacmSecurityToGroupTable violates the SNMPv3 architecture goals, since another security model (such as USM) would not necessarily do this dynamic configuration of VACM tables, and an access control model that doesn't use the vacmSecurityToGroupTable cannot work with the EUSM proposal. If the consensus of this WG (and the rest of the IETF, of course) is that it does make sense to require all security models to also generate a securityGroupName, then maybe we should define a user-to-group mapping table as part of the security (authentication) subsystem rather than as part of the access control subsystem, and modify USM and VACM to shift the vacmSecurityToGroupTable functionality into the USM security model, and change the ASIs to pass a groupname. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > Sent: Tuesday, July 26, 2005 8:37 PM > To: isms@ietf.org > Subject: Re: [Isms] securityName > > Hi - > > > From: "Juergen Schoenwaelder" > > To: "Tom Petch" > > Cc: > > Sent: Saturday, July 23, 2005 9:11 AM > > Subject: Re: [Isms] securityName > >> On Sat, Jul 23, 2005 at 03:26:47PM +0200, Tom Petch wrote: > ... > > > 2) when does the entry in the vacmSecurityToGroupTable > get created, when > > > destroyed w.r.t. a session? I see maintenance of that > table as a problem. > > > > For me, the vacmSecurityToGroupTable belongs to the access control > > configuration on the device and I therefore believe this is out of > > scope for ISMS at this point in time. > ... > > However, I'd like to remind folks what we wrote in section 3.3 of > http://www.ietf.org/internet-drafts/draft-ietf-isms-proposal-c > omparison-00.txt > > Dynamic authentication of users is not operationally sufficient, > given how VACM works. Requiring security administrators to > pre-configure the vacmSecurityToGroupTable [RFC3415] for > dynamically > authenticated users would defeat the whole purpose of doing dynamic > authentication. Consequently, the evaluation team recommends the > inclusion of something similar to the EUSM proposal's mechanism for > conveying user-to-group mappings from the AAA-server-equivalent. > This should not be confused with full-scale configuration of VACM, > which is out of scope for this working group. > > Randy > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 27 00:15:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxdGy-00074x-Ng; Wed, 27 Jul 2005 00:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxdGw-00074i-La for isms@megatron.ietf.org; Wed, 27 Jul 2005 00:11:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18263 for ; Wed, 27 Jul 2005 00:11:55 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxdm7-0004rg-EZ for isms@ietf.org; Wed, 27 Jul 2005 00:44:11 -0400 Received: from h-68-166-189-173.snvacaid.dynamic.covad.net ([68.166.189.173] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DxdGq-0001Xk-00 for isms@ietf.org; Wed, 27 Jul 2005 00:11:52 -0400 Message-ID: <00ec01c59261$679db940$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200507262313.1dXCmD6zL3Nl3oX0@new.mail.atl.earthlink.net> Subject: Re: [Isms] securityName Date: Tue, 26 Jul 2005 21:12:28 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: "'Randy Presuhn'" ; > Sent: Tuesday, July 26, 2005 8:13 PM > Subject: RE: [Isms] securityName ... > I have serious concerns with the EUSM dynamic population of the > vacmSecurityToGroupTable. EUSM doesn't populate the vacmSecurityToGroupTable. It provides a way for the mapping information for an authenticated user to be delivered from the authentication infrastructure, avoiding the need to pre-configure vacmSecurityToGroupTable for all users. Any solution that doesn't address this part of the problem will require that SNMP management systems touch every managed system whenever a user is created or deleted. (The former requirement is stronger than the latter, but the latter is a matter of configuration management sanity.) I would argue that, from an operational perspective, as long as SNMP management infrastructure has to touch vacmSecurityToGroupTable for every user add/delete, ISMS doesn't really make things any more manageable. > The SNMPv3 architecture separates authentication from access control > so that subsystems can be updated with new models independent of other > subsystems. We need to make a decision about which subsystem defines > the user-to-group mappings or the architectural modularity goes to > hell. The SNMPv3 WG decided this should be done in the access control > subsystem. The user/group mapping is an edge case. Although we put it in VACM (because it was an optimization to reduce the size of access control configuration) one could argue that this optimization (having a security name for auditing purposes, but mapping it to a role for purposes of allowing optimization of access control configuration size) is *relatively* security model neutral. Requiring the authentication infrastructure to tickle managed systems with VACM updates whenever a new user is added or deleted is not a very attractive integration, in my opinion, and would scale far less well than delivering the information when needed, i.e., when the user is authenticated. > As I recall, the consensus of the SNMPv3 WG was that not all access > control models would necessarily support a security-to-group mapping. Another way of looking at it is that in those other models we considered. each conceptual group would have exactly one user (snmpv2p) or a user might belong to multiple groups (Unix-like). Both could be supported by an EUSM-like way of delivering the information, regardless of architectural purity. > VACM represented one approach to access control, but there were > supporters of other approaches as well, especially for purposes of > leveraging existing access control mechanisms. We need to be careful > we don't limit future access control models to accommodate the VACM > approach in this case. Agree. But it's also important that ISMS actually addresses the integration problem. Propagation of full VACM configuration is out of scope, and I think this is ok. But not addressing the user/group mapping leaves us with a "solution" that is operationally only marginally better than what we have today: it makes key changes tidier, but doesn't simplify user add/delete. > The EUSM approach of dynamically configuring the > vacmSecurityToGroupTable violates the SNMPv3 architecture goals, It didn't actually create / delete table entries, if I recall correctly. Whether it should have is a separate discussion; I can see pros and cons both ways. We were careful in the evaluation to put it in terms of conveying the mappings, and not nail down whether those mappings would actually show up in the table, since this raises all sorts of interesting interaction questions. > since another security model (such as USM) would not necessarily do > this dynamic configuration of VACM tables, and an access control model > that doesn't use the vacmSecurityToGroupTable cannot work with the > EUSM proposal. I don't see how this follows. If a security model uses only the authenticated user name, then any group mappings delivered by the authentication service can be ignored. > If the consensus of this WG (and the rest of the IETF, of course) is > that it does make sense to require all security models to also > generate a securityGroupName, then maybe we should define a > user-to-group mapping table as part of the security (authentication) > subsystem rather than as part of the access control subsystem, and > modify USM and VACM to shift the vacmSecurityToGroupTable > functionality into the USM security model, and change the ASIs to pass > a groupname. ... I could see making the user/group mapping part of the security model, but I could also see making it part of the "glue" between them, since to some extent it's security model and access control model neutral. But I don't think such changes are *necessary*. All that's happening is that three related pieces of information are coming from the authentication server rather than two. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 27 00:50:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxds8-0008W6-6G; Wed, 27 Jul 2005 00:50:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxds6-0008W1-1x for isms@megatron.ietf.org; Wed, 27 Jul 2005 00:50:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20548 for ; Wed, 27 Jul 2005 00:50:19 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxeNI-0005tz-3h for isms@ietf.org; Wed, 27 Jul 2005 01:22:36 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 26 Jul 2005 21:50:13 -0700 X-IronPort-AV: i="3.95,145,1120460400"; d="scan'208"; a="200800361:sNHT29549704" Received: from kaushik-w2k03.cisco.com (sjc-vpn5-105.cisco.com [10.21.88.105]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6R4oA6q029484; Tue, 26 Jul 2005 21:50:10 -0700 (PDT) Message-Id: <6.2.0.14.0.20050716213936.03f74b80@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sat, 16 Jul 2005 21:50:08 -0700 To: ietfdbh@comcast.net From: Kaushik Narayan Subject: RE: [Isms] securityName In-Reply-To: <200507270313.XAA15807@ietf.org> References: <002f01c59243$3b9aec00$7f1afea9@oemcomputer> <200507270313.XAA15807@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.2 (+) 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, If we retain the user to group mapping as part of the access control subsystem (VACM), even though might obtain external user authentication via ISMS, we will still need operators to define all users on all agents since user to group mapping would need to be done locally. This will be a significant deterrent to ISMS deployment. This is the reason we took a pragmatic approach in EUSM by allowing the security model acquire the group mapping from the authentication system that can then be used by the access control model. This is a very common model of integration of access control with multiple authentication systems. regards, kaushik! At 08:13 PM 7/26/2005, David B Harrington wrote: >Hi Randy, > >I have serious concerns with the EUSM dynamic population of the >vacmSecurityToGroupTable. > >The SNMPv3 architecture separates authentication from access control >so that subsystems can be updated with new models independent of other >subsystems. We need to make a decision about which subsystem defines >the user-to-group mappings or the architectural modularity goes to >hell. The SNMPv3 WG decided this should be done in the access control >subsystem. > >As I recall, the consensus of the SNMPv3 WG was that not all access >control models would necessarily support a security-to-group mapping. >VACM represented one approach to access control, but there were >supporters of other approaches as well, especially for purposes of >leveraging existing access control mechanisms. We need to be careful >we don't limit future access control models to accommodate the VACM >approach in this case. > >The EUSM approach of dynamically configuring the >vacmSecurityToGroupTable violates the SNMPv3 architecture goals, >since another security model (such as USM) would not necessarily do >this dynamic configuration of VACM tables, and an access control model >that doesn't use the vacmSecurityToGroupTable cannot work with the >EUSM proposal. > >If the consensus of this WG (and the rest of the IETF, of course) is >that it does make sense to require all security models to also >generate a securityGroupName, then maybe we should define a >user-to-group mapping table as part of the security (authentication) >subsystem rather than as part of the access control subsystem, and >modify USM and VACM to shift the vacmSecurityToGroupTable >functionality into the USM security model, and change the ASIs to pass >a groupname. > >David Harrington >dbharrington@comcast.net > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > > Sent: Tuesday, July 26, 2005 8:37 PM > > To: isms@ietf.org > > Subject: Re: [Isms] securityName > > > > Hi - > > > > > From: "Juergen Schoenwaelder" > > > To: "Tom Petch" > > > Cc: > > > Sent: Saturday, July 23, 2005 9:11 AM > > > Subject: Re: [Isms] securityName > > >> On Sat, Jul 23, 2005 at 03:26:47PM +0200, Tom Petch wrote: > > ... > > > > 2) when does the entry in the vacmSecurityToGroupTable > > get created, when > > > > destroyed w.r.t. a session? I see maintenance of that > > table as a problem. > > > > > > For me, the vacmSecurityToGroupTable belongs to the access control > > > configuration on the device and I therefore believe this is out of > > > scope for ISMS at this point in time. > > ... > > > > However, I'd like to remind folks what we wrote in section 3.3 of > > http://www.ietf.org/internet-drafts/draft-ietf-isms-proposal-c > > omparison-00.txt > > > > Dynamic authentication of users is not operationally sufficient, > > given how VACM works. Requiring security administrators to > > pre-configure the vacmSecurityToGroupTable [RFC3415] for > > dynamically > > authenticated users would defeat the whole purpose of doing >dynamic > > authentication. Consequently, the evaluation team recommends the > > inclusion of something similar to the EUSM proposal's mechanism >for > > conveying user-to-group mappings from the AAA-server-equivalent. > > This should not be confused with full-scale configuration of >VACM, > > which is out of scope for this working group. > > > > Randy > > > > > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 27 08:50:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxlN2-000521-Mm; Wed, 27 Jul 2005 08:50:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxlN0-0004z4-Qp for isms@megatron.ietf.org; Wed, 27 Jul 2005 08:50:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24247 for ; Wed, 27 Jul 2005 08:50:44 -0400 (EDT) Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxlsG-0003os-8J for isms@ietf.org; Wed, 27 Jul 2005 09:23:05 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) 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 j6RCoYJC013426 for ; Wed, 27 Jul 2005 12:50: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 j6RCo3X4000828 for ; Wed, 27 Jul 2005 12:50:34 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 M2005072705503417493 for ; Wed, 27 Jul 2005 05:50:34 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 05:50:34 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 05:50:33 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 08:50:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] securityName Date: Wed, 27 Jul 2005 08:47:22 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929018B79F0@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] securityName Thread-Index: AcWSZtGOwfXIjp+5TqSKeEzh+gxJZQAQQ40g From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 27 Jul 2005 12:50:32.0989 (UTC) FILETIME=[C6A704D0:01C592A9] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I think Randy is 100% correct in his evaluaion of usage of VACM in general and vacmSecurityToGroupTable in particular. More so, I too consider the user-to-group mapping as a "glue" that is necessary for any practical solution. Without such glue packet/user authentication and packet encryption is useless. More so, I believe that dynamic authentication is necessary if people want to avoid static pre-configuration of SNMP users.=20 Having one source providing all of the following: , seems well aligned with the ISMS goal to use external-to-SNMP already-deployed security infrastructure and to off-load the configuration and decision-making burden to somebody else (RADIUS in case of EUSM). Kaushik, I agree with what you said. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Kaushik Narayan Sent: Sunday, July 17, 2005 12:50 AM To: ietfdbh@comcast.net Cc: isms@ietf.org Subject: RE: [Isms] securityName Hi David, If we retain the user to group mapping as part of the access control subsystem (VACM), even though might obtain external user authentication via ISMS, we will still need operators to define all users on all agents since user to group mapping would need to be done locally. This will be a significant deterrent to ISMS deployment. This is the reason we took a pragmatic approach in EUSM by allowing the security model acquire the group mapping from the authentication system that can then be used by the access control model. This is a very common model of integration of access control with multiple authentication systems. regards, kaushik! At 08:13 PM 7/26/2005, David B Harrington wrote: >Hi Randy, > >I have serious concerns with the EUSM dynamic population of the >vacmSecurityToGroupTable. > >The SNMPv3 architecture separates authentication from access control >so that subsystems can be updated with new models independent of other >subsystems. We need to make a decision about which subsystem defines >the user-to-group mappings or the architectural modularity goes to >hell. The SNMPv3 WG decided this should be done in the access control >subsystem. > >As I recall, the consensus of the SNMPv3 WG was that not all access >control models would necessarily support a security-to-group mapping. >VACM represented one approach to access control, but there were >supporters of other approaches as well, especially for purposes of >leveraging existing access control mechanisms. We need to be careful >we don't limit future access control models to accommodate the VACM >approach in this case. > >The EUSM approach of dynamically configuring the >vacmSecurityToGroupTable violates the SNMPv3 architecture goals, >since another security model (such as USM) would not necessarily do >this dynamic configuration of VACM tables, and an access control model >that doesn't use the vacmSecurityToGroupTable cannot work with the >EUSM proposal. > >If the consensus of this WG (and the rest of the IETF, of course) is >that it does make sense to require all security models to also >generate a securityGroupName, then maybe we should define a >user-to-group mapping table as part of the security (authentication) >subsystem rather than as part of the access control subsystem, and >modify USM and VACM to shift the vacmSecurityToGroupTable >functionality into the USM security model, and change the ASIs to pass >a groupname. > >David Harrington >dbharrington@comcast.net > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > > Sent: Tuesday, July 26, 2005 8:37 PM > > To: isms@ietf.org > > Subject: Re: [Isms] securityName > > > > Hi - > > > > > From: "Juergen Schoenwaelder" > > > To: "Tom Petch" > > > Cc: > > > Sent: Saturday, July 23, 2005 9:11 AM > > > Subject: Re: [Isms] securityName > > >> On Sat, Jul 23, 2005 at 03:26:47PM +0200, Tom Petch wrote: > > ... > > > > 2) when does the entry in the vacmSecurityToGroupTable > > get created, when > > > > destroyed w.r.t. a session? I see maintenance of that > > table as a problem. > > > > > > For me, the vacmSecurityToGroupTable belongs to the access control > > > configuration on the device and I therefore believe this is out of > > > scope for ISMS at this point in time. > > ... > > > > However, I'd like to remind folks what we wrote in section 3.3 of > > http://www.ietf.org/internet-drafts/draft-ietf-isms-proposal-c > > omparison-00.txt > > > > Dynamic authentication of users is not operationally sufficient, > > given how VACM works. Requiring security administrators to > > pre-configure the vacmSecurityToGroupTable [RFC3415] for > > dynamically > > authenticated users would defeat the whole purpose of doing >dynamic > > authentication. Consequently, the evaluation team recommends the > > inclusion of something similar to the EUSM proposal's mechanism >for > > conveying user-to-group mappings from the AAA-server-equivalent. > > This should not be confused with full-scale configuration of >VACM, > > which is out of scope for this working group. > > > > Randy > > > > > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 27 09:21:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxlqK-0006Ok-46; Wed, 27 Jul 2005 09:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxlqI-0006Of-Tl for isms@megatron.ietf.org; Wed, 27 Jul 2005 09:21:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26878 for ; Wed, 27 Jul 2005 09:21:00 -0400 (EDT) Message-Id: <200507271321.JAA26878@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxmLZ-0004vu-6f for isms@ietf.org; Wed, 27 Jul 2005 09:53:21 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <200507271320520140004egge>; Wed, 27 Jul 2005 13:20:52 +0000 From: "David B Harrington" To: "'Kaushik Narayan'" Subject: RE: [Isms] securityName Date: Wed, 27 Jul 2005 09:20:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <6.2.0.14.0.20050716213936.03f74b80@email.cisco.com> thread-index: AcWSZqyZkymBIrDhTs6tnRfqh9f6WgAPvi/w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I understand why this was done, and I personally prefer that the user-to-group mapping be done as part of the authentication mechanism for exactly the reasons that you and Randy and Uri argue - if we don't automate this dynamic mapping, the goals of ISMS (as compared to the charter of ISMS) will not be met, and user adds/deletes would be difficult to work with. I think it makes sense because the user-to-group mapping is likely to be as volatile as the user-authentication itself, while the rest of the access control subsystem configuration is likely to be fairly static. My issue is about compliance with the modularity requirement. We cannot have the user-to-group mapping done by some, but not all, security models, or, in order to provide group-level access controls, the access control models will need to know about the "glue" provided by different security models, and we end up with unwanted bindings between the models. We need to make it unambiguous which subsystem has the responsibility for this task, and what the interfaces between subsystems (ASIs) look like, or security models and access control models cannot be freely mixed and matched. After the SNMPv2 meltdown, which was largely the result of the SNMPv2 architecture being monolithic rather than modular so you could not address specific issues without causing side effects on everything else, I don't want to see us throw out the modularity requirements. I cannot stress enough how important modularity is to SNMPv3 being able to accommodate different industry segments' differing requirements. If everybody is in agreement that the user-to-group mapping functionality should be handled by the authentication subsystem, then I suggest we figure out a way to make such an architectural change to SNMPv3, and retro-fit USM and VACM to that change. This, of course, is out of scope for this WG, but might be a necessary change to meet ISMS goals. If we are not allowed to modify the architecture, then we may need to provide a standard hack to achieve the same effect. If the security model has the responsibility, then we need to determine how that mapping gets passed to the access control subsystem. It might be as simple as standardizing a modification to securityName, to use a format similar to "user (group1, group2, ...)", or simply passes the groupname as the securityName (but this would be difficult for specifying the outgoing user-principal). If we do this, we need to make it standard so security models know how to construct the securityName, and access control models know how to extract the information in a consistent manner. How and whether different access control models utilize the group information would be up to the specific access control models. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Kaushik Narayan [mailto:kaushik@cisco.com] > Sent: Sunday, July 17, 2005 12:50 AM > To: ietfdbh@comcast.net > Cc: 'Randy Presuhn'; isms@ietf.org > Subject: RE: [Isms] securityName > > Hi David, > > If we retain the user to group mapping as part of the access control > subsystem (VACM), even though might obtain external user > authentication via ISMS, we will still need operators to > define all users > on all agents since user to group mapping would need to be done > locally. This will be a significant deterrent to ISMS deployment. > > This is the reason we took a pragmatic approach in EUSM by allowing > the security model acquire the group mapping from the authentication > system that can then be used by the access control model. This is a > very common model of integration of access control with multiple > authentication systems. > > regards, > kaushik! > > > > At 08:13 PM 7/26/2005, David B Harrington wrote: > >Hi Randy, > > > >I have serious concerns with the EUSM dynamic population of the > >vacmSecurityToGroupTable. > > > >The SNMPv3 architecture separates authentication from access control > >so that subsystems can be updated with new models > independent of other > >subsystems. We need to make a decision about which subsystem defines > >the user-to-group mappings or the architectural modularity goes to > >hell. The SNMPv3 WG decided this should be done in the access control > >subsystem. > > > >As I recall, the consensus of the SNMPv3 WG was that not all access > >control models would necessarily support a security-to-group mapping. > >VACM represented one approach to access control, but there were > >supporters of other approaches as well, especially for purposes of > >leveraging existing access control mechanisms. We need to be careful > >we don't limit future access control models to accommodate the VACM > >approach in this case. > > > >The EUSM approach of dynamically configuring the > >vacmSecurityToGroupTable violates the SNMPv3 architecture goals, > >since another security model (such as USM) would not necessarily do > >this dynamic configuration of VACM tables, and an access > control model > >that doesn't use the vacmSecurityToGroupTable cannot work with the > >EUSM proposal. > > > >If the consensus of this WG (and the rest of the IETF, of course) is > >that it does make sense to require all security models to also > >generate a securityGroupName, then maybe we should define a > >user-to-group mapping table as part of the security (authentication) > >subsystem rather than as part of the access control subsystem, and > >modify USM and VACM to shift the vacmSecurityToGroupTable > >functionality into the USM security model, and change the > ASIs to pass > >a groupname. > > > >David Harrington > >dbharrington@comcast.net > > > > > -----Original Message----- > > > From: isms-bounces@lists.ietf.org > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > > > Sent: Tuesday, July 26, 2005 8:37 PM > > > To: isms@ietf.org > > > Subject: Re: [Isms] securityName > > > > > > Hi - > > > > > > > From: "Juergen Schoenwaelder" > > > > To: "Tom Petch" > > > > Cc: > > > > Sent: Saturday, July 23, 2005 9:11 AM > > > > Subject: Re: [Isms] securityName > > > >> On Sat, Jul 23, 2005 at 03:26:47PM +0200, Tom Petch wrote: > > > ... > > > > > 2) when does the entry in the vacmSecurityToGroupTable > > > get created, when > > > > > destroyed w.r.t. a session? I see maintenance of that > > > table as a problem. > > > > > > > > For me, the vacmSecurityToGroupTable belongs to the > access control > > > > configuration on the device and I therefore believe > this is out of > > > > scope for ISMS at this point in time. > > > ... > > > > > > However, I'd like to remind folks what we wrote in section 3.3 of > > > http://www.ietf.org/internet-drafts/draft-ietf-isms-proposal-c > > > omparison-00.txt > > > > > > Dynamic authentication of users is not operationally > sufficient, > > > given how VACM works. Requiring security administrators to > > > pre-configure the vacmSecurityToGroupTable [RFC3415] for > > > dynamically > > > authenticated users would defeat the whole purpose of doing > >dynamic > > > authentication. Consequently, the evaluation team > recommends the > > > inclusion of something similar to the EUSM proposal's mechanism > >for > > > conveying user-to-group mappings from the > AAA-server-equivalent. > > > This should not be confused with full-scale configuration of > >VACM, > > > which is out of scope for this working group. > > > > > > Randy > > > > > > > > > > > > > > > _______________________________________________ > > > Isms mailing list > > > Isms@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > > > >_______________________________________________ > >Isms mailing list > >Isms@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 27 09:30:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxlzk-0000FR-D2; Wed, 27 Jul 2005 09:30:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxlzi-0000FC-AI for isms@megatron.ietf.org; Wed, 27 Jul 2005 09:30:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27585 for ; Wed, 27 Jul 2005 09:30:44 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxmUv-0005GP-H4 for isms@ietf.org; Wed, 27 Jul 2005 10:03:05 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 7CE2939235 for ; Wed, 27 Jul 2005 15:30:26 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08366-09 for ; Wed, 27 Jul 2005 15:30:25 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 7F881390EE for ; Wed, 27 Jul 2005 15:30:24 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 8D08E397C4F; Wed, 27 Jul 2005 09:21:06 +0200 (CEST) Date: Wed, 27 Jul 2005 09:21:06 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Subject: Re: [Isms] securityName Message-ID: <20050727072106.GA1530@boskop.local> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <200507262313.1dXCmD6zL3Nl3oX0@new.mail.atl.earthlink.net> <00ec01c59261$679db940$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00ec01c59261$679db940$7f1afea9@oemcomputer> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.6 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Tue, Jul 26, 2005 at 09:12:28PM -0700, Randy Presuhn wrote: > Any solution that doesn't address this part of the problem will require > that SNMP management systems touch every managed system whenever > a user is created or deleted. (The former requirement is stronger than the > latter, but the latter is a matter of configuration management sanity.) > I would argue that, from an operational perspective, as long as SNMP > management infrastructure has to touch vacmSecurityToGroupTable > for every user add/delete, ISMS doesn't really make things any more > manageable. I believe the mapping of a user identity to the group determines this user identities' access rights. Hence I consider this mapping being part of VACM access control. In fact, the whole group concept is a VACM concept and does not exist as an architectural concept visible outside this specific access control model. Correct me if I am wrong. The objective of SNMP over TLS/SSH is to leverage existing on-the-wire security protocols with the main goal to reuse keying material / mechanisms that is/are already known by the device. Sure, this does not address the access control configuration issue and how you can get access control information from a central repository, e.g. an AAA server - I think this is not a bug. My understanding of the charter is that we were asked to solve the first part of the problem and if we manage to get agreement in a timely fashion (!), we might do followup work to address the other part of the problem space. Note that I would love to have a mechanism to define full ACM configs in a centralized fashion for all the boxes I worry about. Perhaps we have to simply agree that this is just device configuration like any other access control lists and hope that NETCONF provides the tools to solve this. (All VACM configurations I have ever created for operational purposes were actually written either by editing config files on hosts or by using CLI commands.) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 27 09:30:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxlzk-0000Fp-M0; Wed, 27 Jul 2005 09:30:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxlzj-0000FH-3i for isms@megatron.ietf.org; Wed, 27 Jul 2005 09:30:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27603 for ; Wed, 27 Jul 2005 09:30:44 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxmUv-0005GO-H8 for isms@ietf.org; Wed, 27 Jul 2005 10:03:06 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id AC22E391C0; Wed, 27 Jul 2005 15:30:25 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08465-02; Wed, 27 Jul 2005 15:30:24 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 768F0EAED; Wed, 27 Jul 2005 15:30:24 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 516FE397DB7; Wed, 27 Jul 2005 14:36:14 +0200 (CEST) Date: Wed, 27 Jul 2005 14:36:13 +0200 From: Juergen Schoenwaelder To: Kaushik Narayan Subject: Re: [Isms] securityName Message-ID: <20050727123613.GA2030@boskop.local> Mail-Followup-To: Kaushik Narayan , ietfdbh@comcast.net, isms@ietf.org References: <002f01c59243$3b9aec00$7f1afea9@oemcomputer> <200507270313.XAA15807@ietf.org> <6.2.0.14.0.20050716213936.03f74b80@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.0.14.0.20050716213936.03f74b80@email.cisco.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Sat, Jul 16, 2005 at 09:50:08PM -0700, Kaushik Narayan wrote: > If we retain the user to group mapping as part of the access control > subsystem (VACM), even though might obtain external user > authentication via ISMS, we will still need operators to define all users > on all agents since user to group mapping would need to be done > locally. This will be a significant deterrent to ISMS deployment. > > This is the reason we took a pragmatic approach in EUSM by allowing > the security model acquire the group mapping from the authentication > system that can then be used by the access control model. This is a > very common model of integration of access control with multiple > authentication systems. What about an extension of the VACM security name to group mapping feature which allows to express policies like "all access with a given security level for a given security model map into group xyz". Such a rule would not need to change if you add/remove authenticated identities and it probably is good enough for many operational environments. For those who need finer grained access control, you can still use the existing VACM security name to group mapping mechanism. I am thinking loud here - so there might be reasons why this won't work. But that put aside, if something like this makes sense, I still consider this architectually an extension of VACM. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 27 09:38:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxm73-0002pm-KI; Wed, 27 Jul 2005 09:38:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxm71-0002pF-Kv for isms@megatron.ietf.org; Wed, 27 Jul 2005 09:38:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28248 for ; Wed, 27 Jul 2005 09:38:17 -0400 (EDT) Message-Id: <200507271338.JAA28248@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxmcF-0005XJ-75 for isms@ietf.org; Wed, 27 Jul 2005 10:10:38 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <2005072713380601300h5u8se>; Wed, 27 Jul 2005 13:38:06 +0000 From: "David B Harrington" To: "'Blumenthal, Uri'" , Subject: RE: [Isms] securityName Date: Wed, 27 Jul 2005 09:38:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <3DEC199BD7489643817ECA151F7C5929018B79F0@pysmsx401.amr.corp.intel.com> thread-index: AcWSZtGOwfXIjp+5TqSKeEzh+gxJZQAQQ40gAAGUL4A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Uri, > -----Original Message----- > Having one source providing all of the following: authenticity, mapping to VACM group>, seems well aligned with the ISMS > goal to use external-to-SNMP already-deployed security infrastructure > and to off-load the configuration and decision-making burden > to somebody > else (RADIUS in case of EUSM). > I agree that this is a nice feature of RADIUS. But what about security models that don't use RADIUS? Is this also a feature available from say, SSH or TLS or Kerberos or other security infrastructure? If not, who provides the dynamic user-to-group mappings? Do we call RADIUS after we have authenticated and decrypted the TLS-protected message, to get the user-to-group mappings? Will this require another user-authentication step? If the BEEP TMSM proposal is accepted, for example, how will the user-to-group mappings be accomplished? Is this something that all proposed security models must specify? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 27 11:05:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxnTN-0003UI-Bp; Wed, 27 Jul 2005 11:05:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxnTL-0003U1-BD for isms@megatron.ietf.org; Wed, 27 Jul 2005 11:05:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05427 for ; Wed, 27 Jul 2005 11:05:24 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxnyb-0008JH-LC for isms@ietf.org; Wed, 27 Jul 2005 11:37:47 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 27 Jul 2005 08:05:17 -0700 Received: from kaushik-w2k03.cisco.com (sjc-vpn5-105.cisco.com [10.21.88.105]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6RF5D6q028212; Wed, 27 Jul 2005 08:05:14 -0700 (PDT) Message-Id: <6.2.0.14.0.20050717074153.03f49980@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sun, 17 Jul 2005 08:05:10 -0700 To: ietfdbh@comcast.net From: Kaushik Narayan Subject: RE: [Isms] securityName In-Reply-To: <200507271338.JAA28248@ietf.org> References: <3DEC199BD7489643817ECA151F7C5929018B79F0@pysmsx401.amr.corp.intel.com> <200507271338.JAA28248@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.2 (+) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, Here is a list of external authentication mechanisms that are required to be supported from the ISMS charter - Radius - TACACS+ - Kerberos - LDAP - Diameter All of these authentication protocols except for Kerberos have means to acquire user-to-group mapping and provide that information to SNMP engines. RADIUS, TACACS+ and Diameter require appropriate attributes to defined to communicate this information. Acquiring Group information in LDAP is pretty standard. Kerberos is probably the only exception since this is implementation specific. Only the Windows KDC acquires the AD user groups and saves that information in the Privilege Attribute Certificate (PAC). The user-to-group mapping will work identical with any ISMS transport protocol/ security model. regards, kaushik! At 06:38 AM 7/27/2005, David B Harrington wrote: >Hi Uri, > > > -----Original Message----- > > Having one source providing all of the following: > authenticity, mapping to VACM group>, seems well aligned with the >ISMS > > goal to use external-to-SNMP already-deployed security >infrastructure > > and to off-load the configuration and decision-making burden > > to somebody > > else (RADIUS in case of EUSM). > > > >I agree that this is a nice feature of RADIUS. But what about security >models that don't use RADIUS? Is this also a feature available from >say, SSH or TLS or Kerberos or other security infrastructure? If not, >who provides the dynamic user-to-group mappings? > >Do we call RADIUS after we have authenticated and decrypted the >TLS-protected message, to get the user-to-group mappings? Will this >require another user-authentication step? > >If the BEEP TMSM proposal is accepted, for example, how will the >user-to-group mappings be accomplished? Is this something that all >proposed security models must specify? > >David Harrington >dbharrington@comcast.net > > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 27 12:32:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxoq2-0007s9-JP; Wed, 27 Jul 2005 12:32:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxoq1-0007s1-B2 for isms@megatron.ietf.org; Wed, 27 Jul 2005 12:32:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12527 for ; Wed, 27 Jul 2005 12:32:53 -0400 (EDT) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxpLH-0002zs-1U for isms@ietf.org; Wed, 27 Jul 2005 13:05:17 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j6RGWjZp015047; Wed, 27 Jul 2005 16:32:45 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 j6RGWZX8008764; Wed, 27 Jul 2005 16:32:45 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 M2005072709324404797 ; Wed, 27 Jul 2005 09:32:45 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 09:32:44 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 09:32:44 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 12:32:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] securityName Date: Wed, 27 Jul 2005 12:29:28 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929018B7D3E@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] securityName Thread-Index: AcWSZtGOwfXIjp+5TqSKeEzh+gxJZQAQQ40gAAGUL4AAA/looA== From: "Blumenthal, Uri" To: , X-OriginalArrivalTime: 27 Jul 2005 16:32:42.0780 (UTC) FILETIME=[CFD3B5C0:01C592C8] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >> Having one source providing all of the following: > authenticity, mapping to VACM group>, seems well aligned with the >> ISMS goal to use external-to-SNMP already-deployed security >> infrastructure and to off-load the configuration and decision-making >> burden to somebody else (RADIUS in case of EUSM). >=20 > > I agree that this is a nice feature of RADIUS. But what about security > models that don't use RADIUS? Is this also a feature available from > say, SSH or TLS or Kerberos or other security infrastructure? If not, > who provides the dynamic user-to-group mappings? The answer of course is - SNMP (Simply Not My Problem). Obtaining this mapping SOMEHOW SOMEWHERE BY SOMEBODY clearly is a-must - without it security model cannot be used. Some authentication systems deal also with authorization, and thus are capable of providing such mapping as part of their "normal" service. Some others - this capability can be hacked into. And some just can't do it, tough luck - for those an extra service must be designed/implemented/deployed together with this new security model, or the whole thing won't be deployable (what good is having TLS-authenticated and encrypted traffic stream, if there is no way to specify whether or not execute the commands carried by that stream?). The short of it is - it has to be done, somehow somewhere. The easiest place for it is nEWSM (see below), as it encapsulates this extra work from other components. And while it doesn't HAVE to be a part of nEWSM itself - releasing a security model without a clear idea of how its output will be mapped onto VACM (or other ACM), IMHO is a waste of time. > Do we call RADIUS after we have authenticated and decrypted the > TLS-protected message, to get the user-to-group mappings? Will this > require another user-authentication step? IMHO, no. Caveat: I'm coming from the idea of sessions. Otherwise the cost of online queries and possible public key cryptography cannot be justified (it got to be amortized across multiple exchanges utilizing the same credentials that were obtained and paid for so dearly, tied together into a "structure" I call "session"). When this nEWSM (not Extended Wonderful Security System) negotiates and establishes a "session", in addition to figuring out what identities are being authenticated and authenticating them, what crypto parameters to use (auth and encr algorithms, keys, lifetime, etc.) it also figures what access rights the authenticated identities should have to SNMP objects and maps those rights onto VACM by providing SecurityToGroup table entries. IF NEWSM DOES NOT DO THAT. { If nEWSM doesn't do that - then somebody else has to either=20 (a) recognize the identity as it comes out of nEWSM, preferably at the time of(or soon after) the successful authentication. So that subsequent traffic messages can be processed without undue delay and overhead; (b) know what VACM rights to give to it; (c) express that knowledge by populating vacmSecurityToGroupTable. or (a) beforehand know all the possible identities that can come out of nEWSM; (b) determine what rights to assign them; and (c) express that knowledge by populating vacmSecurityToGroupTable. Also, this may increase the difficulty of using dynamic names for SNMP authentication and sessions, difficulties in figuring out lifetime of authentication (for how long should authentication result be valid?) etc. etc. It also may mean that SNMPv3 architecture changes and a new Module is introduced: SM-to-ACM Mapper, with defines functionality, ASI, interfaces, etc. } One simple alternative is: "all the identities coming from nEWSM are on the same level and shall be granted access level X defined by VACM group Y", then define a VACM group for nEWSM. It can work - but makes logging more difficult, and is a touch hard on access granularity. And still somebody has to insert that one entry into VACM table. Another alternative is - write a piece of code that maps Unix groups onto some very limited VACM groups and populate vacmSecurityToGroupTable with those. Then have nEWSM use Unix identities as securityName, and an extra module that determines the group by doing system lookup. Of course those who do not use Unix groups in their security infrastructure, won't be happy with this approach. These poor alternatives are brought here mostly to demonstrate the importance of that mapping, and the great benefits of having it somehow integrated into Security Model, rather than having to figure it out elsewhere. > If the BEEP TMSM proposal is accepted, for example, how will the > user-to-group mappings be accomplished? Don't know. SNMP (see above :-). > Is this something that all proposed security models must specify? IMHO - yes. Because no nEWSM can be deployed, until a co-proposal is written and accepted - that defines how to use securityName's it returns with VACM. Because otherwise those who find it difficult to populate and maintain User database and want to off-load it to RADIUS or Kerberos, will surely find it as difficult to populate and maintain VACM user-to-group database (as the problems are very tightly coupled). In the end, they still won't deploy it until all the I's are dotted. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 27 14:08:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxqKm-0004xc-E8; Wed, 27 Jul 2005 14:08:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxqKi-0004xU-Eg for isms@megatron.ietf.org; Wed, 27 Jul 2005 14:08:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19119 for ; Wed, 27 Jul 2005 14:08:42 -0400 (EDT) Received: from ibfb9.i.pppool.de ([85.73.191.185] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxqpy-00065m-Co for isms@ietf.org; Wed, 27 Jul 2005 14:41:05 -0400 Received: by boskop.local (Postfix, from userid 501) id B9BBC3981AA; Wed, 27 Jul 2005 20:08:28 +0200 (CEST) Date: Wed, 27 Jul 2005 20:08:28 +0200 From: Juergen Schoenwaelder To: "Blumenthal, Uri" Subject: Re: [Isms] securityName Message-ID: <20050727180828.GA3015@boskop.local> Mail-Followup-To: "Blumenthal, Uri" , ietfdbh@comcast.net, isms@ietf.org References: <3DEC199BD7489643817ECA151F7C5929018B7D3E@pysmsx401.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DEC199BD7489643817ECA151F7C5929018B7D3E@pysmsx401.amr.corp.intel.com> User-Agent: Mutt/1.5.9i 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 Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Wed, Jul 27, 2005 at 12:29:28PM -0400, Blumenthal, Uri wrote: > These poor alternatives are brought here mostly to demonstrate the > importance of that mapping, and the great benefits of having it somehow > integrated into Security Model, rather than having to figure it out > elsewhere. The security name to group mapping is just a little piece of the access control decision. I fail to see why solving this piece is of such high importance while we ignore the rest. I believe that the rest (that is the definition of suitable vacm views) is rather static and on most devices will not change much during the lifetime of the device. I also believe that a wildcard authenticated user via mechanism xyz maps to group abc is going to be rather static in most installations and hence it can be configured like all the rest of VACM. Sure, having the capability to retrieve VACM rules from a trusted AAA server would be nice. I doubt, however, this is as crucial for this work to succeed than some of the other people here. Anyway, if this is crucial, then I think the proper solution is to fix the charter. /js P.S. I believe there is quite some confusion in this discussion about the usage of the word "group". VACM groups are surely very different from UNIX groups and I also believe that some of the AAA protocols mentions have yet other interpretations of groups. Perhaps this needs to be untangled in Paris. -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 27 14:32:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxqhH-0007Oa-24; Wed, 27 Jul 2005 14:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxqhG-0007N4-E3 for isms@megatron.ietf.org; Wed, 27 Jul 2005 14:32:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21246 for ; Wed, 27 Jul 2005 14:32:00 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxrCQ-00073D-Pq for isms@ietf.org; Wed, 27 Jul 2005 15:04:24 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j6RIVkZC028714 for ; Wed, 27 Jul 2005 14:31:46 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 27 Jul 2005 14:31:46 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 27 Jul 2005 14:31:46 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 27 Jul 2005 14:31:46 -0400 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] securityName Date: Wed, 27 Jul 2005 14:31:45 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103247F@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] securityName Thread-Index: AcWS1y9qjoeyLTIzTim6nC92jbw43gAAPtmA From: "Nelson, David" To: X-OriginalArrivalTime: 27 Jul 2005 18:31:46.0257 (UTC) FILETIME=[71ABCC10:01C592D9] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:82.4442 M:98.8113 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen Schoenwaelder writes... > I believe that the rest (that is the definition of suitable vacm views) > is rather static and on most devices will not change much during the > lifetime of the device. I agree that this is the most likely scenario. > I also believe that a wildcard authenticated > user via mechanism xyz maps to group abc is going to be rather static > in most installations and hence it can be configured like all the > rest of VACM. Here, I beg to disagree. My vision of authorization is that access control levels or policies are assigned to individuals based on their role within the organization. While everyone in a particular organization may authenticate via the same method, they may have differing roles which require a different access control policy to be applied.=20 > Sure, having the capability to retrieve VACM rules from a trusted AAA > server would be nice. I doubt, however, this is as crucial for this > work to succeed than some of the other people here. Anyway, if this > is crucial, then I think the proper solution is to fix the charter. Retrieving the actual VACM table entries is not something that ISMS needs to solve, IMHO. As you say, these tend to be relatively static, based on pre-defined roles, such as Help Desk Support vs. Network Administrator. I do think that the *binding* of the securityName to whatever "name" might be used to index locally stored access control rules should be provided as part of the authentication method. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 27 15:02:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxrAi-0006rL-4r; Wed, 27 Jul 2005 15:02:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxrAg-0006rG-Ur for isms@megatron.ietf.org; Wed, 27 Jul 2005 15:02:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23830 for ; Wed, 27 Jul 2005 15:02:24 -0400 (EDT) Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxrfz-00080l-6f for isms@ietf.org; Wed, 27 Jul 2005 15:34:48 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j6RJ2Gv4021342 for ; Wed, 27 Jul 2005 19:02:16 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j6RJ2DWo028118 for ; Wed, 27 Jul 2005 19:02:16 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005072712021220454 for ; Wed, 27 Jul 2005 12:02:12 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 12:02:12 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 12:02:12 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 15:02:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] securityName Date: Wed, 27 Jul 2005 14:58:56 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929018B7FAA@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] securityName Thread-Index: AcWS1y9qjoeyLTIzTim6nC92jbw43gAAPtmAAAD8QZA= From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 27 Jul 2005 19:02:11.0521 (UTC) FILETIME=[B19CFB10:01C592DD] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > Retrieving the actual VACM table entries is not something that ISMS > needs to solve, IMHO. As you say, these tend to be relatively static, > based on pre-defined roles, such as Help Desk Support vs. Network > Administrator.=20 *Retrieving* VACM table entries isn't something that needs to be solved *here*, IMHO. Providing a sure-to-work not-burdensome way to do the mapping - is, IMHO. =20 And we should realize that until *both* SM and ACM issues are resolved somehow, there will be no deployment (by those who want to reuse existing configs and not to bother with extras). > I do think that the *binding* of the securityName to > whatever "name" might be used to index locally stored access control > rules should be provided as part of the authentication method. Yes.=20 Plus guidance that tells people (most of who want no-touch config) what entries they must insert into VACM tables to make this working. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 27 16:15:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxsFM-0002JO-1N; Wed, 27 Jul 2005 16:11:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxsFK-0002JH-Eu for isms@megatron.ietf.org; Wed, 27 Jul 2005 16:11:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29161 for ; Wed, 27 Jul 2005 16:11:15 -0400 (EDT) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxskd-0001eH-Af for isms@ietf.org; Wed, 27 Jul 2005 16:43:40 -0400 Received: from pc6 (1Cust173.tnt104.lnd4.gbr.da.uu.net [213.116.56.173]) by ranger.systems.pipex.net (Postfix) with SMTP id 3C610E000142; Wed, 27 Jul 2005 21:10:56 +0100 (BST) Message-ID: <003d01c592de$c95f7b00$0601a8c0@pc6> From: "Tom Petch" To: "Blumenthal, Uri" , References: <3DEC199BD7489643817ECA151F7C5929018B7D3E@pysmsx401.amr.corp.intel.com> Subject: Re: [Isms] securityName Date: Wed, 27 Jul 2005 21:09:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Blumenthal, Uri" To: ; Sent: Wednesday, July 27, 2005 6:29 PM Subject: RE: [Isms] securityName >> Having one source providing all of the following: > authenticity, mapping to VACM group>, seems well aligned with the >> ISMS goal to use external-to-SNMP already-deployed security >> infrastructure and to off-load the configuration and decision-making >> burden to somebody else (RADIUS in case of EUSM). > > I agree that this is a nice feature of RADIUS. But what about security > models that don't use RADIUS? Is this also a feature available from > say, SSH or TLS or Kerberos or other security infrastructure? If not, > who provides the dynamic user-to-group mappings? The answer of course is - SNMP (Simply Not My Problem). Obtaining this mapping SOMEHOW SOMEWHERE BY SOMEBODY clearly is a-must - without it security model cannot be used. Some authentication systems deal also with authorization, and thus are capable of providing such mapping as part of their "normal" service. Some others - this capability can be hacked into. And some just can't do it, tough luck - for those an extra service must be designed/implemented/deployed together with this new security model, or the whole thing won't be deployable (what good is having TLS-authenticated and encrypted traffic stream, if there is no way to specify whether or not execute the commands carried by that stream?). [tp] Yes, absolutely. isms is about reusing existing security systems at least in part, whereas SNMPv3 USM + VACM set out to do everything alone and unaided. We have left open the question of just what we get from an existing security system (beyond authentication of an enduser) and for me, the more we use, the more we integrate, the better. I am used to a widely deployed proprietary security system (it did get a mention in Wes's survey) which does provide very fine grained and powerful definitions of authorization, access rights, privileges etc. So I have no problem with a solution that says that this information, mapping of end user to role and authorization, comes from elsewhere, be that open standard like RADIUS or proprietary, as I am more used to. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 27 17:42:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxtfd-00040e-Rk; Wed, 27 Jul 2005 17:42:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxtfc-00040Z-1B for isms@megatron.ietf.org; Wed, 27 Jul 2005 17:42:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05277 for ; Wed, 27 Jul 2005 17:42:28 -0400 (EDT) Received: from i811f.i.pppool.de ([85.73.129.31] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxuAw-0004Nx-Pm for isms@ietf.org; Wed, 27 Jul 2005 18:14:55 -0400 Received: by boskop.local (Postfix, from userid 501) id 18C9D3982E6; Wed, 27 Jul 2005 23:32:07 +0200 (CEST) Date: Wed, 27 Jul 2005 23:32:07 +0200 From: Juergen Schoenwaelder To: "Nelson, David" , Dave Harrington Subject: Re: [Isms] securityName Message-ID: <20050727213207.GA3262@boskop.local> Mail-Followup-To: "Nelson, David" , Dave Harrington , isms@ietf.org References: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103247F@MAANDMBX2.ets.enterasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103247F@MAANDMBX2.ets.enterasys.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Wed, Jul 27, 2005 at 02:31:45PM -0400, Nelson, David wrote: > Here, I beg to disagree. My vision of authorization is that access > control levels or policies are assigned to individuals based on their > role within the organization. While everyone in a particular > organization may authenticate via the same method, they may have > differing roles which require a different access control policy to be > applied. [...] > Retrieving the actual VACM table entries is not something that ISMS > needs to solve, IMHO. As you say, these tend to be relatively static, > based on pre-defined roles, such as Help Desk Support vs. Network > Administrator. I do think that the *binding* of the securityName to > whatever "name" might be used to index locally stored access control > rules should be provided as part of the authentication method. To implement what you are asking for without changing the current SNMP architecture, one could probably map, within the security model, the authenticated user identities to security names using an N:1 mapping function. The VACM security name to group mapping would then likely be a static 1:1 mapping. In other words, the users "joe" and "fred" would be mapped to the security name "helpdesk" within the security model while the VACM security name to group mapping would most likely map 1:1 the "helpdesk" security name to the "helpdesk" VACM group. Note that with USM, we currently have the N:1 mapping in VACM and the 1:1 mapping within USM. The approach sketched above would use the VACM N:1 mapping effectivly as a 1:1 mapping and move the real mapping into the security model. The community-based security model (RFC 2576) actually supports N:1 mappings of community strings to security names. The intended usage, as I recall, was to map community strings of the form "joe@bridge1" and "joe@bridge2" to the security name "joe" and the two contexts "bridge1" and "bridge2", but there is nothing which prevents you from mapping the community strings "joe" and "fred" to the security name "helpdesk" as far as I can tell. The reverse mapping for outgoing notifications, where the architecture just gives you a security name, is simply solved by using the first matching user identity. >From an architectural point of view, I don't really see a problem to achieve an N:1 mapping of users to roles within a security model - I believe RFC 2576 already sets a precedence (even though the community security model has probably not been used in this way so far). Am I missing something? Dave Harrington, what do you think? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 27 17:54:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxtqz-0007ZM-UL; Wed, 27 Jul 2005 17:54:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxtqw-0007ZE-Gm for isms@megatron.ietf.org; Wed, 27 Jul 2005 17:54:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05856 for ; Wed, 27 Jul 2005 17:54:11 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxuMG-0004eO-FF for isms@ietf.org; Wed, 27 Jul 2005 18:26:37 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 27 Jul 2005 14:54:03 -0700 X-IronPort-AV: i="3.95,146,1120460400"; d="scan'208"; a="201007797:sNHT27429170" Received: from kaushik-w2k03.cisco.com (dhcp-171-69-126-246.cisco.com [171.69.126.246]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6RLs2JM021915; Wed, 27 Jul 2005 14:54:02 -0700 (PDT) Message-Id: <6.2.0.14.0.20050727144826.0384b940@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 27 Jul 2005 14:54:02 -0700 To: "Nelson, David" From: Kaushik Narayan Subject: RE: [Isms] securityName In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103247F@MAANDMBX2.ets.ent erasys.com> References: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103247F@MAANDMBX2.ets.enterasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, Retrieving the actual VACM table entries is not something that ISMS >needs to solve, IMHO. As you say, these tend to be relatively static, >based on pre-defined roles, such as Help Desk Support vs. Network >Administrator. I do think that the *binding* of the securityName to >whatever "name" might be used to index locally stored access control >rules should be provided as part of the authentication method. I am not sure that we want to use "roles" for the binding since that is embedded within the access control system and the authorization model being employed. The user group on the other hand is probably more appropriate binding. regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 27 18:35:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxuUr-0002gj-5Q; Wed, 27 Jul 2005 18:35:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxuUq-0002ge-9J for isms@megatron.ietf.org; Wed, 27 Jul 2005 18:35:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10514 for ; Wed, 27 Jul 2005 18:35:24 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxv0B-0005dA-GY for isms@ietf.org; Wed, 27 Jul 2005 19:07:51 -0400 Received: from [10.0.1.3] (unknown [83.145.64.146]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 981931BAC99; Thu, 28 Jul 2005 00:35:18 +0200 (CEST) Date: Wed, 27 Jul 2005 17:01:18 +0200 From: Juergen Quittek To: j.schoenwaelder@iu-bremen.de, David B Harrington Subject: Re: [Isms] draft agenda for Paris Message-ID: <1903FE73097EB5DBEC1513F8@753F3B888A9969457862729D> In-Reply-To: <20050723063234.GB21724@boskop.local> References: <62335A94F69AF6FC5BA2CEA8@[10.1.1.171]> <200507222331.TAA11356@ietf.org> <20050723063234.GB21724@boskop.local> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.6 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I am fine with dropping the TLSM presentation, but I would like to see at least a short presentation of BTSM. Kaushik, will you or one of your co-authors be prepared for a short overview and of the key properties of this solution? Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 7/23/2005 8:32 AM +0200 Juergen Schoenwaelder wrote: > On Fri, Jul 22, 2005 at 07:31:28PM -0400, David B Harrington wrote: > >> I will not be in Paris. >> >> TLSM/TMSM has been presented at earlier meetings. I'm not sure it has >> changed that much. > > I will be in Paris at the ISMS meeting. However, I agree with David that > we should not waste valuable time on too many presentations. Instead, > I believe it would be much more valuable if we can work through a list > of well phrased open questions and ideally such a list would be created > on the mailing list well in advance of the face to face meeting so that > one can make effective use of the face to face time. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 27 19:48:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxvd2-0006vj-CZ; Wed, 27 Jul 2005 19:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxvd0-0006ve-By for isms@megatron.ietf.org; Wed, 27 Jul 2005 19:47:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18110 for ; Wed, 27 Jul 2005 19:47:54 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxw8K-0007qA-Es for isms@ietf.org; Wed, 27 Jul 2005 20:20:22 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 27 Jul 2005 16:47:47 -0700 X-IronPort-AV: i="3.95,147,1120460400"; d="scan'208"; a="651448746:sNHT30477464" Received: from kaushik-w2k03.cisco.com (dhcp-171-69-126-246.cisco.com [171.69.126.246]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6RNljJM000821; Wed, 27 Jul 2005 16:47:46 -0700 (PDT) Message-Id: <6.2.0.14.0.20050727164633.038c54c0@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 27 Jul 2005 16:47:45 -0700 To: Juergen Quittek From: Kaushik Narayan Subject: Re: [Isms] draft agenda for Paris In-Reply-To: <1903FE73097EB5DBEC1513F8@753F3B888A9969457862729D> References: <62335A94F69AF6FC5BA2CEA8@[10.1.1.171]> <200507222331.TAA11356@ietf.org> <20050723063234.GB21724@boskop.local> <1903FE73097EB5DBEC1513F8@753F3B888A9969457862729D> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Juergen, Eliot will present the draft at the ISMS meeting. regards, kaushik! At 08:01 AM 7/27/2005, Juergen Quittek wrote: >I am fine with dropping the TLSM presentation, but I would like to see >at least a short presentation of BTSM. > >Kaushik, will you or one of your co-authors be prepared for a short >overview and of the key properties of this solution? > >Thanks, > > Juergen >-- >Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 >NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de > > >--On 7/23/2005 8:32 AM +0200 Juergen Schoenwaelder wrote: > >>On Fri, Jul 22, 2005 at 07:31:28PM -0400, David B Harrington wrote: >> >>>I will not be in Paris. >>> >>>TLSM/TMSM has been presented at earlier meetings. I'm not sure it has >>>changed that much. >> >>I will be in Paris at the ISMS meeting. However, I agree with David that >>we should not waste valuable time on too many presentations. Instead, >>I believe it would be much more valuable if we can work through a list >>of well phrased open questions and ideally such a list would be created >>on the mailing list well in advance of the face to face meeting so that >>one can make effective use of the face to face time. >> >>/js >> >>-- >>Juergen Schoenwaelder International University Bremen >> P.O. Box 750 561, 28725 Bremen, Germany > > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 28 02:51:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy2FD-0003CA-3T; Thu, 28 Jul 2005 02:51:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy2FB-0003C2-9z for isms@megatron.ietf.org; Thu, 28 Jul 2005 02:51:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00316 for ; Thu, 28 Jul 2005 02:51:47 -0400 (EDT) Message-Id: <200507280651.CAA00316@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy2kY-0001Db-PT for isms@ietf.org; Thu, 28 Jul 2005 03:24:17 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005072806513601400hh25ae>; Thu, 28 Jul 2005 06:51:36 +0000 From: "David B Harrington" To: , "'Nelson, David'" , "'Dave Harrington'" Subject: RE: [Isms] securityName Date: Thu, 28 Jul 2005 02:51:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050727213207.GA3262@boskop.local> thread-index: AcWS9DbcPO8TXAVITwW4LMWnCUs8wQAP2syg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Juergen, -- requirements for a hack -- What you suggest is equivalent to passing the groupname via the securityName parameter. As you point out, for an outgoing request (e.g. notifications, there needs to be a way to convert from group in the securityName to a model-specific identity (e.g. user). This is true not only for notifications but also for requests. You suggest selecting the first match. Ultimately, this means all members of a group would use the same identity. I'm not sure how authentication would work for a TMSM approach, if the SSH user used for authentication is in fact a different user, especially if a CHAP authentication is used to establish a session. For this reason, the securityName really needs to identify the principal, not just a group mapping. It might be ok to pass both the principal and group(s) in the securityName. However, if we modify the semantics of securityName, then all RFC341x references to securityName will subsequently be wrong. We could add a groupName(s) parameter to the ASIs, or use global variables in the form of a user-to-group mapping MIB that can be accessed by both authentication and access control subsystems. Shared MIB modules proved problematic in SNMPv2, but if we standardize it and make the objects definitive such that different security models and different access control models cannot modify/overload the semantics of the objects in the table, we should be able to avoid the side-effects problem of SNMPv2. I suggest that the cleanest way to do this is to develop a separate MIB module that mirrors the vacmSecurityToGroupTable fields, and that may be used by future security models to provide the user-to-group mapping, and can be used by future access control models to get group information from those securityModels that support the new MIB. We can add an appendix that contains directions for coexistence with VACM that suggests simply copying the rows from the new MIB into the vacmSecurityToGroupTable, and ensures fate-sharing between the tables. Or we could develop an updated VACM that simply uses the new security-model-and-access-control-model-independent table instead of the vacmSecurityToGroupTable. Using a new MIB module allows us to support non-security-model configuration of the table (e.g. using SNMP or CLI scripting, or a dynamic mechanism to supplement an authentication mechanism that doesn't do authorizations) if there are circumstances that warrant such an approach (such as a requirement for no dependencies on external security infrastructure), yet allows new security models to populate the MIB module dynamically. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Wednesday, July 27, 2005 5:32 PM > To: Nelson, David; Dave Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] securityName > > On Wed, Jul 27, 2005 at 02:31:45PM -0400, Nelson, David wrote: > > > Here, I beg to disagree. My vision of authorization is that access > > control levels or policies are assigned to individuals > based on their > > role within the organization. While everyone in a particular > > organization may authenticate via the same method, they may have > > differing roles which require a different access control > policy to be > > applied. > > [...] > > > Retrieving the actual VACM table entries is not something that ISMS > > needs to solve, IMHO. As you say, these tend to be > relatively static, > > based on pre-defined roles, such as Help Desk Support vs. Network > > Administrator. I do think that the *binding* of the securityName to > > whatever "name" might be used to index locally stored access control > > rules should be provided as part of the authentication method. > > To implement what you are asking for without changing the current SNMP > architecture, one could probably map, within the security model, the > authenticated user identities to security names using an N:1 mapping > function. The VACM security name to group mapping would then likely be > a static 1:1 mapping. In other words, the users "joe" and "fred" would > be mapped to the security name "helpdesk" within the security model > while the VACM security name to group mapping would most likely map > 1:1 the "helpdesk" security name to the "helpdesk" VACM group. > > Note that with USM, we currently have the N:1 mapping in VACM and the > 1:1 mapping within USM. The approach sketched above would use the VACM > N:1 mapping effectivly as a 1:1 mapping and move the real mapping into > the security model. > > The community-based security model (RFC 2576) actually supports N:1 > mappings of community strings to security names. The intended usage, > as I recall, was to map community strings of the form "joe@bridge1" > and "joe@bridge2" to the security name "joe" and the two contexts > "bridge1" and "bridge2", but there is nothing which prevents you from > mapping the community strings "joe" and "fred" to the security name > "helpdesk" as far as I can tell. The reverse mapping for outgoing > notifications, where the architecture just gives you a security name, > is simply solved by using the first matching user identity. > > >From an architectural point of view, I don't really see a problem to > achieve an N:1 mapping of users to roles within a security model - I > believe RFC 2576 already sets a precedence (even though the community > security model has probably not been used in this way so far). > > Am I missing something? Dave Harrington, what do you think? > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 28 04:08:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy3Rk-0000IW-Of; Thu, 28 Jul 2005 04:08:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy3Rj-0000IQ-SK for isms@megatron.ietf.org; Thu, 28 Jul 2005 04:08:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04583 for ; Thu, 28 Jul 2005 04:08:49 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy3x7-0003bN-SC for isms@ietf.org; Thu, 28 Jul 2005 04:41:20 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 1524439936; Thu, 28 Jul 2005 10:08:33 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 23046-09; Thu, 28 Jul 2005 10:08:32 +0200 (CEST) Received: from boskop.local (unknown [10.71.237.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 1B55339221; Thu, 28 Jul 2005 10:08:32 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 9CEEE398688; Thu, 28 Jul 2005 09:50:07 +0200 (CEST) Date: Thu, 28 Jul 2005 09:50:07 +0200 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Isms] securityName Message-ID: <20050728075007.GA731@boskop.local> Mail-Followup-To: David B Harrington , "'Nelson, David'" , 'Dave Harrington' , isms@ietf.org References: <20050727213207.GA3262@boskop.local> <20050728065138.A5745D5EE@hermes.iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050728065138.A5745D5EE@hermes.iu-bremen.de> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: isms@ietf.org, 'Dave Harrington' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Thu, Jul 28, 2005 at 02:51:28AM -0400, David B Harrington wrote: > -- requirements for a hack -- > > What you suggest is equivalent to passing the groupname via the > securityName parameter. > As you point out, for an outgoing request (e.g. notifications, there > needs to be a way to convert from group in the securityName to a > model-specific identity (e.g. user). This is true not only for > notifications but also for requests. You suggest selecting the first > match. Ultimately, this means all members of a group would use the > same identity. I did not say that selecting the first one is the solution - I just mentioned that this is what the communiy-based security model does. If the user identity to security name mapping resides on an AAA server, then there might be other mappings that are more suitable. But yes, reversing an N:1 mapping has its issues. > I'm not sure how authentication would work for a TMSM approach, if the > SSH user used for authentication is in fact a different user, > especially if a CHAP authentication is used to establish a session. > For this reason, the securityName really needs to identify the > principal, not just a group mapping. Not sure I understand your concerns here. You authenticate a user and an AAA server provides a user to security name mapping. > It might be ok to pass both the principal and group(s) in the > securityName. However, if we modify the semantics of securityName, > then all RFC341x references to securityName will subsequently be > wrong. Why? Does RFC 341x say somewhere that the security name must directly identify a principal? > We could add a groupName(s) parameter to the ASIs, or use global > variables in the form of a user-to-group mapping MIB that can be > accessed by both authentication and access control subsystems. Shared > MIB modules proved problematic in SNMPv2, but if we standardize it and > make the objects definitive such that different security models and > different access control models cannot modify/overload the semantics > of the objects in the table, we should be able to avoid the > side-effects problem of SNMPv2. But both options are in fact changing the architectural interfaces. > I suggest that the cleanest way to do this is to develop a separate > MIB module that mirrors the vacmSecurityToGroupTable fields, and that > may be used by future security models to provide the user-to-group > mapping, and can be used by future access control models to get group > information from those securityModels that support the new MIB. > > We can add an appendix that contains directions for coexistence with > VACM that suggests simply copying the rows from the new MIB into the > vacmSecurityToGroupTable, and ensures fate-sharing between the tables. > Or we could develop an updated VACM that simply uses the new > security-model-and-access-control-model-independent table instead of > the vacmSecurityToGroupTable. > > Using a new MIB module allows us to support non-security-model > configuration of the table (e.g. using SNMP or CLI scripting, or a > dynamic mechanism to supplement an authentication mechanism that > doesn't do authorizations) if there are circumstances that warrant > such an approach (such as a requirement for no dependencies on > external security infrastructure), yet allows new security models to > populate the MIB module dynamically. My understanding is that we have the desired N:1 mapping table in VACM and the only concern that I heard hear on this list is that people do not want to touch this table when they add/remove users and they prefer that this mapping actually comes from say an AAA server. How does introducing another table solve that problem? I see these options: a) provide a mechanism to retrieve (at least parts of a) VACM configuration from an AAA server (not in our charter) b) do a N:1 mapping from user identities into security names in the ISMS security model (rather than doing a 1:1 mapping like USM) c) generally change the SNMP architecture providing new or extended ASIs to actually make this mapping something between the security model and the access control model (not in our charter) There are now technical pros and cons for all these options and there are process (charter) issues to consider. There was also the other option (not sure it really counts as an option): d) provide a wildcard mapping extension to VACM which can be exploited to map all security name with the same security level and security model together into a vacm group (works only on simple setups where you basically do not distinguish between different MIB views for authenticated users - but perhaps this is a low hanging fruit that covers most existing VACM configurations anyway) Any other options to consider which I forgot to list? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 28 10:56:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy9ns-0003mk-Cq; Thu, 28 Jul 2005 10:56:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy9nr-0003mf-0x for isms@megatron.ietf.org; Thu, 28 Jul 2005 10:56:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03400 for ; Thu, 28 Jul 2005 10:56:04 -0400 (EDT) Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyAJK-00083v-R1 for isms@ietf.org; Thu, 28 Jul 2005 11:28:39 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) 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 j6SEtpx7010633 for ; Thu, 28 Jul 2005 14:55:51 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 j6SEtphJ027364 for ; Thu, 28 Jul 2005 14:55:51 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 M2005072807555012006 for ; Thu, 28 Jul 2005 07:55:50 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 07:55:50 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 07:55:50 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 10:55:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] securityName Date: Thu, 28 Jul 2005 10:52:33 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929018EE444@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] securityName Thread-Index: AcWTS9LVWtoXiYB8Q6mzRD10MzNsoQANAdDQ From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 28 Jul 2005 14:55:49.0520 (UTC) FILETIME=[71446100:01C59384] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >> I'm not sure how authentication would work for a TMSM approach, if the >> SSH user used for authentication is in fact a different user, >> especially if a CHAP authentication is used to establish a session. >> For this reason, the securityName really needs to identify the >> principal, not just a group mapping.=20 > > Not sure I understand your concerns here. You authenticate a user and > an AAA server provides a user to security name mapping. The point is that conceptually and traditionally Security Model did not determine such mapping by itself, and limited its scope of knowledge to the principal it authenticated. Assumption was - somebody outside of SNMP (statically ?) defined/configured that mapping. What ISMS is actually doing is a meta-framework, because the "principal" of per-message security becomes "session ID". That "extra piece of functionality" can (and IMHO should) do both establish the "session ID" (or "session principal") based on the "high-level" principal who authenticates the initial exchange, and setting up access control for this session. It seems to me that the issue is not "how to bolt TLS (or SSH) onto SNMP so that users somehow authenticate without creating an extra database", but "how to accomodate architecturally addition of sessions and ACM mappings". >> It might be ok to pass both the principal and group(s) in the >> securityName. However, if we modify the semantics of securityName, >> then all RFC341x references to securityName will subsequently be >> wrong. > > Why? Does RFC 341x say somewhere that the security name must directly > identify a principal? securityName identifies a principal, and if one cannot unambiguously map back from securityName to an authenticated principal, the effect is of sharing userID's - a practice reasonable people frown upon. > My understanding is that we have the desired N:1 mapping table in VACM > and the only concern that I heard hear on this list is that people do > not want to touch this table when they add/remove users and they > prefer that this mapping actually comes from say an AAA server. How > does introducing another table solve that problem? Jurgen, I'm with you here. > I see these options: >=20 > a) provide a mechanism to retrieve (at least parts of a) VACM configuration > from an AAA server (not in our charter) Workable - assuming that *Security* model is not chartered with it. > b) do a N:1 mapping from user identities into security names in the > ISMS security model (rather than doing a 1:1 mapping like USM) First, this is ugly as a mule. Second - it breaks identification for cases when it matters. Right now only audit and VACM care who it is that authenticated the request. In general, it is not necessarily so. A Security Model should not authenticate a group, and It should be clear outside of the given Security Model what principal it dealt with. Grouping is ACM's job. > c) generally change the SNMP architecture providing new or extended > ASIs to actually make this mapping something between the security > model and the access control model (not in our charter) I'd prefer to see an extra module that does it. So I am for your option (c). There are now technical pros and cons for all these options and there are process (charter) issues to consider. There was also the other option (not sure it really counts as an option): > Any other options to consider which I forgot to list? Those above are enough, methinks. :-) _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 28 11:45:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyAZL-00016n-6D; Thu, 28 Jul 2005 11:45:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyAZJ-00015V-FU for isms@megatron.ietf.org; Thu, 28 Jul 2005 11:45:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06582 for ; Thu, 28 Jul 2005 11:45:06 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyB4i-0000ym-Km for isms@ietf.org; Thu, 28 Jul 2005 12:17:42 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j6SFj2ZC005955 for ; Thu, 28 Jul 2005 11:45:02 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 28 Jul 2005 11:45:02 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 28 Jul 2005 11:45:02 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 28 Jul 2005 11:45:02 -0400 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] securityName Date: Thu, 28 Jul 2005 11:45:01 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032485@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] securityName Thread-Index: AcWS9BELBTW2kjDVRQaKhgdxmRfBUwAlCmyg From: "Nelson, David" To: , "Dave Harrington" X-OriginalArrivalTime: 28 Jul 2005 15:45:02.0335 (UTC) FILETIME=[514830F0:01C5938B] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:92.7141 M:95.2280 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > To implement what you are asking for without changing the current SNMP > architecture, one could probably map, within the security model, the > authenticated user identities to security names using an N:1 mapping > function. The VACM security name to group mapping would then likely be > a static 1:1 mapping. In other words, the users "joe" and "fred" would > be mapped to the security name "helpdesk" within the security model > while the VACM security name to group mapping would most likely map > 1:1 the "helpdesk" security name to the "helpdesk" VACM group. Why wouldn't it be more straightforward to map authenticated user identities to securityNames on a 1:1 basis? My previous use of the term of "roles" meant organizational title, job description, and function (i.e. labels in the Human Resources Department domain). The generally accepted IT Department practice is to associate roles with authorization credentials, such as group membership or access rights. It is my opinion that the provisioning of access rights on the managed entity (by means of VACM, or whatever) need to be bound to the provisioning of access rights in the centralized AAA infrastructure. It would therefore make more sense to me to have a securityGroup name that is provided by the SNMP authentication module, and that comes from the AAA server. Attempting to centralize the authentication of identity, and the management of keys in a centralized fashion, but leaving the binding of access rights to a non-centralized mapping, is very problematic, IMHO. I don't think it is reasonable to request that users of ISMS protocols deploy a separate AAA infrastructure for network administration purposes. Most customers will want to use the infrastructure that they already have, and part of that infrastructure is access rights information. The fact that my user account may authenticate via AAA and provide authorization for remote VPN access to my company's network does not mean that my same account should authorize me to access the various managed entities in that network via SNMNP/ISMS. I guess the point is that *authorization* matters, and it exists today as part of the AAA infrastructure that we are attempting to re-use. > Note that with USM, we currently have the N:1 mapping in VACM and the > 1:1 mapping within USM. The approach sketched above would use the VACM > N:1 mapping effectivly as a 1:1 mapping and move the real mapping into > the security model. I agree. > From an architectural point of view, I don't really see a problem to > achieve an N:1 mapping of users to roles within a security model - I > believe RFC 2576 already sets a precedence (even though the community > security model has probably not been used in this way so far). I think the N:1 mapping of users to roles (as I use the word) occurs in the centralized AAA server. I would call the mapping that occurs in the security model a 1:1 mapping of organizational role to SNMP access control rule-set. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 28 13:46:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCT4-000649-Kz; Thu, 28 Jul 2005 13:46:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCT3-00062K-2s for isms@megatron.ietf.org; Thu, 28 Jul 2005 13:46:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15799 for ; Thu, 28 Jul 2005 13:46:45 -0400 (EDT) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyCyY-0004uS-7u for isms@ietf.org; Thu, 28 Jul 2005 14:19:22 -0400 Received: from pc6 (1Cust119.tnt105.lnd4.gbr.da.uu.net [213.116.58.119]) by ranger.systems.pipex.net (Postfix) with SMTP id 23013E0001DD; Thu, 28 Jul 2005 18:46:25 +0100 (BST) Message-ID: <04ae01c59393$c1525080$0601a8c0@pc6> From: "Tom Petch" To: "Kaushik Narayan" References: <3DEC199BD7489643817ECA151F7C5929018B79F0@pysmsx401.amr.corp.intel.com><200507271338.JAA28248@ietf.org> <6.2.0.14.0.20050717074153.03f49980@email.cisco.com> Subject: Re: [Isms] securityName Date: Thu, 28 Jul 2005 18:32:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org ----- Original Message ----- From: "Kaushik Narayan" To: Cc: Sent: Sunday, July 17, 2005 5:05 PM Subject: RE: [Isms] securityName > Hi David, > > Here is a list of external authentication mechanisms that are required to be > supported from the ISMS charter > > - Radius > - TACACS+ > - Kerberos > - LDAP > - Diameter > Well, no, that is not what I see or would ever want to see in the charter because I would regard it as impossible if it weren't that already. What I see the charter say is "The following security infrastructures will be considered by the working group as potential existing authentication infrastructures to make use of within the new security model. The solution will hopefully be able to be integrated with multiple of these user databases although it is expected that one will be mandatory. - Local accounts - SSH identities - Radius - TACACS+ - X.509 Certificates - Kerberos - LDAP - Diameter" So we have to support one, hopefully more than one, never all. And notice that the order of the list is that of the percentage currently using it as revealed in Wes' survey, so support for SSH counts for more than support for LDAP, by an order of magnitude. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 28 13:46:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCT6-00067l-Tt; Thu, 28 Jul 2005 13:46:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCT3-00062q-Kb for isms@megatron.ietf.org; Thu, 28 Jul 2005 13:46:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15803 for ; Thu, 28 Jul 2005 13:46:45 -0400 (EDT) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyCyY-0004ut-80 for isms@ietf.org; Thu, 28 Jul 2005 14:19:22 -0400 Received: from pc6 (1Cust119.tnt105.lnd4.gbr.da.uu.net [213.116.58.119]) by ranger.systems.pipex.net (Postfix) with SMTP id 8A22AE0002C8; Thu, 28 Jul 2005 18:46:27 +0100 (BST) Message-ID: <04af01c59393$c22afd40$0601a8c0@pc6> From: "Tom Petch" To: References: <20050727213207.GA3262@boskop.local><20050728065138.A5745D5EE@hermes.iu-bremen.de> <20050728075007.GA731@boskop.local> Subject: Re: [Isms] securityName via securityLevel Date: Thu, 28 Jul 2005 18:42:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen To clarify, when you say security level, I take it you mean 3.4.3. securityLevel - noAuthNoPriv - authNoPriv - authPriv As you say, it is just about feasible. I see current proprietary management systems with three levels, for general user, configuration change and system change (software, security, passwords) which maps ok (although a spare would be nice). But I seem to recall a post from Sharon saying seven would be needed. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "David B Harrington" Cc: ; "'Dave Harrington'" Sent: Thursday, July 28, 2005 9:50 AM Subject: Re: [Isms] securityName > On Thu, Jul 28, 2005 at 02:51:28AM -0400, David B Harrington wrote: > > > -- requirements for a hack -- > > > > What you suggest is equivalent to passing the groupname via the > > securityName parameter. > > As you point out, for an outgoing request (e.g. notifications, there > > needs to be a way to convert from group in the securityName to a > > model-specific identity (e.g. user). This is true not only for > > notifications but also for requests. You suggest selecting the first > > match. Ultimately, this means all members of a group would use the > > same identity. > > I did not say that selecting the first one is the solution - I just > mentioned that this is what the communiy-based security model does. > If the user identity to security name mapping resides on an AAA > server, then there might be other mappings that are more suitable. > But yes, reversing an N:1 mapping has its issues. > > > I'm not sure how authentication would work for a TMSM approach, if the > > SSH user used for authentication is in fact a different user, > > especially if a CHAP authentication is used to establish a session. > > For this reason, the securityName really needs to identify the > > principal, not just a group mapping. > > Not sure I understand your concerns here. You authenticate a user and > an AAA server provides a user to security name mapping. > > > It might be ok to pass both the principal and group(s) in the > > securityName. However, if we modify the semantics of securityName, > > then all RFC341x references to securityName will subsequently be > > wrong. > > Why? Does RFC 341x say somewhere that the security name must directly > identify a principal? > > > We could add a groupName(s) parameter to the ASIs, or use global > > variables in the form of a user-to-group mapping MIB that can be > > accessed by both authentication and access control subsystems. Shared > > MIB modules proved problematic in SNMPv2, but if we standardize it and > > make the objects definitive such that different security models and > > different access control models cannot modify/overload the semantics > > of the objects in the table, we should be able to avoid the > > side-effects problem of SNMPv2. > > But both options are in fact changing the architectural interfaces. > > > I suggest that the cleanest way to do this is to develop a separate > > MIB module that mirrors the vacmSecurityToGroupTable fields, and that > > may be used by future security models to provide the user-to-group > > mapping, and can be used by future access control models to get group > > information from those securityModels that support the new MIB. > > > > We can add an appendix that contains directions for coexistence with > > VACM that suggests simply copying the rows from the new MIB into the > > vacmSecurityToGroupTable, and ensures fate-sharing between the tables. > > Or we could develop an updated VACM that simply uses the new > > security-model-and-access-control-model-independent table instead of > > the vacmSecurityToGroupTable. > > > > Using a new MIB module allows us to support non-security-model > > configuration of the table (e.g. using SNMP or CLI scripting, or a > > dynamic mechanism to supplement an authentication mechanism that > > doesn't do authorizations) if there are circumstances that warrant > > such an approach (such as a requirement for no dependencies on > > external security infrastructure), yet allows new security models to > > populate the MIB module dynamically. > > My understanding is that we have the desired N:1 mapping table in VACM > and the only concern that I heard hear on this list is that people do > not want to touch this table when they add/remove users and they > prefer that this mapping actually comes from say an AAA server. How > does introducing another table solve that problem? > > I see these options: > > a) provide a mechanism to retrieve (at least parts of a) VACM configuration > from an AAA server (not in our charter) > > b) do a N:1 mapping from user identities into security names in the > ISMS security model (rather than doing a 1:1 mapping like USM) > > c) generally change the SNMP architecture providing new or extended > ASIs to actually make this mapping something between the security > model and the access control model (not in our charter) > > There are now technical pros and cons for all these options and there > are process (charter) issues to consider. There was also the other > option (not sure it really counts as an option): > > d) provide a wildcard mapping extension to VACM which can be exploited > to map all security name with the same security level and security > model together into a vacm group (works only on simple setups where > you basically do not distinguish between different MIB views for > authenticated users - but perhaps this is a low hanging fruit that > covers most existing VACM configurations anyway) > > Any other options to consider which I forgot to list? > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 28 13:46:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCT7-00068K-6e; Thu, 28 Jul 2005 13:46:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCT3-00062p-KR for isms@megatron.ietf.org; Thu, 28 Jul 2005 13:46:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15801 for ; Thu, 28 Jul 2005 13:46:45 -0400 (EDT) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyCyY-0004uF-85 for isms@ietf.org; Thu, 28 Jul 2005 14:19:22 -0400 Received: from pc6 (1Cust119.tnt105.lnd4.gbr.da.uu.net [213.116.58.119]) by ranger.systems.pipex.net (Postfix) with SMTP id D5B20E0001D0; Thu, 28 Jul 2005 18:46:22 +0100 (BST) Message-ID: <04ad01c59393$c05e2c80$0601a8c0@pc6> From: "Tom Petch" To: "Sam Hartman" References: <20050722232427.7131818000081@grand.systems.pipex.net><002401c5902a$187d05c0$0601a8c0@pc6> Subject: Re: [Isms] securityName Date: Thu, 28 Jul 2005 18:19:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org ----- Original Message ----- From: "Sam Hartman" To: "Tom Petch" Cc: ; Sent: Tuesday, July 26, 2005 2:21 AM Subject: Re: [Isms] securityName > >>>>> "Tom" == Tom Petch writes: > > Tom> I was rather assuming that if ssh-userauth authenticated a > Tom> principal, then although that is a model dependent name to > Tom> isms, it would be the same principal identifier as is used in > Tom> other security systems in the organisation and would be the > Tom> same as the securityName. I don't see the merit in having a > Tom> separate principal identifier and securityName, given that > Tom> one of our aims is to integrate better with existing security > Tom> systems. > > I'm not at all sure this is true. In general, SASL and other > application protocols have found it useful to separate the identifier > authenticated by a security model from the identifier (authorization > ID for SASL) used to make authorization decisions. IN many cases > there is a simple mapping that can be overridden. Sam I've thought about this for 48 hours and still don't understand it:-( securityName in SNMPv3 is intended to identify a principal in a security-model independent manner and as Juergen pointed out, in USM that is likely to be the identity mapping with the userName. All I was saying was that that would be a good starting point for any security model. And in SNMPv3, the role of the security model is message level security, timeliness, encryption, authentication, not authorization. So I am not sure where your comment about identifier for authorization decisions comes from. I have said elsewhere that I see groups as a - the - key part of authorization so if you mean having an authenticated-principal-identifier mapping into one or more authorization-groups, then I agree. And as this thread has explored, the presence of that mapping in the 'agent' does create a configuration workload issue that I see as a bar to the deployment of SNMPv3. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 28 14:02:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyChx-0003Vo-RH; Thu, 28 Jul 2005 14:02:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyChw-0003UA-O3 for isms@megatron.ietf.org; Thu, 28 Jul 2005 14:02:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17229 for ; Thu, 28 Jul 2005 14:02:11 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyDDP-0005Pw-2U for isms@ietf.org; Thu, 28 Jul 2005 14:34:46 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 28 Jul 2005 11:01:59 -0700 X-IronPort-AV: i="3.95,150,1120460400"; d="scan'208"; a="326931921:sNHT27233916" Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6SI1vJM029621; Thu, 28 Jul 2005 11:01:58 -0700 (PDT) Message-Id: <6.2.0.14.0.20050728105946.040004b8@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 28 Jul 2005 11:01:57 -0700 To: "Tom Petch" From: Kaushik Narayan Subject: Re: [Isms] securityName In-Reply-To: <04ae01c59393$c1525080$0601a8c0@pc6> References: <3DEC199BD7489643817ECA151F7C5929018B79F0@pysmsx401.amr.corp.intel.com> <200507271338.JAA28248@ietf.org> <6.2.0.14.0.20050717074153.03f49980@email.cisco.com> <04ae01c59393$c1525080$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Sure. I did not intend to mean that all of these authentication mechanisms were mandatory to support for ISMS. I was just trying to explain that most of these authentication protocols/mechanisms have means to communicate the user group names to SNMP engines. At 09:32 AM 7/28/2005, Tom Petch wrote: >----- Original Message ----- >From: "Kaushik Narayan" >To: >Cc: >Sent: Sunday, July 17, 2005 5:05 PM >Subject: RE: [Isms] securityName > > > Hi David, > > > > Here is a list of external authentication mechanisms that are required > to be > > supported from the ISMS charter > > > > - Radius > > - TACACS+ > > - Kerberos > > - LDAP > > - Diameter > > > >Well, no, that is not what I see or would ever want to see in the charter >because I would regard it as impossible if it weren't that already. What >I see >the charter say is > >"The following security infrastructures will be considered by the working >group >as potential existing >authentication infrastructures to make use of within the new security >model. The >solution will hopefully be able to be integrated with multiple of these user >databases although it is expected that one will be mandatory. > >- Local accounts >- SSH identities >- Radius >- TACACS+ >- X.509 Certificates >- Kerberos >- LDAP >- Diameter" > >So we have to support one, hopefully more than one, never all. And notice >that >the order of the list is that of the percentage currently using it as revealed >in Wes' survey, so support for SSH counts for more than support for LDAP, >by an >order of magnitude. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 28 14:06:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCmM-00051U-ME; Thu, 28 Jul 2005 14:06:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCmL-000503-Df for isms@megatron.ietf.org; Thu, 28 Jul 2005 14:06:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17635 for ; Thu, 28 Jul 2005 14:06:43 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyDHq-0005Ys-2G for isms@ietf.org; Thu, 28 Jul 2005 14:39:19 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 28 Jul 2005 11:06:35 -0700 X-IronPort-AV: i="3.95,150,1120460400"; d="scan'208"; a="326934503:sNHT51451166" Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6SI6VIt025450; Thu, 28 Jul 2005 11:06:32 -0700 (PDT) Message-Id: <6.2.0.14.0.20050728110407.04000000@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 28 Jul 2005 11:06:34 -0700 To: j.schoenwaelder@iu-bremen.de From: Kaushik Narayan Subject: Re: [Isms] securityName In-Reply-To: <20050727213207.GA3262@boskop.local> References: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103247F@MAANDMBX2.ets.enterasys.com> <20050727213207.GA3262@boskop.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: isms@ietf.org, Dave Harrington X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Juergen, To implement what you are asking for without changing the current SNMP >architecture, one could probably map, within the security model, the >authenticated user identities to security names using an N:1 mapping >function. The VACM security name to group mapping would then likely be >a static 1:1 mapping. In other words, the users "joe" and "fred" would >be mapped to the security name "helpdesk" within the security model >while the VACM security name to group mapping would most likely map >1:1 the "helpdesk" security name to the "helpdesk" VACM group. I think this approach would be counter productive since we overload the notion of a securityName to identify not the client principal but his "role". I think it would be a lot cleaner if we were to allow group mapping to happen external to the access control system. regards, kaushk! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 28 14:20:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCzT-0000ve-B1; Thu, 28 Jul 2005 14:20:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCzR-0000vZ-62 for isms@megatron.ietf.org; Thu, 28 Jul 2005 14:20:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18412 for ; Thu, 28 Jul 2005 14:20:15 -0400 (EDT) Received: from i86e7.i.pppool.de ([85.73.134.231] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyDUv-0005x5-Sd for isms@ietf.org; Thu, 28 Jul 2005 14:52:51 -0400 Received: by boskop.local (Postfix, from userid 501) id 186E0398D45; Thu, 28 Jul 2005 20:19:56 +0200 (CEST) Date: Thu, 28 Jul 2005 20:19:56 +0200 From: Juergen Schoenwaelder To: Tom Petch Subject: Re: [Isms] securityName via securityLevel Message-ID: <20050728181956.GA648@boskop.local> Mail-Followup-To: Tom Petch , isms@ietf.org References: <20050728075007.GA731@boskop.local> <04af01c59393$c22afd40$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04af01c59393$c22afd40$0601a8c0@pc6> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Thu, Jul 28, 2005 at 06:42:57PM +0200, Tom Petch wrote: > Juergen > > To clarify, when you say security level, I take it you mean > > 3.4.3. securityLevel > - noAuthNoPriv > - authNoPriv > - authPriv Yes, I mean security level as defined in the SNMPv3 architecture. > As you say, it is just about feasible. I see current proprietary > management systems with three levels, for general user, > configuration change and system change (software, security, > passwords) which maps ok (although a spare would be nice). But I > seem to recall a post from Sharon saying seven would be needed. And here is a misunderstanding I think. The security level describes the amount of protection on the wire. You seem to assume that the security level somehow implies what someone is allowed to do, which would be an authorization level, something that does not exist in SNMPv3 since this is actually handled by the access control model. What you descibe above sounds like a typical CLI course grain access control model where the device implementor is basically in charge to ensure that access control is properly enforced for the N defined authorization levels (usually hard-wired for the different objects). Since we are not chartered to discuss the merits of VACM nor not VACM I better suppress any comments on the merits and pitfalls of these two different approaches. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 29 04:26:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyQCJ-0001bf-BV; Fri, 29 Jul 2005 04:26:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyQCH-0001bR-8L for isms@megatron.ietf.org; Fri, 29 Jul 2005 04:26:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20472 for ; Fri, 29 Jul 2005 04:26:21 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyQhs-0000bN-Pt for isms@ietf.org; Fri, 29 Jul 2005 04:59:05 -0400 Received: from pc6 (1Cust105.tnt30.lnd3.gbr.da.uu.net [62.188.122.105]) by blaster.systems.pipex.net (Postfix) with SMTP id 7F036E000125; Fri, 29 Jul 2005 09:26:04 +0100 (BST) Message-ID: <000d01c5940e$a46bac20$0601a8c0@pc6> From: "Tom Petch" To: References: <20050728075007.GA731@boskop.local> <04af01c59393$c22afd40$0601a8c0@pc6> <20050728181956.GA648@boskop.local> Subject: Re: [Isms] securityName via securityLevel Date: Fri, 29 Jul 2005 09:23:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen I am confused. Rereading my previous e-mail, I do mean what I said. I believe I understand the difference between security level on the wire and authorisation/access control and use them in the same sense as you.. I have read and still read your option d) as proposing that securityLevel on the wire should be used to determine the group name and hence the access control in vacm. So consider that option e) and please give me an alternative explanation for what you described as "d) provide a wildcard mapping extension to VACM which can be exploited to map all security name with the same security level and security model together into a vacm group (works only on simple setups where you basically do not distinguish between different MIB views for authenticated users - but perhaps this is a low hanging fruit that covers most existing VACM configurations anyway)" which I read as a proposal to map (one of three) security level into a (one of three) vacm group but which you say does not:-( Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Tom Petch" Cc: Sent: Thursday, July 28, 2005 8:19 PM Subject: Re: [Isms] securityName via securityLevel > On Thu, Jul 28, 2005 at 06:42:57PM +0200, Tom Petch wrote: > > Juergen > > > > To clarify, when you say security level, I take it you mean > > > > 3.4.3. securityLevel > > - noAuthNoPriv > > - authNoPriv > > - authPriv > > Yes, I mean security level as defined in the SNMPv3 architecture. > > > As you say, it is just about feasible. I see current proprietary > > management systems with three levels, for general user, > > configuration change and system change (software, security, > > passwords) which maps ok (although a spare would be nice). But I > > seem to recall a post from Sharon saying seven would be needed. > > And here is a misunderstanding I think. The security level describes > the amount of protection on the wire. You seem to assume that the > security level somehow implies what someone is allowed to do, which > would be an authorization level, something that does not exist in > SNMPv3 since this is actually handled by the access control model. > > What you descibe above sounds like a typical CLI course grain access > control model where the device implementor is basically in charge to > ensure that access control is properly enforced for the N defined > authorization levels (usually hard-wired for the different objects). > > Since we are not chartered to discuss the merits of VACM nor not > VACM I better suppress any comments on the merits and pitfalls of > these two different approaches. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 29 05:08:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyQqm-0004NA-FJ; Fri, 29 Jul 2005 05:08:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyQqk-0004N4-Gp for isms@megatron.ietf.org; Fri, 29 Jul 2005 05:08:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22576; Fri, 29 Jul 2005 05:08:11 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyRMK-0001l2-QU; Fri, 29 Jul 2005 05:40:56 -0400 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7FCF21523C; Fri, 29 Jul 2005 11:07:56 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jul 2005 11:07:56 +0200 Message-ID: <88F766D04E6AF3409B39E60D7D933EB20E8BC6@europa.office> Thread-Topic: Agenda for ISMS at IETF-63 in Paris Thread-Index: AcWUHQI51De5Iv1fTdu4R9z08bDfXw== From: "Juergen Quittek" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org Subject: [Isms] Agenda for ISMS at IETF-63 in Paris X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org =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 Integrated Security Model for SNMP WG (isms) IETF #63 Thursday August 4, 2005 : 1030-1230 =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 Chairs: Ken Hornstein Juergen Quittek AGENDA: 1) Agenda bashing, WG Status ( 5 min) 2) A BEEP Profile for SNMPv3 PDUs (20 min) - draft-kaushik-isms-btsm-01.txt 3) Selection of the ISMS transport protocol (70 min) 4) Charter discussion (optional) (20 min) 5) Wrap up ( 5 min) - action points, schedule for charter INTERNET DRAFTS: Transport Layer Security Model (TLSM) for the Simple Network Management Protocol version 3 (SNMPv3) http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-02.txt A BEEP Profile for SNMPv3 PDUs http://www.ietf.org/internet-drafts/draft-kaushik-isms-btsm-01.txt _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 29 06:55:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DySX1-0000Al-Kt; Fri, 29 Jul 2005 06:55:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DySX0-0000Aa-Md for isms@megatron.ietf.org; Fri, 29 Jul 2005 06:55:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28285 for ; Fri, 29 Jul 2005 06:55:54 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyT2e-0004l9-IR for isms@ietf.org; Fri, 29 Jul 2005 07:28:40 -0400 Received: from pc6 (1Cust79.tnt29.lnd3.gbr.da.uu.net [62.188.120.79]) by blaster.systems.pipex.net (Postfix) with SMTP id 44944E000069; Fri, 29 Jul 2005 11:55:39 +0100 (BST) Message-ID: <010101c59423$8a17a9e0$0601a8c0@pc6> From: "Tom Petch" To: "Sam Hartman" References: <200507151618.MAA22560@ietf.org> Subject: Re: [Isms] Comments on the BTSMS proposal Date: Fri, 29 Jul 2005 10:26:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org ----- Original Message ----- From: "Sam Hartman" To: Cc: Sent: Tuesday, July 26, 2005 8:57 PM Subject: Re: [Isms] Comments on the BTSMS proposal > >>>>> "David" == David B Harrington writes: > > David> 2) Make the transport security selection transparent, not > David> opaque. > > David> I don't feel comfortable having one BEEP transport mapping > David> that might use only TLS or might user TLS with SASL or some > David> other combination of underlying protocols. I think TLS and > David> SASL-over-TLS probably meet different security > David> requirements, so should be considered different BEEP > David> profiles, different SNMP transport mappings, and different > David> SNMP security models. SNMP-over-BEEP seems too opaque to be > David> useful for security purposes. > > I have not yet read the document but based on your comments I > disagree. The security provided by TLS, SASL and any combination will > depend on the specific mechanisms in use, ciphers used by those > mechanisms and possibly by properties of external authentication > infrastructures. > > If you try and expose this information to SNMP, you will complicate > the mapping significantly. In addition, you will probably find that > several deployments do not fit your mapping. > > I don't think there is a lot to be gained from treating for example > SASL+TLS differently from just TLS. > > I do think that exposing properties like whether there is integrity, > whether there is confidentiality and whether there is mutual > authentication is useful. > > I do believe that allowing implementations to expose additional > information for the purpose of making security policy decisions is > reasonable. > > I suspect based on some comments here that what I'm proposing may not > be entirely consistent with the SNMP architecture. Sam FYI What the SNMPv3 architecture exposes is the level of security on the wire as (RFC3411 3.4.3. p.29) securityLevel - without authentication and without privacy (noAuthNoPriv) - with authentication but without privacy (authNoPriv) - with authentication and with privacy (authPriv) Authentication applies to a message; the architecture does not specify what kind but, for me, implies one way only, of manager/client/command generator to agent/server/command responder. It is also referred to as a primary threat of Masquerade, of one principal as another. Privacy again applies to a message and is confidentiality. The architecture also refers to this as Disclosure and treats it as a secondary threat. Modification of information, integrity, is defined as a primary threat that a security model must guard against but is not exposed in the interfaces. As you say, it could be different, but that is what we currently have and which I have taken as a given in this work. Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jul 30 11:17:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyt5k-00005Q-2o; Sat, 30 Jul 2005 11:17:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyt5j-00005L-1l for isms@megatron.ietf.org; Sat, 30 Jul 2005 11:17:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15791 for ; Sat, 30 Jul 2005 11:17:33 -0400 (EDT) Received: from open-27-104.ietf63.ietf.org ([86.255.27.104] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dytbb-0006hd-LV for isms@ietf.org; Sat, 30 Jul 2005 11:50:32 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 798A8E0049; Sat, 30 Jul 2005 11:16:33 -0400 (EDT) To: "Tom Petch" Subject: Re: [Isms] Comments on the BTSMS proposal References: <200507151618.MAA22560@ietf.org> <010101c59423$8a17a9e0$0601a8c0@pc6> From: Sam Hartman Date: Sat, 30 Jul 2005 11:16:33 -0400 In-Reply-To: <010101c59423$8a17a9e0$0601a8c0@pc6> (Tom Petch's message of "Fri, 29 Jul 2005 10:26:48 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Tom" == Tom Petch writes: Tom> Sam Tom> FYI Tom> What the SNMPv3 architecture exposes is the level of security Tom> on the wire as (RFC3411 3.4.3. p.29) securityLevel - without Tom> authentication and without privacy (noAuthNoPriv) - with Tom> authentication but without privacy (authNoPriv) - with Tom> authentication and with privacy (authPriv) These seem like reasonable things for the encapsulation layer to communicate to the rest of SNMP. I anticipate no problem with doing this for Ssh, Beep, SASL, TLS or DTLS. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jul 30 12:20:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyu4P-0005HR-N1; Sat, 30 Jul 2005 12:20:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyu4N-0005HG-6D for isms@megatron.ietf.org; Sat, 30 Jul 2005 12:20:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18330 for ; Sat, 30 Jul 2005 12:20:12 -0400 (EDT) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyuaH-0000P4-2W for isms@ietf.org; Sat, 30 Jul 2005 12:53:13 -0400 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 5DA341705C; Sat, 30 Jul 2005 09:20:08 -0700 (PDT) To: Sam Hartman Subject: Re: [Isms] Comments on the BTSMS proposal References: <200507151618.MAA22560@ietf.org> <010101c59423$8a17a9e0$0601a8c0@pc6> From: Eric Rescorla Date: Sat, 30 Jul 2005 09:20:08 -0700 In-Reply-To: (Sam Hartman's message of "Sat, 30 Jul 2005 11:16:33 -0400") Message-ID: <86oe8kb70n.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: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Sam Hartman writes: >>>>>> "Tom" == Tom Petch writes: > > Tom> Sam > > Tom> FYI > > Tom> What the SNMPv3 architecture exposes is the level of security > Tom> on the wire as (RFC3411 3.4.3. p.29) securityLevel - without > Tom> authentication and without privacy (noAuthNoPriv) - with > Tom> authentication but without privacy (authNoPriv) - with > Tom> authentication and with privacy (authPriv) > > These seem like reasonable things for the encapsulation layer to > communicate to the rest of SNMP. > > > I anticipate no problem with doing this for Ssh, Beep, SASL, TLS or > DTLS. Agreed. Though it's worth noting that as far as I know all of these establish a single connection-level set of security parameters. This contrasts with the current USM, which lets you set per-message parameters. -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jul 31 00:58:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dz5th-0001XK-Ff; Sun, 31 Jul 2005 00:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dz5te-0001XF-Uw for isms@megatron.ietf.org; Sun, 31 Jul 2005 00:57:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14629 for ; Sun, 31 Jul 2005 00:57:56 -0400 (EDT) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dz6Pe-00075x-Ut for isms@ietf.org; Sun, 31 Jul 2005 01:31:03 -0400 Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id DC13A284CC for ; Sat, 30 Jul 2005 22:39:32 -0700 (PDT) To: isms@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Sat, 30 Jul 2005 21:57:42 -0700 From: Eric Rescorla Message-Id: <20050731053932.DC13A284CC@sierra.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Subject: [Isms] Comments on draft-schoenw-snmp-tlsm-02.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org S 5.1: It's important to distinguish channel properties from handshake properties. All TLS channels, even those set up with anonymous DH keys, provide message integrity for the channel. I'm not sure whether to call this auth or not, but... S 5.1.1: Why expose the master secret? Is there any need for it? S 5.2: I would move the discussion of requiring certs to the TLS section, since the issues are basically the same. I note you list SRP, which isn't really proceeding in TLS. However, there is a PSK mechanism that has been approved by the IESG. S 5.3: You should note here that with SASL you would need to use the channel security mode. Also, you should be citing RFC 2831 as welll here... S A.2: For SBSM, and for many TMSM models, securityName is specified during session setup, and associated with the session identifier. Is it possible for the request (and notification) originator to specify per message auth and encryption services, or are they are "fixed" by the transport/session model? In major channel security protocol I know of, these properties are fixed on a per-session basis. If a session is created as 'authPriv', then keys for encryption would still be negotiated once at the beginning of the session. But if a message is presented to the session with a security level of authNoPriv, then that message could simply be authenticated and not encrypted. Wouldn't that also have some security benefit, in that it reduces the encrypted data available to an attacker gathering packets to try and discover the encryption keys? Not really. In general, modern algorithms are not susceptible to this kind of attack. Some SNMP entities are resource-constrained. Adding sessions increases the need for resources, we shouldn't require two sessions when one can suffice. 2 bytes per session structure and a compare or two is much less of a resource burden than two separate sessions. It's not just about CPU power of the device but the percentage of CPU cycles that are spent on network management. There isn't much value in using encryption for a performance management system polling PEs for performance data on thousands of interfaces every ten minutes,it just adds significant overhead to processing of the packet. Using an encrypted TLS channel for everything may not work for use cases in performance management wherein we collect massive amounts of non sensitive data at periodic intervals. Each SNMP "session" would have to negotiate two separate protection channels (authPriv and authNoPriv) and for every packet the SNMP engine will use the appropriate channel based on the desired securityLevel. If the underlying transport layer security was configurable on a per-message basis, a TMSM could have a MIB module with configurable maxSecurityLevel and a minSecurityLevel objects to identify the range of possible levels, and not all messages sent via that session are of the same level. A session's maxSecurityLevel would identify the maximum security it could provide, and a session created with a minSecurityLevel of authPriv would reject an attempt to send an authNoPriv message. This performance issue is raised a lot, but I'm not something I'm much concerned with. Modern encryption algorithms are incredibly fast, even on cheap processors. Unless you have measurements indicating that this is a real problem, I don't think it's worth undertaking the very substantial effort of re-working one of these protocols. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jul 31 05:35:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzAE0-00011q-SA; Sun, 31 Jul 2005 05:35:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzADy-00011l-TP for isms@megatron.ietf.org; Sun, 31 Jul 2005 05:35:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13934 for ; Sun, 31 Jul 2005 05:35:12 -0400 (EDT) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzAk0-00033J-Su for isms@ietf.org; Sun, 31 Jul 2005 06:08:22 -0400 Received: from pc6 (1Cust230.tnt104.lnd4.gbr.da.uu.net [213.116.56.230]) by ranger.systems.pipex.net (Postfix) with SMTP id 07887E0001A2; Sun, 31 Jul 2005 10:34:52 +0100 (BST) Message-ID: <001001c595aa$94f52580$0601a8c0@pc6> From: "Tom Petch" To: "Juergen Quittek" References: <88F766D04E6AF3409B39E60D7D933EB20E8BC6@europa.office> Subject: Re: [Isms] Agenda for ISMS at IETF-63 in Paris Date: Sun, 31 Jul 2005 10:31:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen, Ken Just to state the obvious, in the light of the current objectives of isms, the 70 minute session on transport protocol selection is critical so I would urge you to ensure that the minutes capture the key technical points made and are available in a timely manner so that the discussion can continue from a common base. Tom Petch ----- Original Message ----- From: "Juergen Quittek" To: Cc: Sent: Friday, July 29, 2005 11:07 AM Subject: [Isms] Agenda for ISMS at IETF-63 in Paris ============================================= Integrated Security Model for SNMP WG (isms) IETF #63 Thursday August 4, 2005 : 1030-1230 ============================================ Chairs: Ken Hornstein Juergen Quittek AGENDA: 1) Agenda bashing, WG Status ( 5 min) 2) A BEEP Profile for SNMPv3 PDUs (20 min) - draft-kaushik-isms-btsm-01.txt 3) Selection of the ISMS transport protocol (70 min) 4) Charter discussion (optional) (20 min) 5) Wrap up ( 5 min) - action points, schedule for charter INTERNET DRAFTS: Transport Layer Security Model (TLSM) for the Simple Network Management Protocol version 3 (SNMPv3) http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-02.txt A BEEP Profile for SNMPv3 PDUs http://www.ietf.org/internet-drafts/draft-kaushik-isms-btsm-01.txt _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jul 31 16:18:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzKGE-00007Q-AP; Sun, 31 Jul 2005 16:18:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzKGC-00007F-Hg for isms@megatron.ietf.org; Sun, 31 Jul 2005 16:18:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16976 for ; Sun, 31 Jul 2005 16:18:10 -0400 (EDT) Received: from tui75-2-82-229-178-125.fbx.proxad.net ([82.229.178.125] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzKmK-0005r3-4E for isms@ietf.org; Sun, 31 Jul 2005 16:51:25 -0400 Received: by boskop.local (Postfix, from userid 501) id 1880039AD3E; Sun, 31 Jul 2005 18:04:52 +0200 (CEST) Date: Sun, 31 Jul 2005 18:04:52 +0200 From: Juergen Schoenwaelder To: Tom Petch Subject: Re: [Isms] securityName via securityLevel Message-ID: <20050731160452.GA2164@boskop.local> Mail-Followup-To: Tom Petch , isms@ietf.org References: <20050728075007.GA731@boskop.local> <04af01c59393$c22afd40$0601a8c0@pc6> <20050728181956.GA648@boskop.local> <000d01c5940e$a46bac20$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000d01c5940e$a46bac20$0601a8c0@pc6> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.7 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Fri, Jul 29, 2005 at 09:23:10AM +0200, Tom Petch wrote: > Juergen > > I am confused. > > Rereading my previous e-mail, I do mean what I said. I believe I > understand the difference between security level on the wire and > authorisation/access control and use them in the same sense as > you.. I have read and still read your option d) as proposing that > securityLevel on the wire should be used to determine the group > name and hence the access control in vacm. > > So consider that option e) and please give me an alternative explanation for > what you described as > > "d) provide a wildcard mapping extension to VACM which can be exploited > to map all security name with the same > security level and security model together > into a vacm group (works only on simple setups where > > you basically do not distinguish between different MIB views for > authenticated users - but perhaps this is a low hanging fruit that > covers most existing VACM configurations anyway)" > > which I read as a proposal to map (one of three) security level into a > (one of three) vacm group but which you say does not:-( Sorry, I did not see the context of your statement. So yes, d == e (and I am not sure this really is an option). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jul 31 17:39:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzLX7-0005sM-5s; Sun, 31 Jul 2005 17:39:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzLX5-0005sH-T1 for isms@megatron.ietf.org; Sun, 31 Jul 2005 17:39:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19593 for ; Sun, 31 Jul 2005 17:39:41 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzM3E-00015W-9S for isms@ietf.org; Sun, 31 Jul 2005 18:12:57 -0400 Received: from openconcorde-21-115.ietf63.ietf.org (openConcorde-21-115.ietf63.ietf.org [86.255.21.115]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 05E441BAC9E; Sun, 31 Jul 2005 23:39:24 +0200 (CEST) Date: Sun, 31 Jul 2005 23:39:23 +0200 From: Juergen Quittek To: Tom Petch Subject: Re: [Isms] Agenda for ISMS at IETF-63 in Paris Message-ID: <59A9A9BC017AB1099E6614F7@openconcorde-21-115.ietf63.ietf.org> In-Reply-To: <001001c595aa$94f52580$0601a8c0@pc6> References: <88F766D04E6AF3409B39E60D7D933EB20E8BC6@europa.office> <001001c595aa$94f52580$0601a8c0@pc6> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom, Thanks for the hint. Is my understanding correct that you volunteer for taking minutes? Thanks, Juergen --On 7/31/2005 10:31 AM +0200 Tom Petch wrote: > Juergen, Ken > > Just to state the obvious, in the light of the current objectives of isms, the > 70 minute session on transport protocol selection is critical so I would urge > you to ensure that the minutes capture the key technical points made and are > available in a timely manner so that the discussion can continue from a common > base. > > Tom Petch > > ----- Original Message ----- > From: "Juergen Quittek" > To: > Cc: > Sent: Friday, July 29, 2005 11:07 AM > Subject: [Isms] Agenda for ISMS at IETF-63 in Paris > > > ============================================= > Integrated Security Model for SNMP WG (isms) > IETF #63 > Thursday August 4, 2005 : 1030-1230 > ============================================ > > Chairs: > Ken Hornstein > Juergen Quittek > > AGENDA: > > 1) Agenda bashing, WG Status ( 5 min) > > 2) A BEEP Profile for SNMPv3 PDUs (20 min) > - draft-kaushik-isms-btsm-01.txt > > 3) Selection of the ISMS transport protocol (70 min) > > 4) Charter discussion (optional) (20 min) > > 5) Wrap up ( 5 min) > - action points, schedule for charter > > > INTERNET DRAFTS: > > Transport Layer Security Model (TLSM) for the Simple Network > Management Protocol version 3 (SNMPv3) > http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-02.txt > > A BEEP Profile for SNMPv3 PDUs > http://www.ietf.org/internet-drafts/draft-kaushik-isms-btsm-01.txt > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms