From isms-bounces@lists.ietf.org Tue May 01 12:19:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiv4G-0008VV-HR; Tue, 01 May 2007 12:19:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiv4F-0008KK-2i for isms@ietf.org; Tue, 01 May 2007 12:19:07 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hiv4D-0003EX-Pa for isms@ietf.org; Tue, 01 May 2007 12:19:07 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l41GIrnc002652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 May 2007 09:18:53 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l41GIqpM008157; Tue, 1 May 2007 09:18:52 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l41GIowt008007; Tue, 1 May 2007 09:18:52 -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.1830); Tue, 1 May 2007 09:18:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] working group lastcallondraft-ietf-isms-transport-security-model-03 Date: Tue, 1 May 2007 09:18:51 -0700 Message-ID: <474EEBD229DF754FB83D256004D0210805DF8E48@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <048001c78997$a4c995d0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] working group lastcallondraft-ietf-isms-transport-security-model-03 Thread-Index: AcdioPSTqZ700mf4QjiyaEeiXkzUIQi6/pJAAFOPxUAATL4U4ABBYdSAABqemMAABcBAoACdr6HA References: <01e101c78703$a24326f0$0600a8c0@china.huawei.com><046d01c78939$0fdcd3a0$0600a8c0@china.huawei.com> <048001c78997$a4c995d0$0600a8c0@china.huawei.com> From: "Fleischman, Eric" To: , , , X-OriginalArrivalTime: 01 May 2007 16:18:52.0473 (UTC) FILETIME=[688A2A90:01C78C0C] X-Spam-Score: 1.1 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org The people I have been talking with and I conform to David's observations (his 3 bullet points below). The general view (as seen from my knothole) is wonder that any protocol could exist in our current brave new world that cannot be adequately secured. -----Original Message----- From: David Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Saturday, April 28, 2007 6:18 AM To: 'Wijnen, Bert (Bert)'; 'Juergen Quittek'; isms@ietf.org Subject: RE: [Isms] working group lastcallondraft-ietf-isms-transport-security-model-03 Hi, My own experience, and previous discussions on this mailing list, make it quite obvious that 1) people would **like** to see TSM work with SNMPv1 and SNMPv2c, and 2) people **expect** that TSM will just work with SNMPv1 and SNMPv2c, and 3) people are **surprised** to learn that, because of RFC3584, it does not. I think I have a pretty good understanding of the RFC3411 architecture and the way RFC3412 dispatching works, but I was surprised TSM would not work with SNMPv1 and SNMPv2c. Even if the ISMS WG takes on the task of rewriting RFC3584, 3) would not go away if the implementation used is not upgraded to RFC3584bis. I think it reasonable to keep the explanation in the Co-existence section of TSM, so people understand why 2) doesn't just happen. dbh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 01 18:50:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj1BL-0003Id-6U; Tue, 01 May 2007 18:50:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj1B6-0002W2-7g; Tue, 01 May 2007 18:50:36 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hj1B4-0004T0-Q4; Tue, 01 May 2007 18:50:36 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id AFCDE2AC66; Tue, 1 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hj1AY-0002Qc-F5; Tue, 01 May 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 01 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-transport-security-model-04.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: , Errors-To: isms-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Security Model for SNMP Author(s) : D. Harrington Filename : draft-ietf-isms-transport-security-model-04.txt Pages : 26 Date : 2007-5-1 This memo describes a Transport Security Model for the Simple Network Management Protocol. This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for monitoring and managing the Transport Security Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-transport-security-model-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isms-transport-security-model-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isms-transport-security-model-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-1151153.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-transport-security-model-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-transport-security-model-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-1151153.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@lists.ietf.org Tue May 01 21:15:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj3RM-0007ya-5L; Tue, 01 May 2007 21:15:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj3RK-0007yV-V3 for isms@ietf.org; Tue, 01 May 2007 21:15:30 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hj3RJ-0005c0-He for isms@ietf.org; Tue, 01 May 2007 21:15:30 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 01 May 2007 18:15:28 -0700 X-IronPort-AV: i="4.14,476,1170662400"; d="scan'208"; a="143135878:sNHT54189828" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l421FSQp006510; Tue, 1 May 2007 18:15:28 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l421FOEi002753; Wed, 2 May 2007 01:15:24 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 May 2007 18:15:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] radius integration document update Date: Tue, 1 May 2007 18:15:26 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C30371F794@xmb-sjc-22d.amer.cisco.com> In-Reply-To: <20070420102523.GB11656@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] radius integration document update Thread-Index: AceDNkqh5yK/O06tRReuOnLvbshwaQJINd8Q From: "Kaushik Narayan \(kaushik\)" To: , , X-OriginalArrivalTime: 02 May 2007 01:15:24.0000 (UTC) FILETIME=[5C2F5E00:01C78C57] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1342; t=1178068528; x=1178932528; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20RE=3A=20[Isms]=20radius=20integration=20document=20update |Sender:=20; bh=eXR8+mU7Qj49l6SEBrX56TfntHYEaiz7+RZcast0dCc=; b=GPKQY1cwJ0O2jD/8DDHiLQqnpApwDZsQ/RHbJColi4CASR+SGBfOAq1F6hCHhk2DTHgBmejA SD54wZRGeheNdEsyDKyjvxTF9r441libHGY/UZ5lgozbj1dKMPCAzOM0; Authentication-Results: sj-dkim-2; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi Juergen, Sorry for the delayed response. We will try to post an update incorporating the changes as suggested by the WG within a weeks time. regards, kaushik =20 -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 Sent: Friday, April 20, 2007 3:25 AM To: kaushik_narayan@yahoo.com; d.b.nelson@comcast.net Cc: isms@ietf.org Subject: [Isms] radius integration document update Hi, following the discussion in Prague, we need to update the RADIUS document to a) bring it into sync with the introduction of a transport subsystem and transport security models, and to b) remove any discussion about authorization that goes beyond the authorization to use a secure transport model (e.g. an ssh subsystem). I suggest that our document editors post a revised version of their individual submission taking a) and b) into account. Once we have that revision in place, we can decided to accept it as a WG document. It would be nice if this can be done until the end of April. /js --=20 Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 02 09:38:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjF2Q-0002SI-5c; Wed, 02 May 2007 09:38:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjF2O-0002SD-Uc for isms@ietf.org; Wed, 02 May 2007 09:38:32 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HjF2M-00053b-Df for isms@ietf.org; Wed, 02 May 2007 09:38:32 -0400 Received: from pc6 (1Cust102.tnt30.lnd3.gbr.da.uu.net [62.188.122.102]) by blaster.systems.pipex.net (Postfix) with SMTP id 2BA81E0006E6; Wed, 2 May 2007 14:38:23 +0100 (BST) Message-ID: <046e01c78cb6$4f47f1c0$0601a8c0@pc6> From: "tom.petch" To: "Fleischman, Eric" , References: <01e101c78703$a24326f0$0600a8c0@china.huawei.com><046d01c78939$0fdcd3a0$0600a8c0@china.huawei.com><048001c78997$a4c995d0$0600a8c0@china.huawei.com> <474EEBD229DF754FB83D256004D0210805DF8E48@XCH-NW-6V1.nw.nos.boeing.com> Subject: STM and v2CRe: [Isms] working grouplastcallondraft-ietf-isms-transport-security-model-03 Date: Wed, 2 May 2007 14:21: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: 1.1 (+) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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: , Errors-To: isms-bounces@lists.ietf.org I agree that taking the spirit of RFC3584 as is, there is no way to invoke TSM from a v2c MPM. But I see no bar to transporting v2c messages over a Secure Transport Model such as SSH. The application specifies SSH in transportDomain/Address along with pduVersion 1 and securityModel 2. The MPM generates destTransportDomain/Address but I see nothing in the MPM to cause that to be any different to that which the application requested. No tmStateReference is generated. The STM sees the SSH transportDomain and uses or creates a secure tunnel over which to transport the message. On receipt, a tmStateReference is generated but ignored by the v2c SM which uses securityParameters, if present, to generate a securityName via the snmpCommunityTable You gain privacy and integrity for the messages, and some degree of authentication of the remote host. Tom Petch ----- Original Message ----- From: "Fleischman, Eric" To: ; ; ; Sent: Tuesday, May 01, 2007 6:18 PM Subject: RE: [Isms] working grouplastcallondraft-ietf-isms-transport-security-model-03 The people I have been talking with and I conform to David's observations (his 3 bullet points below). The general view (as seen from my knothole) is wonder that any protocol could exist in our current brave new world that cannot be adequately secured. -----Original Message----- From: David Harrington [mailto:ietfdbh@comcast.net] Sent: Saturday, April 28, 2007 6:18 AM To: 'Wijnen, Bert (Bert)'; 'Juergen Quittek'; isms@ietf.org Subject: RE: [Isms] working group lastcallondraft-ietf-isms-transport-security-model-03 Hi, My own experience, and previous discussions on this mailing list, make it quite obvious that 1) people would **like** to see TSM work with SNMPv1 and SNMPv2c, and 2) people **expect** that TSM will just work with SNMPv1 and SNMPv2c, and 3) people are **surprised** to learn that, because of RFC3584, it does not. I think I have a pretty good understanding of the RFC3411 architecture and the way RFC3412 dispatching works, but I was surprised TSM would not work with SNMPv1 and SNMPv2c. Even if the ISMS WG takes on the task of rewriting RFC3584, 3) would not go away if the implementation used is not upgraded to RFC3584bis. I think it reasonable to keep the explanation in the Co-existence section of TSM, so people understand why 2) doesn't just happen. dbh _______________________________________________ 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 May 08 12:46:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlSpa-0000wW-Qf; Tue, 08 May 2007 12:46:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlJ7J-0002ig-Ix for isms@ietf.org; Tue, 08 May 2007 02:24:09 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlJ7H-0004Pp-9X for isms@ietf.org; Tue, 08 May 2007 02:24:09 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 7AD1F6D9C1 for ; Tue, 8 May 2007 08:24:06 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 13107-02; Tue, 8 May 2007 08:24:03 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 219C16D9ED; Tue, 8 May 2007 08:24:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 418D324D854; Tue, 8 May 2007 08:24:02 +0200 (CEST) Date: Tue, 8 May 2007 08:24:02 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20070508062402.GB13781@elstar.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.15 (2007-04-06) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Tue, 08 May 2007 12:46:29 -0400 Cc: Subject: [Isms] status of draft-ietf-isms-transport-security-model-04.txt 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: , Errors-To: isms-bounces@lists.ietf.org Hi, David posted a few days ago. David, can you summarize where you see this document? Do you think this document addresses all the comments received during the WG last call or are there any open issues left on this document? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 08 13:45:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlTka-0001TH-WD; Tue, 08 May 2007 13:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlTkZ-0001T6-Bv for isms@ietf.org; Tue, 08 May 2007 13:45:23 -0400 Received: from alnrmhc15.comcast.net ([206.18.177.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlTkZ-00054X-1z for isms@ietf.org; Tue, 08 May 2007 13:45:23 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc15) with SMTP id <20070508174522b1500sl64be>; Tue, 8 May 2007 17:45:22 +0000 From: "David Harrington" To: "'tom.petch'" , "'Fleischman, Eric'" , References: <01e101c78703$a24326f0$0600a8c0@china.huawei.com><046d01c78939$0fdcd3a0$0600a8c0@china.huawei.com><048001c78997$a4c995d0$0600a8c0@china.huawei.com><474EEBD229DF754FB83D256004D0210805DF8E48@XCH-NW-6V1.nw.nos.boeing.com> <046e01c78cb6$4f47f1c0$0601a8c0@pc6> Subject: RE: STM and v2CRe: [Isms] workinggrouplastcallondraft-ietf-isms-transport-security-model-03 Date: Tue, 8 May 2007 13:45:13 -0400 Message-ID: <018601c79198$a44af1e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <046e01c78cb6$4f47f1c0$0601a8c0@pc6> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: AceMvy59yIMOH5C3TUq41zKtNi69kwE2Dang X-Spam-Score: 1.1 (+) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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: , Errors-To: isms-bounces@lists.ietf.org Hi, I fully agree. I do not think we said in the subsystem document, and I believe we will not say aything in the SSH Transport Model document to the effect that one cannot use an SSH transport model with SNMPv1 or SNMPv2c messages. All we have said is you cannot use the Transport Security Model in combination with the RFC3584 message processing models, because the RFC3584 processing will never route the message to the TSM. dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Wednesday, May 02, 2007 8:21 AM > To: Fleischman, Eric; isms@ietf.org > Subject: STM and v2CRe: [Isms] > workinggrouplastcallondraft-ietf-isms-transport-security-model-03 > > I agree that taking the spirit of RFC3584 as is, there is no > way to invoke TSM > from a v2c MPM. > > But I see no bar to transporting v2c messages over a Secure > Transport Model such > as SSH. The application specifies SSH in > transportDomain/Address along with > pduVersion 1 and securityModel 2. The MPM generates > destTransportDomain/Address > but I see nothing in the MPM to cause that to be any > different to that which the > application requested. No tmStateReference is generated. > The STM sees the SSH > transportDomain and uses or creates a secure tunnel over > which to transport the > message. > > On receipt, a tmStateReference is generated but ignored by > the v2c SM which uses > securityParameters, if present, to generate a securityName via the > snmpCommunityTable > > You gain privacy and integrity for the messages, and some degree of > authentication of the remote host. > > Tom Petch > > ----- Original Message ----- > From: "Fleischman, Eric" > To: ; ; > ; > Sent: Tuesday, May 01, 2007 6:18 PM > Subject: RE: [Isms] working > grouplastcallondraft-ietf-isms-transport-security-model-03 > > > The people I have been talking with and I conform to David's > observations (his 3 bullet points below). The general view > (as seen from > my knothole) is wonder that any protocol could exist in our current > brave new world that cannot be adequately secured. > > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Saturday, April 28, 2007 6:18 AM > To: 'Wijnen, Bert (Bert)'; 'Juergen Quittek'; isms@ietf.org > Subject: RE: [Isms] working group > lastcallondraft-ietf-isms-transport-security-model-03 > > Hi, > > My own experience, and previous discussions on this mailing list, make > it quite obvious that > 1) people would **like** to see TSM work with SNMPv1 and SNMPv2c, and > 2) people **expect** that TSM will just work with SNMPv1 and SNMPv2c, > and > 3) people are **surprised** to learn that, because of RFC3584, it does > not. > > I think I have a pretty good understanding of the RFC3411 architecture > and the way RFC3412 dispatching works, but I was surprised > TSM would not > work with SNMPv1 and SNMPv2c. > > Even if the ISMS WG takes on the task of rewriting RFC3584, 3) would > not go away if the implementation used is not upgraded to RFC3584bis. > I think it reasonable to keep the explanation in the Co-existence > section of TSM, so people understand why 2) doesn't just happen. > > dbh > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 08 14:57:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlUsI-0002On-Tc; Tue, 08 May 2007 14:57:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlUsI-0002Od-0u for isms@ietf.org; Tue, 08 May 2007 14:57:26 -0400 Received: from alnrmhc16.comcast.net ([204.127.225.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlUsG-00006b-53 for isms@ietf.org; Tue, 08 May 2007 14:57:26 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc16) with SMTP id <20070508185723b1600hl5n8e>; Tue, 8 May 2007 18:57:23 +0000 From: "David Harrington" To: , References: <20070508062402.GB13781@elstar.local> Subject: RE: [Isms] status of draft-ietf-isms-transport-security-model-04.txt Date: Tue, 8 May 2007 14:57:18 -0400 Message-ID: <018a01c791a2$b40144e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20070508062402.GB13781@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: AceRkG6W8KwY7aFBQtado4d71iZWSAABl5CA X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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: , Errors-To: isms-bounces@lists.ietf.org I believe the document represents WG consensus on all raised issues. In a few cases, the consensus was rough, and the chairs might want to review the discussions on these points. 1) should the incompatibility of TSM and rfc3584 be mentioned? 2) should an error be generated by TSM if msgSecurityParameters is not a zero length OCTET STRING? 3) should the prepareResponseMessage ASI include transport parameters? dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Tuesday, May 08, 2007 2:24 AM > To: isms@ietf.org > Subject: [Isms] status of > draft-ietf-isms-transport-security-model-04.txt > > Hi, > > David posted a few > days ago. > > David, can you summarize where you see this document? Do you think > this document addresses all the comments received during the WG last > call or are there any open issues left on this document? > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > 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 May 09 09:11:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hllwl-0004zX-V8; Wed, 09 May 2007 09:11:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hllwk-0004yV-RS for isms@ietf.org; Wed, 09 May 2007 09:11:10 -0400 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hllwj-0002zZ-IC for isms@ietf.org; Wed, 09 May 2007 09:11:10 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20070509131109b1200f9crbe>; Wed, 9 May 2007 13:11:09 +0000 From: "David Harrington" To: References: <20070508062402.GB13781@elstar.local> <018a01c791a2$b40144e0$0600a8c0@china.huawei.com> <20070509122133.GA16392@elstar.local> Subject: RE: [Isms] status ofdraft-ietf-isms-transport-security-model-04.txt Date: Wed, 9 May 2007 09:11:03 -0400 Message-ID: <027c01c7923b$7fdc2c90$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20070509122133.GA16392@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: AceSNKsbMLZHhTwfQ9eDXih/LbFw4AAA1tew X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Comments inline > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Wednesday, May 09, 2007 8:22 AM > To: David Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] status > ofdraft-ietf-isms-transport-security-model-04.txt > > On Tue, May 08, 2007 at 02:57:18PM -0400, David Harrington wrote: > > > I believe the document represents WG consensus on all raised issues. > > In a few cases, the consensus was rough, and the chairs > might want to > > review the discussions on these points. > > > > 1) should the incompatibility of TSM and rfc3584 be mentioned? > > There is no incompatibility with RFC 3584 as far as I can tell. I > understand that people are interested in the transition path from > SNMPv1/SNMPv2c to an ISMS solution, but this is in my view not bound > to RFC 3584. The following text in section 2.3 > > The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP > 74) [RFC3584] always selects the SNMPv1(1) Security Model for an > SNMPv1 message, or the SNMPv2c(2) Security Model for an SNMPv2c > message. Since there is no field in the message format > that permits > specifying a Security Model, RFC3584 message processing does not > permit the selection of Security Models other than SNMPv1 > or SNMPv2. > Therefore, SNMPv1 or SNMPv2c messages that go through the SNMPv1 or > SNMPv2 Message Processing Models **as defined in RFC3584** > cannot use > the Transport Security Model. (This does not mean an SNMPv1 or > SNMPv2 message cannot use a secure transport model, only that the > RFC3584 MPM will not invoke this security model.) > > seems to describe the situation in an appropriate way. Perhaps a note > can be added that running SNMPv1/SNMPv2c over a secure transport like > SSH has some problems, namely that the securityName used for access > control decisions is then derived from the community string, which is > not the authenticated identity. (I can authenticate as guest and then > simply claim to be root.) will add the note. > > 3) should the prepareResponseMessage ASI include transport > parameters? > [...] > In other words, architecturally it makes sense to include these > parameters for consistency between the generateRequestMsg() and > generateResponseMsg() ASIs and added flexibility for future security > models, but for ISMS to achieve its goals, these parameters are not > strictly needed for the generateResponseMsg() ASI. Am I correct? Yes. > > Reading consensus is difficult here since this was mostly a discussion > between you and Bert. If my summary above is correct and somewhat > understandable, then perhaps others can speak up here and help us to > find concensus (or you and Bert reach agreement ;-). We can try. > > In any case, the introduction of these parameters should have been > described in the transport subsystem document > and not in the transport security model. At the moment, these > documents do not seem to be consistent; in fact, section 6.2 of the > transport subsystem document should probably spell out the signatures > of the generateRequestMsg() and generateResponseMsg() ASIs and > indicate the new elements. When I submitted the TSM update, I also submitted a TMSM update; I don't know why that has not been published as well. That had the requested fix. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 09 11:21:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlnyV-00067g-7C; Wed, 09 May 2007 11:21:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HllBM-00071y-4t for isms@ietf.org; Wed, 09 May 2007 08:22:12 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HllBK-0002y1-Jv for isms@ietf.org; Wed, 09 May 2007 08:22:12 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id CA7C476881; Wed, 9 May 2007 14:22:09 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 06259-03; Wed, 9 May 2007 14:22:05 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id EF0997AE0B; Wed, 9 May 2007 14:21:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D98E924F59B; Wed, 9 May 2007 14:21:33 +0200 (CEST) Date: Wed, 9 May 2007 14:21:33 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] status of draft-ietf-isms-transport-security-model-04.txt Message-ID: <20070509122133.GA16392@elstar.local> Mail-Followup-To: David Harrington , isms@ietf.org References: <20070508062402.GB13781@elstar.local> <018a01c791a2$b40144e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <018a01c791a2$b40144e0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.15 (2007-04-06) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-Mailman-Approved-At: Wed, 09 May 2007 11:21:05 -0400 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: , Errors-To: isms-bounces@lists.ietf.org On Tue, May 08, 2007 at 02:57:18PM -0400, David Harrington wrote: > I believe the document represents WG consensus on all raised issues. > In a few cases, the consensus was rough, and the chairs might want to > review the discussions on these points. > > 1) should the incompatibility of TSM and rfc3584 be mentioned? There is no incompatibility with RFC 3584 as far as I can tell. I understand that people are interested in the transition path from SNMPv1/SNMPv2c to an ISMS solution, but this is in my view not bound to RFC 3584. The following text in section 2.3 The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP 74) [RFC3584] always selects the SNMPv1(1) Security Model for an SNMPv1 message, or the SNMPv2c(2) Security Model for an SNMPv2c message. Since there is no field in the message format that permits specifying a Security Model, RFC3584 message processing does not permit the selection of Security Models other than SNMPv1 or SNMPv2. Therefore, SNMPv1 or SNMPv2c messages that go through the SNMPv1 or SNMPv2 Message Processing Models **as defined in RFC3584** cannot use the Transport Security Model. (This does not mean an SNMPv1 or SNMPv2 message cannot use a secure transport model, only that the RFC3584 MPM will not invoke this security model.) seems to describe the situation in an appropriate way. Perhaps a note can be added that running SNMPv1/SNMPv2c over a secure transport like SSH has some problems, namely that the securityName used for access control decisions is then derived from the community string, which is not the authenticated identity. (I can authenticate as guest and then simply claim to be root.) [Note that on an API level, I believe ISMS can be made to look very similar to SNMPv1/SNMPv2c and this I believe addresses the concerns people have in practice.] > 2) should an error be generated by TSM if msgSecurityParameters is not > a zero length OCTET STRING? I polled for additional opinions with very little feedback and a slight preference to treat a non-zero length value as an error, and this is also what the text currently says in section 5.2: 2) If the received securityParameters is not a zero-length OCTET STRING, then the snmpInASNParseErrs counter [RFC3418] is incremented, and an error indication (parseError) is returned to the calling module, and Security Model processing stops for this message. If WG members feel strongly that this should be changed, please speak up now. I will read silence as agreement to the current text. > 3) should the prepareResponseMessage ASI include transport parameters? I assume the question is about the generateResponseMsg() ASI. As far as I understand, you proposed to add IN transportDomain -- (NEW) specified by application IN transportAddress -- (NEW) specified by application to both generateRequestMsg() and generateResponseMsg(). It is clear why these parameters are needed in generateRequestMsg(), but it is less clear why they are needed in generateResponseMsg() (the transport security model extracts those values from the cache - these parameters would only be needed in future security models where responses would be allowed to travel over transports different than the transport used to receive the request). In other words, architecturally it makes sense to include these parameters for consistency between the generateRequestMsg() and generateResponseMsg() ASIs and added flexibility for future security models, but for ISMS to achieve its goals, these parameters are not strictly needed for the generateResponseMsg() ASI. Am I correct? Reading consensus is difficult here since this was mostly a discussion between you and Bert. If my summary above is correct and somewhat understandable, then perhaps others can speak up here and help us to find concensus (or you and Bert reach agreement ;-). In any case, the introduction of these parameters should have been described in the transport subsystem document and not in the transport security model. At the moment, these documents do not seem to be consistent; in fact, section 6.2 of the transport subsystem document should probably spell out the signatures of the generateRequestMsg() and generateResponseMsg() ASIs and indicate the new elements. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 10 01:39:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm1NH-0004YQ-Db; Thu, 10 May 2007 01:39:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm1NG-0004YK-AN for isms@ietf.org; Thu, 10 May 2007 01:39:34 -0400 Received: from alnrmhc13.comcast.net ([206.18.177.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm1ND-0004nH-Fj for isms@ietf.org; Thu, 10 May 2007 01:39:33 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc13) with SMTP id <20070510053930b1300dovkke>; Thu, 10 May 2007 05:39:31 +0000 From: "David Harrington" To: , Subject: RE: [Isms] review of draft-ietf-isms-secshell-05.txt Date: Thu, 10 May 2007 01:39:21 -0400 Message-ID: <033d01c792c5$9154b9d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20061105001324.GC27351@boskop.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: AccAbzmJDxP72rMaTpyISCq3g49mLwottang X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 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: , Errors-To: isms-bounces@lists.ietf.org > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Saturday, November 04, 2006 7:13 PM > To: isms@ietf.org > Subject: [Isms] review of draft-ietf-isms-secshell-05.txt > > I have reviewed and below are my > comments (as a technical contributor). > > /js > > 01: Page 1: Reference [RFC 3411] in the third paragraph in section 1. Done. > > 02: Page 5: The last sentence in the 3rd paragraph of section 1.3 > somehow does not read well. fixed > > 03: Page 5: "User Security Model" -> "User-based Security Model" fixed > > 04: Page 6: Keyboard-interactive [RFC4256] has been excluded from the > discussion of authentication mechanisms and I think it should be > mentioned. added a reference and a citation in the SSH Protocol overview section. Do you want more discussion? Can you provide text? > > 05: Page 7: Is the last paragraph on this page needed? removed. > > 06: Page 8: I think we should replace the term "tunnel" with > "channel". >From RFC4284: This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel." It looks to me like tunnel is the correct choice. > > 07: Page 10: "SSH.This" -> "SSH. This" > done. > 08: Page 10: I think we need to mention here keyboard-interactive > again. done. > > 09: Page 11: Expland "DH" the first time it is used. done. > > 10: Page 11: The first paragraph in section 3.1.7 actually is part of > an applicability statement and perhaps should be factored out into > a separate section. done. > > 11: Page 12: I think engineID discovery is so widely used with USM > that we can't make the discovery implementation-dependent. We need > an interoperable solution. engineID discovery is critical to USM because it needs the securityEngineID. > > The USM discovery procedure concerns the securityEngineID (the > contextEngineID is actually not passed to a security model). My > understanding is that implementations usually do securityEngineID > discovery and subsequently use the securityEngineID also as the > contextEngineID (basically assuming that they talk to the > non-proxy agent). Please correct me if my assumption is wrong. > > Dave Perkins wrote a private message on this subject to a few > people on Thu, 8 Sep 2005 which led to the conclusion that one > should get an snmpUnknownPDUHandlers report if there is not value > engineID (or the PDU type is invalid) and that this can be used to > pickup the "local" engineID. Dave Perkins, can you post the > relevant part of your message to this list? [Note that we also > discussed this durng the Boston interim.] > > An alternative approach could be to introduce a "fake" > securityEngineID into the Transport Security Model for the only > purpose to let it be discovered and to let clients to continue to > assume that the securityEngineID is the contextEngineID to use. > > Another alternative would be to introduce a general "default" > contextEngineID (while conceptually simply and appealing, this > does not really work due to the fact the no existing > implementation has something like that and all SNMPv3/USM > implementations are not likely to change). > We need to settle on one approach and document it properly. I do not believe contextEngineID should be discovered by a transport model or a security model; I believe contextEngineID discovery should be an application-level function. I believe your discovery document with a 'local' engineID serves this purpose. I eliminated the discovery section, an dall reference to engineIDnoted. > > 12: Page 13: 1st paragraph in 3.3: Is it OK to be silent how > credentials are provisioned? Provisioning will be at least partly implementation-dependent. > > 13: Page 14: Why do you use the tms prefix here? Note that the names > of the transport domain etc. may need to be updated. I am not sure > why you want to have the security model in the LCD. agreed; I have eliminated securityModel from the document, since the transport doesn't know about security models. > > 14: Page 16: tmsTransportModel can't be "SSH Transport Model" removed any reference to update transportmodel; since we now use a transportDomain, we don't need a transportmodel parameter. > > 15: Page 16: Add a comment after tmStateReference in the ASIs. done. > > 16: Page 17: Add a comment after tmStateReference in the ASI and > fix the alignment of the comments. done. > > 17: Page 18: [todo]: This is mainly an architectural problem since we > can't write the EoP; I assume that in most implementations, you > still know whether you send a response or a request. I am not sure > what to do about it. This needs discussion. need to develop a tmSameSession boolean and EOP to deal with it. > > 18: Page 18: [todo]: I think it is always the client invoking the > ssh-userauth service. Shall we state as in step 1) that it is > implementation dependent where the parameters are coming from? done. > > 19: Page 19: drop "(TBD by IANA)" done. > > 20: Page 19: The last paragraph in 5.3 likely needs updates depending > how we want to deal with engineID discovery. And I kind of believe > we should deal with this in the Transport Security Model, not in > every Transport Model. As mentioned above, I believe this should be an application-level function, not a transport, message, or security model function. > > 21: Page 19: The first sentence in 5.4 needs a rewrite - closeSession > does not pass data between the Transport Model and the SSH > Service. done. > > 22: Page 21: "SSHTM-MIB" -> "SNMP-SSH-TM-MIB" to be consistent with > prior naming conventions. This module should likely be registered > under snmpModules as well. done. > > 23: Page 23: I am not sure we need TransportAddressSSH; we should be > able to use TransportAddressDns. changed to snmpSSHDomain and SnmpSSHAddress > > 24: Page 24: I think transportDomainSSH should be snmpSshDomain and be > registered below snmpDomains (now that we even have an IANA > registry for this). done. > > 25: Page 24: Does sshtmSessionOpenErrors count all open errors ranging > from TCP connection establishment failures to SSH user > authentication failures? yup. > > 26: Page 24: When will sshtmSessionSecurityLevelNotAvailableErrors be > incremented? Does the document not say SSH is always providing > good enough security and we trust it? yes. removed. > > 27: Page 30: I do not understand the [discuss]. removed. > > 28: Page 30/31: The MIB module security section needs to be updated. yes; once we stabilize the MIB, I'll update the security cons. > > 29: Page 31: IANA considerations need to be updated (mib-2 -> > snmpModules, done. > registration of snmpSshDomain, added request to iana considerations > creation of the > transport modules registration is done the transport model > architectural extension document. No it doesn't. The TMSM doesn't require anything of IANA. We don't register transport models; we define a transport domain for each transport model. > > > -- > 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 May 10 02:10:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm1ra-0005dd-Ti; Thu, 10 May 2007 02:10:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm1rZ-0005dV-CH for isms@ietf.org; Thu, 10 May 2007 02:10:53 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm1rY-0000Sn-2D for isms@ietf.org; Thu, 10 May 2007 02:10:53 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 4942F5609B; Thu, 10 May 2007 08:10:51 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 01939-03; Thu, 10 May 2007 08:10:47 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id BAE335AC6F; Thu, 10 May 2007 08:10:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C7D8824FE79; Thu, 10 May 2007 08:10:46 +0200 (CEST) Date: Thu, 10 May 2007 08:10:46 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] review of draft-ietf-isms-secshell-05.txt Message-ID: <20070510061046.GA17238@elstar.local> Mail-Followup-To: David Harrington , isms@ietf.org References: <20061105001324.GC27351@boskop.local> <033d01c792c5$9154b9d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <033d01c792c5$9154b9d0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.15 (2007-04-06) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Thu, May 10, 2007 at 01:39:21AM -0400, David Harrington wrote: > > 06: Page 8: I think we should replace the term "tunnel" with > > "channel". > From RFC4284: This document describes the SSH Connection Protocol. > It provides > interactive login sessions, remote execution of commands, forwarded > TCP/IP connections, and forwarded X11 connections. All of these > channels are multiplexed into a single encrypted tunnel." > > It looks to me like tunnel is the correct choice. I believe ISMS runs over an SSH channel, not the underlying encrypted tunnel. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 10 10:36:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9kk-0004q2-GD; Thu, 10 May 2007 10:36:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9ki-0004pj-6O; Thu, 10 May 2007 10:36:20 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm9kh-0002XS-TV; Thu, 10 May 2007 10:36:20 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id C6C5226E83; Thu, 10 May 2007 14:36:19 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1Hm9kh-0002J1-NP; Thu, 10 May 2007 10:36:19 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 10 May 2007 10:36:19 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-tmsm-08.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: , Errors-To: isms-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Subsystem for the Simple Network Management Protocol (SNMP) Author(s) : D. Harrington, J. Schoenwaelder Filename : draft-ietf-isms-tmsm-08.txt Pages : 35 Date : 2007-5-9 This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models, comparable to other subsystems in the RFC3411 architecture. As work is being done to expand the transport to include secure transport such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isms-tmsm-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isms-tmsm-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-10103600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-tmsm-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-tmsm-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-10103600.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@lists.ietf.org Thu May 10 10:50:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9y6-0007sV-63; Thu, 10 May 2007 10:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9y0-0007oI-8h; Thu, 10 May 2007 10:50:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm9xz-0006if-MM; Thu, 10 May 2007 10:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 13B6E26E9E; Thu, 10 May 2007 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hm9xx-0002iL-VD; Thu, 10 May 2007 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 10 May 2007 10:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-secshell-06.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: , Errors-To: isms-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Secure Shell Transport Model for SNMP Author(s) : J. Salowey, D. Harrington Filename : draft-ietf-isms-secshell-06.txt Pages : 37 Date : 2007-5-10 This memo describes a Transport Model for the Simple Network Management Protocol, using the Secure Shell protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isms-secshell-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isms-secshell-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-10094137.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-secshell-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-secshell-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-10094137.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@lists.ietf.org Fri May 11 13:19:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmYm9-0001ZN-ER; Fri, 11 May 2007 13:19:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmYm8-0001Ye-KK for isms@ietf.org; Fri, 11 May 2007 13:19:28 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmYm7-0008D1-Bh for isms@ietf.org; Fri, 11 May 2007 13:19:28 -0400 Received: from pc6 (1Cust217.tnt29.lnd3.gbr.da.uu.net [62.188.120.217]) by astro.systems.pipex.net (Postfix) with SMTP id E912CE00026F; Fri, 11 May 2007 18:19:24 +0100 (BST) Message-ID: <000401c793e7$a5677de0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , , References: <033d01c792c5$9154b9d0$0600a8c0@china.huawei.com> Date: Fri, 11 May 2007 18:11:38 +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.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Isms] draft-ietf-isms-tmsm-08.txt 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: , Errors-To: isms-bounces@lists.ietf.org I have a concern with this I-D that it is blurring the meaning of authentication As per RFC2828, there is data origin authentication and peer entity authentication. Read the secure session RFC, such as SSH and TLS, and they are clear that they offer peer entity authentication.and not data origin authentication. This I-D, like the RFC341? series, seems to be written as if there were only data origin authentication, as if authentication was a security function that will applied to an isolated message, as opposed to occurring only in the context of an association. Rather, with Transport Security, the message cannot be authenticated; it came over a pipe from a peer which was authenticated some time in the past and the authentication depends on the continued existence of that pipe. In security terms, I see the difference as significant and one that this I-D should call out. I see this in (at least) 3.2.1.2, 3.2.3 and 3.3.3 . Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 11 15:51:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmb90-0003Z2-MS; Fri, 11 May 2007 15:51:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmb8L-0001kP-AF; Fri, 11 May 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hmb8K-0005RW-FT; Fri, 11 May 2007 15:50:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 67229175FA; Fri, 11 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hmb7q-0000EN-5G; Fri, 11 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 11 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-secshell-07.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: , Errors-To: isms-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Secure Shell Transport Model for SNMP Author(s) : J. Salowey, D. Harrington Filename : draft-ietf-isms-secshell-07.txt Pages : 37 Date : 2007-5-11 This memo describes a Transport Model for the Simple Network Management Protocol, using the Secure Shell protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isms-secshell-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isms-secshell-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-11140559.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-secshell-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-secshell-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-11140559.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@lists.ietf.org Mon May 14 06:56:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnYC6-0002lF-11; Mon, 14 May 2007 06:54:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnYC4-0002l8-VR for isms@ietf.org; Mon, 14 May 2007 06:54:20 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnYC3-0007S4-E0 for isms@ietf.org; Mon, 14 May 2007 06:54:20 -0400 Received: from pc6 (1Cust113.tnt29.lnd3.gbr.da.uu.net [62.188.120.113]) by astro.systems.pipex.net (Postfix) with SMTP id 5A033E000439; Mon, 14 May 2007 11:54:16 +0100 (BST) Message-ID: <016a01c7960d$54a095e0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , References: <20070508062402.GB13781@elstar.local><018a01c791a2$b40144e0$0600a8c0@china.huawei.com><20070509122133.GA16392@elstar.local> <027c01c7923b$7fdc2c90$0600a8c0@china.huawei.com> Subject: Re: [Isms] status ofdraft-ietf-isms-transport-security-model-04.txt Date: Mon, 14 May 2007 11:48:09 +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.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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: , Errors-To: isms-bounces@lists.ietf.org Point 3 in this dialogue leave me confused (1 and 2 are fine by me). I am clear that I expect to see tmStateReference as an OUT parameter in prepareResponseMessage ASI ie the call from Dispatcher to MPP. Juergen's reply said "I assume the question is about the generateResponseMsg() ASI. " Nope, I do not assume that; I assume it is about prepareResponseMessage ASI RFC3411 s4.2.2 David's reply said "> When I submitted the TSM update, I also submitted a TMSM update; I > don't know why that has not been published as well. That had the > requested fix." Nope, I saw TMSM update draft-ietf-isms-tmsm-08.txt and TSM update draft-ietf-isms-transport-security-model-04.txt But the former does not contain the requested fix (it does contain other fixes such as the TLS reference); s6.2 still says "6.2. Other Outgoing ASIs A tmStateReference parameter has been added to the prepareOutgoingMessage, generateRequestMsg, and generateResponseMsg ASIs as an OUT parameter." prepareResponseMessage remains conspicuous by its absence. Tom Petch ----- Original Message ----- From: "David Harrington" To: Cc: Sent: Wednesday, May 09, 2007 3:11 PM Subject: RE: [Isms] status ofdraft-ietf-isms-transport-security-model-04.txt > Comments inline > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > > Sent: Wednesday, May 09, 2007 8:22 AM > > To: David Harrington > > Cc: isms@ietf.org > > Subject: Re: [Isms] status > > ofdraft-ietf-isms-transport-security-model-04.txt > > > > On Tue, May 08, 2007 at 02:57:18PM -0400, David Harrington wrote: > > > > > I believe the document represents WG consensus on all raised > issues. > > > In a few cases, the consensus was rough, and the chairs > > might want to > > > review the discussions on these points. > > > > > > 3) should the prepareResponseMessage ASI include transport > > parameters? > > > [...] > > In other words, architecturally it makes sense to include these > > parameters for consistency between the generateRequestMsg() and > > generateResponseMsg() ASIs and added flexibility for future security > > models, but for ISMS to achieve its goals, these parameters are not > > strictly needed for the generateResponseMsg() ASI. Am I correct? > > Yes. > > > > Reading consensus is difficult here since this was mostly a > discussion > > between you and Bert. If my summary above is correct and somewhat > > understandable, then perhaps others can speak up here and help us to > > find concensus (or you and Bert reach agreement ;-). > > We can try. > > > > > In any case, the introduction of these parameters should have been > > described in the transport subsystem document > > and not in the transport security model. At the moment, these > > documents do not seem to be consistent; in fact, section 6.2 of the > > transport subsystem document should probably spell out the > signatures > > of the generateRequestMsg() and generateResponseMsg() ASIs and > > indicate the new elements. > > When I submitted the TSM update, I also submitted a TMSM update; I > don't know why that has not been published as well. That had the > requested fix. > > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > 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 May 14 07:01:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnYHP-0006KZ-2q; Mon, 14 May 2007 06:59:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnYHN-0006KQ-Jq for isms@ietf.org; Mon, 14 May 2007 06:59:49 -0400 Received: from alnrmhc13.comcast.net ([206.18.177.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnYHL-0000VV-6l for isms@ietf.org; Mon, 14 May 2007 06:59:49 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc13) with SMTP id <20070514105946b1300dnu6ae>; Mon, 14 May 2007 10:59:46 +0000 From: "David Harrington" To: "'tom.petch'" , References: <20070508062402.GB13781@elstar.local><018a01c791a2$b40144e0$0600a8c0@china.huawei.com><20070509122133.GA16392@elstar.local> <027c01c7923b$7fdc2c90$0600a8c0@china.huawei.com> <016a01c7960d$54a095e0$0601a8c0@pc6> Subject: RE: [Isms] status ofdraft-ietf-isms-transport-security-model-04.txt Date: Mon, 14 May 2007 06:59:38 -0400 Message-ID: <05b701c79616$f8126330$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <016a01c7960d$54a095e0$0601a8c0@pc6> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: AceWFjjQT4G/aUYiSh+LkZqhfsv3HAAACxhg X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, I apologize. I accepted Juergen;s comment, and just assumed I had made a typo referencing the ASI. You know what they say about asumming. I'll reply later today on this issue - AFTER doing the research I should have done earlier. dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Monday, May 14, 2007 5:48 AM > To: David Harrington; j.schoenwaelder@iu-bremen.de > Cc: isms@ietf.org > Subject: Re: [Isms] status > ofdraft-ietf-isms-transport-security-model-04.txt > > Point 3 in this dialogue leave me confused (1 and 2 are fine by me). > > I am clear that I expect to see tmStateReference as an OUT > parameter in > prepareResponseMessage ASI ie the call from Dispatcher to MPP. > > Juergen's reply said > "I assume the question is about the generateResponseMsg() ASI. " > > Nope, I do not assume that; I assume it is about > prepareResponseMessage ASI > RFC3411 s4.2.2 > > David's reply said > "> When I submitted the TSM update, I also submitted a TMSM update; I > > don't know why that has not been published as well. That had the > > requested fix." > > Nope, I saw TMSM update draft-ietf-isms-tmsm-08.txt and TSM update > draft-ietf-isms-transport-security-model-04.txt > But the former does not contain the requested fix (it does > contain other fixes > such as the TLS reference); s6.2 still says > "6.2. Other Outgoing ASIs > > A tmStateReference parameter has been added to the > prepareOutgoingMessage, generateRequestMsg, and generateResponseMsg > ASIs as an OUT parameter." > > prepareResponseMessage remains conspicuous by its absence. > > Tom Petch > > > ----- Original Message ----- > From: "David Harrington" > To: > Cc: > Sent: Wednesday, May 09, 2007 3:11 PM > Subject: RE: [Isms] status > ofdraft-ietf-isms-transport-security-model-04.txt > > > > Comments inline > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > > > Sent: Wednesday, May 09, 2007 8:22 AM > > > To: David Harrington > > > Cc: isms@ietf.org > > > Subject: Re: [Isms] status > > > ofdraft-ietf-isms-transport-security-model-04.txt > > > > > > On Tue, May 08, 2007 at 02:57:18PM -0400, David Harrington wrote: > > > > > > > I believe the document represents WG consensus on all raised > > issues. > > > > In a few cases, the consensus was rough, and the chairs > > > might want to > > > > review the discussions on these points. > > > > > > > > > > > 3) should the prepareResponseMessage ASI include transport > > > parameters? > > > > > [...] > > > In other words, architecturally it makes sense to include these > > > parameters for consistency between the generateRequestMsg() and > > > generateResponseMsg() ASIs and added flexibility for > future security > > > models, but for ISMS to achieve its goals, these > parameters are not > > > strictly needed for the generateResponseMsg() ASI. Am I correct? > > > > Yes. > > > > > > Reading consensus is difficult here since this was mostly a > > discussion > > > between you and Bert. If my summary above is correct and somewhat > > > understandable, then perhaps others can speak up here and > help us to > > > find concensus (or you and Bert reach agreement ;-). > > > > We can try. > > > > > > > > In any case, the introduction of these parameters should have been > > > described in the transport subsystem document > > > > and not in the transport security model. At the moment, these > > > documents do not seem to be consistent; in fact, section > 6.2 of the > > > transport subsystem document should probably spell out the > > signatures > > > of the generateRequestMsg() and generateResponseMsg() ASIs and > > > indicate the new elements. > > > > When I submitted the TSM update, I also submitted a TMSM update; I > > don't know why that has not been published as well. That had the > > requested fix. > > > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 > Bremen, Germany > > > Fax: +49 421 200 3103 > > > > > > > > > > > _______________________________________________ > > 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 May 17 18:25:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HooPe-0006wU-EM; Thu, 17 May 2007 18:25:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HooPd-0006wN-J9 for isms@ietf.org; Thu, 17 May 2007 18:25:33 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HooPc-0005RI-Bc for isms@ietf.org; Thu, 17 May 2007 18:25:33 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l4HMPTl7011302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 May 2007 18:25:30 -0400 (EDT) Date: Thu, 17 May 2007 18:25:29 -0400 From: Jeffrey Hutzelman To: j.schoenwaelder@jacobs-university.de, David Harrington Subject: Re: [Isms] review of draft-ietf-isms-secshell-05.txt Message-ID: <6198162911536B5F9060D117@sirius.fac.cs.cmu.edu> In-Reply-To: <20070510061046.GA17238@elstar.local> References: <20061105001324.GC27351@boskop.local> <033d01c792c5$9154b9d0$0600a8c0@china.huawei.com> <20070510061046.GA17238@elstar.local> Originator-Info: login-token=Mulberry:01KgwOsJR0gyR2V4YxXYo+H8F+RduxQIeXgTwVYIw=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) 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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: isms@ietf.org, Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Thursday, May 10, 2007 08:10:46 AM +0200 Juergen Schoenwaelder wrote: > On Thu, May 10, 2007 at 01:39:21AM -0400, David Harrington wrote: > >> > 06: Page 8: I think we should replace the term "tunnel" with >> > "channel". >> From RFC4284: This document describes the SSH Connection Protocol. >> It provides >> interactive login sessions, remote execution of commands, forwarded >> TCP/IP connections, and forwarded X11 connections. All of these >> channels are multiplexed into a single encrypted tunnel." >> >> It looks to me like tunnel is the correct choice. > > I believe ISMS runs over an SSH channel, not the underlying encrypted > tunnel. So do I. Note that "channel" has specific technical meaning in SSH, but "tunnel" really does not - the text you quote from 4284 uses the word in a generic sense. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 17 18:58:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoov2-00048M-KD; Thu, 17 May 2007 18:58:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoov0-0003yb-RB for isms@ietf.org; Thu, 17 May 2007 18:57:58 -0400 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hoouz-0000kL-4A for isms@ietf.org; Thu, 17 May 2007 18:57:58 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <20070517225756011005tn3ke>; Thu, 17 May 2007 22:57:56 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , References: <20061105001324.GC27351@boskop.local> <033d01c792c5$9154b9d0$0600a8c0@china.huawei.com> <20070510061046.GA17238@elstar.local> <6198162911536B5F9060D117@sirius.fac.cs.cmu.edu> Subject: RE: [Isms] review of draft-ietf-isms-secshell-05.txt Date: Thu, 17 May 2007 18:57:17 -0400 Message-ID: <018801c798d6$b7dff6c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6198162911536B5F9060D117@sirius.fac.cs.cmu.edu> Thread-Index: AceY0kdKhx5lherbTASR99ftVRnl/QAA6yNA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 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: , Errors-To: isms-bounces@lists.ietf.org Thanks for clarifying. Will fix. dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Thursday, May 17, 2007 6:25 PM > To: j.schoenwaelder@jacobs-university.de; David Harrington > Cc: isms@ietf.org; Jeffrey Hutzelman > Subject: Re: [Isms] review of draft-ietf-isms-secshell-05.txt > > > > On Thursday, May 10, 2007 08:10:46 AM +0200 Juergen Schoenwaelder > wrote: > > > On Thu, May 10, 2007 at 01:39:21AM -0400, David Harrington wrote: > > > >> > 06: Page 8: I think we should replace the term "tunnel" with > >> > "channel". > >> From RFC4284: This document describes the SSH > Connection Protocol. > >> It provides > >> interactive login sessions, remote execution of > commands, forwarded > >> TCP/IP connections, and forwarded X11 connections. All of these > >> channels are multiplexed into a single encrypted tunnel." > >> > >> It looks to me like tunnel is the correct choice. > > > > I believe ISMS runs over an SSH channel, not the underlying > encrypted > > tunnel. > > So do I. Note that "channel" has specific technical meaning > in SSH, but > "tunnel" really does not - the text you quote from 4284 uses > the word in a > generic sense. > > -- Jeff > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 18 14:20:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp74N-000654-Ab; Fri, 18 May 2007 14:20:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp74M-00064r-9g for isms@ietf.org; Fri, 18 May 2007 14:20:50 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp74K-0005QP-0L for isms@ietf.org; Fri, 18 May 2007 14:20:50 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l4IIKfId011880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 May 2007 14:20:42 -0400 (EDT) Date: Fri, 18 May 2007 14:20:41 -0400 From: Jeffrey Hutzelman To: j.schoenwaelder@iu-bremen.de, "McDonald, Ira" Subject: Re: [Isms] workinggrouplastcallondraft-ietf-isms-transport-security-model-03 Message-ID: <41C64B79272D6CD8F284014E@sirius.fac.cs.cmu.edu> In-Reply-To: <20070430193606.GB3148@elstar.local> References: <20070430102633.GA2272@elstar.local> <20070430193606.GB3148@elstar.local> Originator-Info: login-token=Mulberry:014YoABEvydXgt1XiFFAgwc3j8Ny9ovnlO/y5pFwo=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 1.1 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: isms@ietf.org, Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Monday, April 30, 2007 09:36:06 PM +0200 Juergen Schoenwaelder wrote: > On Mon, Apr 30, 2007 at 11:01:10AM -0700, McDonald, Ira wrote: > >> To allow failover to something other than local passwords >> based on configured policy to be RFC-conformant, but still >> maximize interoperability, how about adding a SHOULD (rather >> than a MUST) for failover to local passwords (that explains >> how it might be at variance with a legitimate local policy)? > > Why should we standardize local policy? A fallback mechanism to local > passwords might even be a security nightmare if those local passwords > never get changed. > > I am find to discuss fallback mechanisms and the pros and cons of them > but I somehow feel SHOULD or MUST language may go a bit to far. I agree. MUST are SHOULD are for implementors; this is a policy decision. We can give deployment advice, like "if you want to be able to connect to this device when the AAA server is broken or unreachable, don't depend on AAA" (or s/AAA/Kerberos/g), but we should go no further. The right thing to do here really depends on the situation, how important the device is, what authentication methods are in use, and so on. To be clear, I interpret the requirement as stating that the TSM must not be designed such that it only works when AAA or some similar service is available. I believe it would be entirely acceptable to have a security model which sometimes depends on AAA, depending on how it is configured. But this is rather moot, as the TSM does not depends on AAA at all, ever. A secure _transport_ model may depend on AAA, but that is a different question entirely. The SSH transport model document happens to specify basically the same constraints, and again, I believe that it is acceptable to have a transport model which sometimes depends on AAA or another network service, depending on how it is configured. The SSH transport model actually falls into this category; some SSH authentication methods depend on external services (e.g. GSS-krb5), some do not (publickey), and some may or may not, depending on how they are configured (password could use local passwords or AAA or some other mechanism; keyboard-interactive could do any of those or a variety of other things). In the case of a transport model, I happen to think a less stringent rule is appropriate. In particular, I see no problem with secure transport models that _always_ depend on some external network service, as long as we define at least one that can be configured to work in times of network stress. The requirement is that I be able to authenticate to and manage my network devices when the network is broken; it is not that every possible way of authenticating to and managing my devices works when the network is broken. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 18 14:41:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp7OO-0004fz-C7; Fri, 18 May 2007 14:41:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp7OL-0004U6-Bm for isms@ietf.org; Fri, 18 May 2007 14:41:29 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp7OL-0007JC-3g for isms@ietf.org; Fri, 18 May 2007 14:41:29 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l4IIfMij011883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 May 2007 14:41:22 -0400 (EDT) Date: Fri, 18 May 2007 14:41:22 -0400 From: Jeffrey Hutzelman To: "tom.petch" , j.schoenwaelder@iu-bremen.de, David Harrington Subject: Re: [Isms] working group lastcallondraft-ietf-isms-transport-security-model-03 Message-ID: In-Reply-To: <01b501c78b4b$70a02520$0601a8c0@pc6> References: <01e101c78703$a24326f0$0600a8c0@china.huawei.com> <046d01c78939$0fdcd3a0$0600a8c0@china.huawei.com> <20070430104342.GB2272@elstar.local> <01b501c78b4b$70a02520$0601a8c0@pc6> Originator-Info: login-token=Mulberry:01b2/2EtnXa4a7um6Tou0mgQbhLT32o2/c5CR3pe8=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 1.1 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: isms@ietf.org, Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Monday, April 30, 2007 05:53:18 PM +0200 "tom.petch" wrote: >> Since it is difficult to determine concensus with just two opinions, I >> like to ask people to comment on this. The question is: >> >> Shall a parser simply ignore the content of msgSecurityParameters >> or shall it raise an error? >> > Raise an error. As I said before, I think it shows significant mismatch > between sender and receiver and so should have attention drawn to it. > This is security we are talking about. "This is security" is a good argument for careful, reasoned design. It is not an excuse for using knee-jerk paranoia instead. Security design does sometimes require that "unused" fields be set to fixed or predictable values. For example, if two parties will construct and hash a message independently, and then compare the hashes, there must be a canonical encoding. The same applies if some party will decompose and reconstruct a message without being able to recompute the hash. But I don't think either of those is relevant here. It is true that "unused" fields whose contents are ignored can provide opportunities for hash collision attacks. But there is a flip side, which is that such fields can also provide an opportunity to defend against such attacks and/or against cryptanalysis by inserting random confounders. This approach has been used to strengthen X.509 certificates against potential hash collision attacks by issuing certificates with random serial numbers. But again, I don't see much relevance to the current question. The golden rule is a good one, even in security protocol design. Yes, of course one must require that security messages be well-formed and that all of the crypto checks out. However, being too strict about the contents of fields that are only sometimes used can damage extensibility, making it much harder to replace a weak security protocol with a newer, stronger one in a way that can actually be deployed. It strikes me that the language in the -03 draft was good -- it required that msgSecurityParameters be set to a 0-length octet string. That's a requirement on the sender, not the recipient; no requirement was stated that the message be rejected if msgSecurityParameters is non-empty. I believe this is the right approach, as it allows for extensibility if we discover that there actually is a reason we want to convey some parameter to the TSM. I noticed that what was section 3.1 apparently disappeared entirely in -04. What's up with that? -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 18 15:03:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp7k4-0004T4-1D; Fri, 18 May 2007 15:03:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp7k2-0004St-Qf for isms@ietf.org; Fri, 18 May 2007 15:03:54 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp7k2-0001bB-IE for isms@ietf.org; Fri, 18 May 2007 15:03:54 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l4IJ3mEZ011898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 May 2007 15:03:49 -0400 (EDT) Date: Fri, 18 May 2007 15:03:48 -0400 From: Jeffrey Hutzelman To: "tom.petch" , David Harrington Subject: Re: TMSM and Port was Re: [Isms] Question regarding SNMPv3engine-iddiscovery process Message-ID: <6328B76F92A0AE1C0068C68F@sirius.fac.cs.cmu.edu> In-Reply-To: <05bd01c788e7$ff4ce1c0$0601a8c0@pc6> References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> <00b701c77c61$51dda2a0$0601a8c0@pc6><20070412064949.GB7796@elstar.local> <013901c7873b$4025fc80$0601a8c0@pc6> <01f501c7874d$cd22a5e0$0600a8c0@china.huawei.com> <05bd01c788e7$ff4ce1c0$0601a8c0@pc6> Originator-Info: login-token=Mulberry:01Zn4lTtDmmsKyyZ3PmfxVvf3wXHntsp7T81OznP4=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) 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: 8b431ad66d60be2d47c7bfeb879db82c Cc: isms@ietf.org, Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Friday, April 27, 2007 06:19:29 PM +0200 "tom.petch" wrote: > Understand that an implementation can use any port it is configured with > as long as its peer agrees. > > But I think that the text in tmsm 3.1.1 needs amplfying, ie where it says > > " To differentiate a session established for different purposes, such > as a notification session versus a request-response session, an > application can use different securityNames or transport addresses > (e.g., port 161 vs. port 162)." > add something like > "Note that some transport models may be allocated a single well-known > port for all sessions." I don't see the issue here. The number of well-known ports allocated for a given transport model doesn't affect which or how many ports an application can use. OTOH, I don't object to the new language in -08, either, except for the bit about distinguishing between "SNMP traffic" and "notifications". As far as I understand, notifications _are_ SNMP traffic. > (assuming we do not ask for two ports for SSH). I appreciate that the > consensus on the list was reuse or not reuse was not an issue but I worry > that we have this one wrong so want the documents to make this clear for > any other reviewers. FWIW, I don't think we do have this one wrong. While message processing in the SNMP application might be substantially different for notifications vs RR, the processing for TSM, the SSH transport model, and SSH itself will all be substantially the same. It would seem to make much more sense to use different securitynames and/or subsystem ID's. In fact, I wonder if we shouldn't change SnmpSSHAddress to allow an optional [:subsystem-name] after the port number, with the "snmp" subsystem being used when none is given. This would allow multiplexing of different types of traffic and/or different SNMP engines on the same ssh port. > And, while suggesting revisions to tmsm, I wonder if the reference to > RFC4366 should be to RFC4346 throughout. As far as I know, we are not > using any TLS extensions. Well, we're not using TLS at all, but you're right; the reference should be to the base spec. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 18 15:48:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8Qu-0003dk-53; Fri, 18 May 2007 15:48:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8Qs-0003dc-U8 for isms@ietf.org; Fri, 18 May 2007 15:48:10 -0400 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp8Qq-0006jU-NN for isms@ietf.org; Fri, 18 May 2007 15:48:10 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <20070518194807011005tcdce>; Fri, 18 May 2007 19:48:08 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'tom.petch'" , References: <01e101c78703$a24326f0$0600a8c0@china.huawei.com> <046d01c78939$0fdcd3a0$0600a8c0@china.huawei.com> <20070430104342.GB2272@elstar.local> <01b501c78b4b$70a02520$0601a8c0@pc6> Subject: RE: [Isms] working group lastcallondraft-ietf-isms-transport-security-model-03 Date: Fri, 18 May 2007 15:48:03 -0400 Message-ID: <01f901c79985$72804ee0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AceZfCPclrD/9ANSThWmxJReLl0//wABHEfQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.1 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Friday, May 18, 2007 2:41 PM > To: tom.petch; j.schoenwaelder@iu-bremen.de; David Harrington > Cc: isms@ietf.org; Jeffrey Hutzelman > Subject: Re: [Isms] working group > lastcallondraft-ietf-isms-transport-security-model-03 > > > I noticed that what was section 3.1 apparently disappeared > entirely in -04. > What's up with that? > As Bert pointed out, the security model really should be independent of the message processing model. Section 3.1 in -03- talked about the fields in an SNMPv3-specific message format. As stated in the first paragraph of 3.1.1, "To maintain the separation between subsystems, the Transport Security Model does not modify Message Model dependent fields." 3.1.1 "msgFlags" says, in a roundabout way, the TSM compares the securityLevel passed in the ASI to the securityLevel passed in the tmStateReference. It does nothing to the msgFlags field. -04- has text that says this more clearly in section 4.2. 3.1.2 msgSecurityParameters is set to a zero-length OCTET STRING; This is now done in the elements of procedure in 4.3, in a wording that is less message-version-specific. dbh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 18 15:58:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8ao-0002YQ-Jq; Fri, 18 May 2007 15:58:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8ao-0002YG-2K for isms@ietf.org; Fri, 18 May 2007 15:58:26 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp8al-0001hn-QN for isms@ietf.org; Fri, 18 May 2007 15:58:26 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007051819582301300a5tr9e>; Fri, 18 May 2007 19:58:23 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'tom.petch'" References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> <00b701c77c61$51dda2a0$0601a8c0@pc6><20070412064949.GB7796@elstar.local> <013901c7873b$4025fc80$0601a8c0@pc6> <01f501c7874d$cd22a5e0$0600a8c0@china.huawei.com> <05bd01c788e7$ff4ce1c0$0601a8c0@pc6> <6328B76F92A0AE1C0068C68F@sirius.fac.cs.cmu.edu> Subject: RE: TMSM and Port was Re: [Isms] Question regarding SNMPv3engine-iddiscovery process Date: Fri, 18 May 2007 15:58:18 -0400 Message-ID: <020301c79986$e155c330$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6328B76F92A0AE1C0068C68F@sirius.fac.cs.cmu.edu> Thread-Index: AceZf0TyHjHr+lTrSta7OnllCdWs2gABnXwQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Friday, May 18, 2007 3:04 PM > To: tom.petch; David Harrington > Cc: isms@ietf.org; Jeffrey Hutzelman > Subject: Re: TMSM and Port was Re: [Isms] Question regarding > SNMPv3engine-iddiscovery process > > > > On Friday, April 27, 2007 06:19:29 PM +0200 "tom.petch" > wrote: > > > Understand that an implementation can use any port it is > configured with > > as long as its peer agrees. > > > > But I think that the text in tmsm 3.1.1 needs amplfying, ie > where it says > > > > " To differentiate a session established for different > purposes, such > > as a notification session versus a request-response session, an > > application can use different securityNames or transport > addresses > > (e.g., port 161 vs. port 162)." > > add something like > > "Note that some transport models may be allocated a single > well-known > > port for all sessions." > > I don't see the issue here. The number of well-known ports > allocated for a > given transport model doesn't affect which or how many ports > an application > can use. OTOH, I don't object to the new language in -08, > either, except > for the bit about distinguishing between "SNMP traffic" and > "notifications". As far as I understand, notifications _are_ > SNMP traffic. Changed to "SNMP request-response traffic" > > > > (assuming we do not ask for two ports for SSH). I > appreciate that the > > consensus on the list was reuse or not reuse was not an > issue but I worry > > that we have this one wrong so want the documents to make > this clear for > > any other reviewers. > > FWIW, I don't think we do have this one wrong. While message > processing in > the SNMP application might be substantially different for > notifications vs > RR, the processing for TSM, the SSH transport model, and SSH > itself will > all be substantially the same. It would seem to make much > more sense to > use different securitynames and/or subsystem ID's. > > In fact, I wonder if we shouldn't change SnmpSSHAddress to allow an > optional [:subsystem-name] after the port number, with the > "snmp" subsystem > being used when none is given. This would allow multiplexing > of different > types of traffic and/or different SNMP engines on the same ssh port. > Does SSH know how to process that optional field after the port#? Or is this an extension only to the SSH transport model? What should the SSH Transport Model inside an SNMP engine do if presented with [:netconf] or [:X11] or whatever? > > > > And, while suggesting revisions to tmsm, I wonder if the > reference to > > RFC4366 should be to RFC4346 throughout. As far as I know, > we are not > > using any TLS extensions. > > Well, we're not using TLS at all, but you're right; the > reference should be > to the base spec. > > -- Jeff > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 18 16:02:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8eq-0004pf-H0; Fri, 18 May 2007 16:02:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8en-0004pQ-4N for isms@ietf.org; Fri, 18 May 2007 16:02:33 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp8el-0002pY-Tf for isms@ietf.org; Fri, 18 May 2007 16:02:33 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l4IK2ROj011914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 May 2007 16:02:28 -0400 (EDT) Date: Fri, 18 May 2007 16:02:27 -0400 From: Jeffrey Hutzelman To: David Harrington , "'tom.petch'" , j.schoenwaelder@iu-bremen.de Subject: RE: [Isms] working group lastcallondraft-ietf-isms-transport-security-model-03 Message-ID: <81B37CC9145B3EFB64F84B7A@sirius.fac.cs.cmu.edu> In-Reply-To: <01f901c79985$72804ee0$0600a8c0@china.huawei.com> References: <01e101c78703$a24326f0$0600a8c0@china.huawei.com> <046d01c78939$0fdcd3a0$0600a8c0@china.huawei.com> <20070430104342.GB2272@elstar.local> <01b501c78b4b$70a02520$0601a8c0@pc6> <01f901c79985$72804ee0$0600a8c0@china.huawei.com> Originator-Info: login-token=Mulberry:01rs2E9Bg1+Wj6GPx14Uu0Y0U/ux81Af0bQrJZ5E0=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 1.1 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: isms@ietf.org, Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Friday, May 18, 2007 03:48:03 PM -0400 David Harrington wrote: > 3.1.2 msgSecurityParameters is set to a zero-length OCTET STRING; This > is now done in the elements of procedure in 4.3, in a wording that is > less message-version-specific. OK; that looks good. However, I don't think we've resolved the question of whether the test described in 5.2 (2) is appropriate or necessary. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 18 16:12:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8oG-000355-Ji; Fri, 18 May 2007 16:12:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8oF-00034s-MD for isms@ietf.org; Fri, 18 May 2007 16:12:19 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp8oE-0004yh-D1 for isms@ietf.org; Fri, 18 May 2007 16:12:19 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l4IKCDMa011917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 May 2007 16:12:14 -0400 (EDT) Date: Fri, 18 May 2007 16:12:13 -0400 From: Jeffrey Hutzelman To: David Harrington , "'tom.petch'" Subject: RE: TMSM and Port was Re: [Isms] Question regarding SNMPv3engine-iddiscovery process Message-ID: <450809FCECF0B4F4E1695A99@sirius.fac.cs.cmu.edu> In-Reply-To: <020301c79986$e155c330$0600a8c0@china.huawei.com> References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> <00b701c77c61$51dda2a0$0601a8c0@pc6><20070412064949.GB7796@elstar.local> <013901c7873b$4025fc80$0601a8c0@pc6> <01f501c7874d$cd22a5e0$0600a8c0@china.huawei.com> <05bd01c788e7$ff4ce1c0$0601a8c0@pc6> <6328B76F92A0AE1C0068C68F@sirius.fac.cs.cmu.edu> <020301c79986$e155c330$0600a8c0@china.huawei.com> Originator-Info: login-token=Mulberry:01A/Nm0W1b20VPPt5SNnGWQJplnfyKJ99waJQ2OXM=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) 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: 2409bba43e9c8d580670fda8b695204a Cc: isms@ietf.org, Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Friday, May 18, 2007 03:58:18 PM -0400 David Harrington wrote: > Does SSH know how to process that optional field after the port#? > Or is this an extension only to the SSH transport model? No; this would be an extension to the transport model, indicating that SSH should be asked to invoke some other subsystem instead of "snmp". Note that SSH doesn't know anything about this "host:port" thing, either, though there are certainly some SSH _implementations_ that accept a parameter written that way. > What should the SSH Transport Model inside an SNMP engine do if > presented with [:netconf] or [:X11] or whatever? Well, the [] were really just to indicate it's optional; they're not part of the syntax. If presented with a transport address like some.host.com:22:netconf, the SSH transport model should open an ssh connection to port 22 on some.host.com, and ask SSH to invoke the "netconf" subsystem. What happens after that won't be pretty, because the other end isn't speaking SNMP, but it also won't be any worse than if you used some other transport model with the wrong port. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 18 16:49:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp9OK-0006ya-BP; Fri, 18 May 2007 16:49:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp9OJ-0006yQ-Jw for isms@ietf.org; Fri, 18 May 2007 16:49:35 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp9OJ-00031X-D0 for isms@ietf.org; Fri, 18 May 2007 16:49:35 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <200705182049340140058ecae>; Fri, 18 May 2007 20:49:34 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'tom.petch'" , References: <01e101c78703$a24326f0$0600a8c0@china.huawei.com> <046d01c78939$0fdcd3a0$0600a8c0@china.huawei.com> <20070430104342.GB2272@elstar.local> <01b501c78b4b$70a02520$0601a8c0@pc6> Subject: RE: [Isms] working group lastcallondraft-ietf-isms-transport-security-model-03 Date: Fri, 18 May 2007 16:49:31 -0400 Message-ID: <024c01c7998e$095e28c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AceZfCPclrD/9ANSThWmxJReLl0//wADAdng X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.1 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Friday, May 18, 2007 2:41 PM > To: tom.petch; j.schoenwaelder@iu-bremen.de; David Harrington > Cc: isms@ietf.org; Jeffrey Hutzelman > Subject: Re: [Isms] working group > lastcallondraft-ietf-isms-transport-security-model-03 > > > The golden rule is a good one, even in security protocol > design. Yes, of > course one must require that security messages be well-formed > and that all > of the crypto checks out. However, being too strict about > the contents of > fields that are only sometimes used can damage extensibility, > making it > much harder to replace a weak security protocol with a newer, > stronger one > in a way that can actually be deployed. > > > It strikes me that the language in the -03 draft was good -- > it required > that msgSecurityParameters be set to a 0-length octet string. > That's a > requirement on the sender, not the recipient; no requirement > was stated > that the message be rejected if msgSecurityParameters is > non-empty. I > believe this is the right approach, as it allows for > extensibility if we > discover that there actually is a reason we want to convey > some parameter > to the TSM. The Transport Security Model is not being designed to respond to transport-model-specific parameters, only to transport-model-independent parameters. If we decide there is a specific reason to pass something to the TSM in the msgSecurityParameters, then TSM would need to be updated when that need is realized. Without such an update, TSM will not respond to data in that field. Please give a real example of what we might want to pass to the TSM in this field that would be transport-model and message-version independent. We already have a strategy for extensibility; if the data in the field is security mechanism specific, and we would have to update TSM to recognize it, why would that not simply be a different security model, one that did accept **specific** data in that field? How large a buffer should a receiver plan on for the undefined data that might be sent in that OCTET STRING? Should we specify that all recievers MUST be prepared to accept data of the largest possible OCTET STRING size in this field for interoperability reasons? That way all implementations can pay for the possibility that someday, somebody might find a use for putting data in this field that would not be transport-, message- or security-model specific. Call me skeptical. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 18 16:54:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp9TG-0004zv-UT; Fri, 18 May 2007 16:54:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp9TG-0004zq-20 for isms@ietf.org; Fri, 18 May 2007 16:54:42 -0400 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp9TF-0004YP-QW for isms@ietf.org; Fri, 18 May 2007 16:54:42 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <2007051820544101200fl1mie>; Fri, 18 May 2007 20:54:41 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'tom.petch'" References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> <00b701c77c61$51dda2a0$0601a8c0@pc6><20070412064949.GB7796@elstar.local> <013901c7873b$4025fc80$0601a8c0@pc6> <01f501c7874d$cd22a5e0$0600a8c0@china.huawei.com> <05bd01c788e7$ff4ce1c0$0601a8c0@pc6> <6328B76F92A0AE1C0068C68F@sirius.fac.cs.cmu.edu> <020301c79986$e155c330$0600a8c0@china.huawei.com> <450809FCECF0B4F4E1695A99@sirius.fac.cs.cmu.edu> Subject: RE: TMSM and Port was Re: [Isms] Question regarding SNMPv3engine-iddiscovery process Date: Fri, 18 May 2007 16:54:38 -0400 Message-ID: <024d01c7998e$c01ab510$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <450809FCECF0B4F4E1695A99@sirius.fac.cs.cmu.edu> Thread-Index: AceZiNO3EYVAweNMSbeSamlSBG+CzAABPHFw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org I'm afraid I don't see the benefit of this extension. Can you enlighten me? dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Friday, May 18, 2007 4:12 PM > To: David Harrington; 'tom.petch' > Cc: isms@ietf.org; Jeffrey Hutzelman > Subject: RE: TMSM and Port was Re: [Isms] Question regarding > SNMPv3engine-iddiscovery process > > > > On Friday, May 18, 2007 03:58:18 PM -0400 David Harrington > wrote: > > > Does SSH know how to process that optional field after the port#? > > Or is this an extension only to the SSH transport model? > > No; this would be an extension to the transport model, > indicating that SSH > should be asked to invoke some other subsystem instead of > "snmp". Note > that SSH doesn't know anything about this "host:port" thing, > either, though > there are certainly some SSH _implementations_ that accept a > parameter > written that way. > > > > What should the SSH Transport Model inside an SNMP engine do if > > presented with [:netconf] or [:X11] or whatever? > > Well, the [] were really just to indicate it's optional; > they're not part > of the syntax. If presented with a transport address like > some.host.com:22:netconf, the SSH transport model should open an ssh > connection to port 22 on some.host.com, and ask SSH to invoke > the "netconf" > subsystem. What happens after that won't be pretty, because > the other end > isn't speaking SNMP, but it also won't be any worse than if > you used some > other transport model with the wrong port. > > -- Jeff > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 18 17:31:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpA2l-0005cW-4i; Fri, 18 May 2007 17:31:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpA2j-0005bG-Ow for isms@ietf.org; Fri, 18 May 2007 17:31:21 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpA2h-0003kr-Ea for isms@ietf.org; Fri, 18 May 2007 17:31:21 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l4ILVDaM011947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 May 2007 17:31:14 -0400 (EDT) Date: Fri, 18 May 2007 17:31:13 -0400 From: Jeffrey Hutzelman To: David Harrington , "'tom.petch'" , j.schoenwaelder@iu-bremen.de Subject: RE: [Isms] working group lastcallondraft-ietf-isms-transport-security-model-03 Message-ID: <5783141EF2470B2A8BB2AAD5@sirius.fac.cs.cmu.edu> In-Reply-To: <024c01c7998e$095e28c0$0600a8c0@china.huawei.com> References: <01e101c78703$a24326f0$0600a8c0@china.huawei.com> <046d01c78939$0fdcd3a0$0600a8c0@china.huawei.com> <20070430104342.GB2272@elstar.local> <01b501c78b4b$70a02520$0601a8c0@pc6> <024c01c7998e$095e28c0$0600a8c0@china.huawei.com> Originator-Info: login-token=Mulberry:01OfbQvqNeRTKFQUg/bHQALdBoB+nAKkmma/4jb3Y=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 1.1 (+) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: isms@ietf.org, Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Friday, May 18, 2007 04:49:31 PM -0400 David Harrington wrote: > The Transport Security Model is not being designed to respond to > transport-model-specific parameters, only to > transport-model-independent parameters. If we decide there is a > specific reason to pass something to the TSM in the > msgSecurityParameters, then TSM would need to be updated when that > need is realized. Without such an update, TSM will not respond to data > in that field. True... Except that with the EOP as currently written, it _will_ respond by rejecting the message. I suppose that might be desirable, from an extensibility standpoint, except that it's not clear to me that "reject the message" means sending an error, as opposed to simply dropping it on the floor. > Please give a real example of what we might want to pass to the TSM in > this field that would be transport-model and message-version > independent. I haven't a clue. But then, extensibility is about planning for the ability to add things you haven't already thought of. > We already have a strategy for extensibility; if the data > in the field is security mechanism specific, and we would have to > update TSM to recognize it, why would that not simply be a different > security model, one that did accept **specific** data in that field? I suppose one could do that. How does the negotiation work, where I don't know whether the recipient supports a particulaar security model? So far, I don't think that's ever been an issue - the only security model was USM, and everyone supported that. With ISMS, we can more or less assume that everyone still supports USM, and that anything that accepts an SSH connection from us will support TSM, too (assuming we're talking SNMPv3). What happens when a sender using SSH has a choice of TSM or some new thing; how does it tell whether the recipient supports the new thing? > How large a buffer should a receiver plan on for the undefined data > that might be sent in that OCTET STRING? Should we specify that all > recievers MUST be prepared to accept data of the largest possible > OCTET STRING size in this field for interoperability reasons? That way > all implementations can pay for the possibility that someday, somebody > might find a use for putting data in this field that would not be > transport-, message- or security-model specific. Who needs a buffer? If you don't need it, just discard it. But I very much suspect that by the time the TSM gets to decide to reject the message based on this field being non-empty, some other, security-model-independent component has actually parsed the message and had the opportunity to say the field is too long. I guess I don't feel too strongly about this, but why require implementors to do this extra work to check that a field they don't care about is empty, when nothing is gained from doing so? -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 18 17:33:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpA4n-0006iV-DG; Fri, 18 May 2007 17:33:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpA4l-0006iF-W3 for isms@ietf.org; Fri, 18 May 2007 17:33:27 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpA4j-0004nC-88 for isms@ietf.org; Fri, 18 May 2007 17:33:27 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l4ILXL58011950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 May 2007 17:33:21 -0400 (EDT) Date: Fri, 18 May 2007 17:33:21 -0400 From: Jeffrey Hutzelman To: David Harrington , "'tom.petch'" Subject: RE: TMSM and Port was Re: [Isms] Question regarding SNMPv3engine-iddiscovery process Message-ID: <560465D5DCE4E968F0FC3AA7@sirius.fac.cs.cmu.edu> In-Reply-To: <024d01c7998e$c01ab510$0600a8c0@china.huawei.com> References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> <00b701c77c61$51dda2a0$0601a8c0@pc6><20070412064949.GB7796@elstar.local> <013901c7873b$4025fc80$0601a8c0@pc6> <01f501c7874d$cd22a5e0$0600a8c0@china.huawei.com> <05bd01c788e7$ff4ce1c0$0601a8c0@pc6> <6328B76F92A0AE1C0068C68F@sirius.fac.cs.cmu.edu> <020301c79986$e155c330$0600a8c0@china.huawei.com> <450809FCECF0B4F4E1695A99@sirius.fac.cs.cmu.edu> <024d01c7998e$c01ab510$0600a8c0@china.huawei.com> Originator-Info: login-token=Mulberry:01wn5ntCzm3CgOyd819fyXI1nwnt9JsuAv85UZ+P4=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: isms@ietf.org, Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Friday, May 18, 2007 04:54:38 PM -0400 David Harrington wrote: > I'm afraid I don't see the benefit of this extension. Can you > enlighten me? The idea is to allow multiplexing of traffic by SSH subsystem name, rather than by TCP port number. I thought this might be interesting to the people who were concerned about only having one default port. Let's see if anyone else thinks this would be useful; if not, we can just drop it. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 18 18:22:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpApl-00038d-Cp; Fri, 18 May 2007 18:22:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpApk-00038S-BA for isms@ietf.org; Fri, 18 May 2007 18:22:00 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpApi-0003Fs-VF for isms@ietf.org; Fri, 18 May 2007 18:22:00 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=SwcwJuWdzd3O8LGXAViHcpOk2AGDW+BTtM+DwgmGVzXiW+/6Bw8r0BoEcSJ7qTJm; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.136.194] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HpApg-0004Pt-DY for isms@ietf.org; Fri, 18 May 2007 18:21:56 -0400 Message-ID: <002201c7999b$61fb7ac0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <01e101c78703$a24326f0$0600a8c0@china.huawei.com><046d01c78939$0fdcd3a0$0600a8c0@china.huawei.com><20070430104342.GB2272@elstar.local><01b501c78b4b$70a02520$0601a8c0@pc6> <024c01c7998e$095e28c0$0600a8c0@china.huawei.com> Subject: Re: [Isms] workinggroup lastcallondraft-ietf-isms-transport-security-model-03 Date: Fri, 18 May 2007 15:25:03 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882c120543388a5fd78456d3fb9016ec391086d778808b4b50350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.136.194 X-Spam-Score: 1.1 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: , Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David Harrington" > To: "'Jeffrey Hutzelman'" ; "'tom.petch'" ; > Cc: > Sent: Friday, May 18, 2007 1:49 PM > Subject: RE: [Isms] workinggroup lastcallondraft-ietf-isms-transport-security-model-03 ... > How large a buffer should a receiver plan on for the undefined data > that might be sent in that OCTET STRING? Should we specify that all > recievers MUST be prepared to accept data of the largest possible > OCTET STRING size in this field for interoperability reasons? That way > all implementations can pay for the possibility that someday, somebody > might find a use for putting data in this field that would not be > transport-, message- or security-model specific. Any robust implementation has to be able to cope with the possibility that unexpectedly large elements (and not just OCTET STRINGs) might show up on the wire. Anywhere. I agree that zero-length should be specified for the sender. I'm agnostic on whether the recipient should care, but inclined to favor the "ignore it" camp. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun May 20 15:21:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpqyB-0003QY-SR; Sun, 20 May 2007 15:21:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpqyA-0003OR-L6 for isms@ietf.org; Sun, 20 May 2007 15:21:30 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hpqy9-0002WE-79 for isms@ietf.org; Sun, 20 May 2007 15:21:30 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A7008284A; Sun, 20 May 2007 21:21:28 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 24465-04; Sun, 20 May 2007 21:21:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 619C482715; Sun, 20 May 2007 21:21:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4A694262151; Sun, 20 May 2007 21:21:22 +0200 (CEST) Date: Sun, 20 May 2007 21:21:22 +0200 From: Juergen Schoenwaelder To: "tom.petch" Subject: Re: [Isms] draft-ietf-isms-tmsm-08.txt Message-ID: <20070520192122.GB26568@elstar.local> Mail-Followup-To: "tom.petch" , David Harrington , isms@ietf.org References: <033d01c792c5$9154b9d0$0600a8c0@china.huawei.com> <000401c793e7$a5677de0$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000401c793e7$a5677de0$0601a8c0@pc6> User-Agent: Mutt/1.5.15 (2007-04-06) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Fri, May 11, 2007 at 06:11:38PM +0200, tom.petch wrote: > I have a concern with this I-D that it is blurring the meaning of > authentication As per RFC2828, there is data origin authentication > and peer entity authentication. Read the secure session RFC, such > as SSH and TLS, and they are clear that they offer peer entity > authentication.and not data origin authentication. This I-D, like > the RFC341? series, seems to be written as if there were only data > origin authentication, as if authentication was a security function > that will applied to an isolated message, as opposed to occurring > only in the context of an association. Rather, with Transport > Security, the message cannot be authenticated; it came over a pipe > from a peer which was authenticated some time in the past and the > authentication depends on the continued existence of that pipe. In > security terms, I see the difference as significant and one that > this I-D should call out. Good point. However, I have the feeling that the SNMPv3 specifications have never been very consistent about this as they generally promise data origin authentication but I think data origin authentication is not what is actually delivered in the case of proxies. Do you agree with me here? Still, we can do better and should get the text straight. If you have concrete proposals how to change the wording in the affected sections, I am sure Dave will be more than happy to pick them up. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun May 20 16:02:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hprc8-0004Zy-8l; Sun, 20 May 2007 16:02:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hprc6-0004Zt-Oy for isms@ietf.org; Sun, 20 May 2007 16:02:46 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hprc5-00033K-CN for isms@ietf.org; Sun, 20 May 2007 16:02:46 -0400 Received: from pc6 (1Cust226.tnt30.lnd3.gbr.da.uu.net [62.188.122.226]) by blaster.systems.pipex.net (Postfix) with SMTP id EDE1DE0003B9; Sun, 20 May 2007 21:02:42 +0100 (BST) Message-ID: <000301c79b10$ec03c300$0601a8c0@pc6> From: "tom.petch" To: "Jeffrey Hutzelman" , "David Harrington" References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> <00b701c77c61$51dda2a0$0601a8c0@pc6><20070412064949.GB7796@elstar.local> <013901c7873b$4025fc80$0601a8c0@pc6> <01f501c7874d$cd22a5e0$0600a8c0@china.huawei.com> <05bd01c788e7$ff4ce1c0$0601a8c0@pc6> <6328B76F92A0AE1C0068C68F@sirius.fac.cs.cmu.edu> <020301c79986$e155c330$0600a8c0@china.huawei.com> <450809FCECF0B4F4E1695A99@sirius.fac.cs.cmu.edu> <024d01c7998e$c01ab510$0600a8c0@china.huawei.com> <560465D5DCE4E968F0FC3AA7@sirius.fac.cs.cmu.edu> Subject: Re: TMSM and Port was Re: [Isms] Question regarding SNMPv3engine-iddiscovery process Date: Sat, 19 May 2007 20:45:43 +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.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: , Errors-To: isms-bounces@lists.ietf.org I am one of those who has been concerned about telling traffic apart. I see it at present with NATs, where I do see different treatment for ports 161 and 162 and can envisage it for a secure transport where users may wish to give different levels of security for different types of traffic. Different subsystems would give part of this. So if TMSM takes this away, then I would like this to be clearly spelt out so others are aware and can comment. SNMP, for me, has a habit of burying bad news in some obscure combination of paragraphs whose impact is not apparent until too late:-{ Tom Petch ----- Original Message ----- From: "Jeffrey Hutzelman" To: "David Harrington" ; "'tom.petch'" Cc: ; "Jeffrey Hutzelman" Sent: Friday, May 18, 2007 11:33 PM Subject: RE: TMSM and Port was Re: [Isms] Question regarding SNMPv3engine-iddiscovery process > > > On Friday, May 18, 2007 04:54:38 PM -0400 David Harrington > wrote: > > > I'm afraid I don't see the benefit of this extension. Can you > > enlighten me? > > The idea is to allow multiplexing of traffic by SSH subsystem name, rather > than by TCP port number. I thought this might be interesting to the people > who were concerned about only having one default port. Let's see if anyone > else thinks this would be useful; if not, we can just drop it. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 21 05:09:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq3tp-0004CQ-5K; Mon, 21 May 2007 05:09:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq3tn-0004CL-JI for isms@ietf.org; Mon, 21 May 2007 05:09:51 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq3tm-0002GE-4m for isms@ietf.org; Mon, 21 May 2007 05:09:51 -0400 Received: from pc6 (1Cust160.tnt16.lnd4.gbr.da.uu.net [62.188.145.160]) by astro.systems.pipex.net (Postfix) with SMTP id A2F0FE000532; Mon, 21 May 2007 10:09:45 +0100 (BST) Message-ID: <005601c79b7e$df8d1c20$0601a8c0@pc6> From: "tom.petch" To: References: <033d01c792c5$9154b9d0$0600a8c0@china.huawei.com> <000401c793e7$a5677de0$0601a8c0@pc6> <20070520192122.GB26568@elstar.local> Subject: Re: [Isms] draft-ietf-isms-tmsm-08.txt Date: Mon, 21 May 2007 09:57:51 +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.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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: , Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "tom.petch" Cc: "David Harrington" ; Sent: Sunday, May 20, 2007 9:21 PM Subject: Re: [Isms] draft-ietf-isms-tmsm-08.txt > On Fri, May 11, 2007 at 06:11:38PM +0200, tom.petch wrote: > > > I have a concern with this I-D that it is blurring the meaning of > > authentication As per RFC2828, there is data origin authentication > > and peer entity authentication. Read the secure session RFC, such > > as SSH and TLS, and they are clear that they offer peer entity > > authentication.and not data origin authentication. This I-D, like > > the RFC341? series, seems to be written as if there were only data > > origin authentication, as if authentication was a security function > > that will applied to an isolated message, as opposed to occurring > > only in the context of an association. Rather, with Transport > > Security, the message cannot be authenticated; it came over a pipe > > from a peer which was authenticated some time in the past and the > > authentication depends on the continued existence of that pipe. In > > security terms, I see the difference as significant and one that > > this I-D should call out. > > Good point. However, I have the feeling that the SNMPv3 specifications > have never been very consistent about this as they generally promise > data origin authentication but I think data origin authentication is > not what is actually delivered in the case of proxies. Do you agree > with me here? > Yes, I am not sure how I would classify the authentication delivered by proxies:-) My main line of thought is to insert a section such as the following - my style is a little different to yours and those with a greater knowledge of security than I may want to tweak the terminology - before the existing 3.3.3 =========================================== There are two types of authentication, data origin authentication and peer entity authentication [RFC2828/draft-shirey-secgloss]. In the former, each message is individually authenticated using the security credentials. This technique is used in SMTP [RFC3851] and in USM [RFC3414]; in fact, parts of the specification of SNMP is written as if this were the only type of authentication [RFC3411, RFC3412]. With peer entity authentication, the identity of a peer is authenticated, a secure tunnel (channel, session) is set up with that peer and keying materials are created for use with that tunnel. Individual messages may be encrypted or integrity checked but are not authenticated. Rather, authentication depends on the fact that the message arrived over the secure tunnel the endpoint of which was authenticated when the tunnel was set up, which may be a long time ago. This approach is used by SSH [RFC4251] and TLS[RFC4346] and so by applications such as HTTPS [RFC2818] and NETCONF [RFC4742]. The use of transport security by SNMP brings the use of peer entity authentication and so the wording used by previous documents must be interpreted in that light. A Transport Security Model using SSH or TLS may be able to check that the tunnel over which a message arrived is known and so that the peer has been authenticated but cannot meaningfully be said to authenticate an individual message. Rather, authentication depends on the procedures followed when the tunnel was created. ================================================= In 3.2.1.2, I would put 'authenticate' in quotes with a cross reference to the above. In 3.2.3, I would add to the second paragraph a parenthetic comment 'The different types of authentication are describe in ' with a cross reference to the above. In 3.3.3, I would change "authentication, integrity checking, and encryption services for data" "integrity checking, encryption and, perhaps, authentication for data". (After all, the key exchange could derive a key that is used to authenticate individual messages in addition to the peer entity authentication although I know of no current system that does so). Also, in 3.2.1.3, I would change "establish an authenticated and/or encrypted tunnel between the Transport Models" to disallow encrypted unauthenticated which the use of and/or currently permits. At which point I would re-read the document to see how it all hangs together. Tom Petch > Still, we can do better and should get the text straight. If you have > concrete proposals how to change the wording in the affected sections, > I am sure Dave will be more than happy to pick them up. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 21 19:25:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqHGC-0008Lk-6c; Mon, 21 May 2007 19:25:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqHGB-0008Lf-Cv for isms@ietf.org; Mon, 21 May 2007 19:25:51 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqHGA-0001Mv-5C for isms@ietf.org; Mon, 21 May 2007 19:25:51 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l4LNPcnp013780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 May 2007 19:25:39 -0400 (EDT) Date: Mon, 21 May 2007 19:25:38 -0400 From: Jeffrey Hutzelman To: "tom.petch" , David Harrington Subject: Re: TMSM and Port was Re: [Isms] Question regarding SNMPv3engine-iddiscovery process Message-ID: <007D222EF1AF82245869D348@sirius.fac.cs.cmu.edu> In-Reply-To: <000301c79b10$ec03c300$0601a8c0@pc6> References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> <00b701c77c61$51dda2a0$0601a8c0@pc6><20070412064949.GB7796@elstar.local> <013901c7873b$4025fc80$0601a8c0@pc6> <01f501c7874d$cd22a5e0$0600a8c0@china.huawei.com> <05bd01c788e7$ff4ce1c0$0601a8c0@pc6> <6328B76F92A0AE1C0068C68F@sirius.fac.cs.cmu.edu> <020301c79986$e155c330$0600a8c0@china.huawei.com> <450809FCECF0B4F4E1695A99@sirius.fac.cs.cmu.edu> <024d01c7998e$c01ab510$0600a8c0@china.huawei.com> <560465D5DCE4E968F0FC3AA7@sirius.fac.cs.cmu.edu> <000301c79b10$ec03c300$0601a8c0@pc6> Originator-Info: login-token=Mulberry:01N68TcqEXiOaD+ovzai1D4c4hSp2+44ykJEHXbS8=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) 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: 9466e0365fc95844abaf7c3f15a05c7d Cc: isms@ietf.org, Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Saturday, May 19, 2007 08:45:43 PM +0200 "tom.petch" wrote: > I am one of those who has been concerned about telling traffic apart. I > see it at present with NATs, where I do see different treatment for ports > 161 and 162 and can envisage it for a secure transport where users may > wish to give different levels of security for different types of traffic. > > Different subsystems would give part of this. Yes, but note that subsystem requests happen inside the authenticated, encrypted SSH connection, and so cannot be inspected by NAT's, firewalls, etc. They also happen too late to allow choice of subsystem to influence things like ports. If you have an ISMS deployment where you want to require stronger ciphers for certain types of requests, then running a separate SSH server on a different port is still your best bet. > So if TMSM takes this away, then I would like this to be clearly spelt > out so others are aware and can comment. SNMP, for me, has a habit of > burying bad news in some obscure combination of paragraphs whose impact > is not apparent until too late:-{ I don't see anything in TSM, TMSM (ugh this needs a new name), or the SSH transport mapping which would eliminate the ability to use arbitrary ports. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms