From isms-bounces@lists.ietf.org Tue Jan 02 15:50:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1qaI-0004dY-9a; Tue, 02 Jan 2007 15:50:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1qaA-0004Dt-Dp; Tue, 02 Jan 2007 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1qaA-0002Sr-5i; Tue, 02 Jan 2007 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 247403292A; Tue, 2 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H1qa9-0002mX-W6; Tue, 02 Jan 2007 15:50:01 -0500 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, 02 Jan 2007 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-transport-security-model-01.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-01.txt Pages : 29 Date : 2007-1-2 This memo describes a Transport Security Model for the Simple Network Management Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-transport-security-model-01.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-01.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-01.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-1-2113237.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-transport-security-model-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-transport-security-model-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-2113237.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 Wed Jan 03 21:01:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HvQ-0004Xq-Q6; Wed, 03 Jan 2007 21:01:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HvP-0004Xl-Ex for isms@ietf.org; Wed, 03 Jan 2007 21:01:47 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2HvF-0003kU-J7 for isms@ietf.org; Wed, 03 Jan 2007 21:01:47 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBB0099TMTDY2@szxga02-in.huawei.com> for isms@ietf.org; Thu, 04 Jan 2007 09:58:25 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JBB00MO1MTCY5@szxga02-in.huawei.com> for isms@ietf.org; Thu, 04 Jan 2007 09:58:25 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JBB007C0MT8L0@szxml04-in.huawei.com> for isms@ietf.org; Thu, 04 Jan 2007 09:58:24 +0800 (CST) Date: Thu, 04 Jan 2007 09:58:20 +0800 From: Miao Fuyou Subject: RE: [Isms] discovery In-reply-to: <197a01c729f2$724ad600$0600a8c0@china.huawei.com> To: 'David Harrington' , j.schoenwaelder@iu-bremen.de, isms@ietf.org Message-id: <01ce01c72fa3$cf75b140$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Accl6KnohSZvVJIwT5WlDT4y0/sDsQJuT+Tg X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Is the discovery mechanism security-model-agnostic, or specific to a model, such as sshsm? If it is specific to sshsm, host key of the managed device may be the piece of data to be discovered. The SSH specification says the host key is delivered out of band, it will be convenient for deployment if it can be discovered. Thanks, Miao > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Thursday, December 28, 2006 4:06 AM > To: j.schoenwaelder@iu-bremen.de; isms@ietf.org > Subject: [Isms] discovery > > Hi, > > I recommend standardizing the discovery mechanisms to include > three pieces of data - contextengineID, sysDescriptor, and > sysObjectID. > Those three items identify the SNMP entity. > > Naming the variables that can be returned by a compliant > implementation of this mechanism allows us to discuss the > security considerations of the data revealed. Leaving it to > the implementation to allow any data in the request/response > makes it pretty much impossble to describe the security > implications of the discovery mechanism. > > It could be argued that additional system objects could be > included in the discovery, and we can discuss the security > implications of including those in the request. > > 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 > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jan 04 02:43:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2NG0-0007Sc-P7; Thu, 04 Jan 2007 02:43:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2NFy-0007SV-C2 for isms@ietf.org; Thu, 04 Jan 2007 02:43:22 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2NFw-0004qw-1s for isms@ietf.org; Thu, 04 Jan 2007 02:43:22 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 2D4695919E; Thu, 4 Jan 2007 08:43:17 +0100 (CET) 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 13641-03; Thu, 4 Jan 2007 08:43:14 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 07DEA4D33D; Thu, 4 Jan 2007 08:43:14 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 9EAC790D248; Thu, 4 Jan 2007 08:43:11 +0100 (CET) Date: Thu, 4 Jan 2007 08:43:10 +0100 From: Juergen Schoenwaelder To: Miao Fuyou Subject: Re: [Isms] discovery Message-ID: <20070104074310.GA6362@noname> Mail-Followup-To: Miao Fuyou , 'David Harrington' , isms@ietf.org References: <197a01c729f2$724ad600$0600a8c0@china.huawei.com> <01ce01c72fa3$cf75b140$800c6f0a@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01ce01c72fa3$cf75b140$800c6f0a@china.huawei.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 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 Thu, Jan 04, 2007 at 09:58:20AM +0800, Miao Fuyou wrote: > Is the discovery mechanism security-model-agnostic, or specific to a model, > such as sshsm? > > If it is specific to sshsm, host key of the managed device may be the piece > of data to be discovered. The SSH specification says the host key is > delivered out of band, it will be convenient for deployment if it can be > discovered. The introduction of says: This document introduces a discovery mechanism which can be used to learn the engine identifier of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may be used also by other protocol interfaces to discover the engine identifier. So yes, the intention is to be security model agnostic. And the intention is to just focus on engineid discovery. If you believe something specific should be done for SSH host keys, then is probably the document to look at. /js -- Juergen Schoenwaelder {International|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 From isms-bounces@lists.ietf.org Thu Jan 04 02:43:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2NGU-0007lm-Bl; Thu, 04 Jan 2007 02:43:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2NGS-0007kf-VA for isms@ietf.org; Thu, 04 Jan 2007 02:43:52 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2NGR-000507-KX for isms@ietf.org; Thu, 04 Jan 2007 02:43:52 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 34AFC59727 for ; Thu, 4 Jan 2007 08:43:51 +0100 (CET) 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 13630-04; Thu, 4 Jan 2007 08:43:48 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 1D18A4D33D; Thu, 4 Jan 2007 08:43:48 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 1B13090D256; Thu, 4 Jan 2007 08:43:47 +0100 (CET) Date: Thu, 4 Jan 2007 08:43:47 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Subject: Re: [Isms] working group last call on draft-ietf-isms-tmsm-05 Message-ID: <20070104074347.GB6362@noname> Mail-Followup-To: isms@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: 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 Fri, Dec 15, 2006 at 04:03:00PM +0100, Juergen Quittek wrote: > Dear all, > > This is the working group last call on the "Transport Subsystem for > the Simple Network Management Protocol (SNMP)" to be found at > . > > The authors and the chairs think that this document is mature enough > for last call. Since the holidays are coming, the last call period is > not two weeks as usual, but three weeks. > > Please do review the document and post your comments on this list until > January 8, 2007. Please also post to the list if you have read the document > and are fine with it. It is very useful to know how many people have read > the document. I like to remind you that we have a last call running. Please read and send us your comments or at least an indication that you read the document and have no specific comments. Thanks, /js -- Juergen Schoenwaelder {International|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 From isms-bounces@lists.ietf.org Mon Jan 08 08:18:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3uOX-00063u-QD; Mon, 08 Jan 2007 08:18:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3uOW-00063m-H9 for isms@ietf.org; Mon, 08 Jan 2007 08:18:32 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3uOV-00083m-7l for isms@ietf.org; Mon, 08 Jan 2007 08:18:32 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l08DITvJ022814 for ; Mon, 8 Jan 2007 08:18:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] working group last call on draft-ietf-isms-tmsm-05 Date: Mon, 8 Jan 2007 15:18:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] working group last call on draft-ietf-isms-tmsm-05 Thread-Index: AccgWnxKNhOsbavlRqaphYEEPQRAKASy9Xgw From: "Romascanu, Dan \(Dan\)" To: "Juergen Quittek" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 read the document and I am fine with it. Detail level comments follow below.=20 It is not clear to me how the document will progress relative to 3411 and the full STD0062 package. I am not sure that the resolution to this question needs to be found in the text of the document though. Expect questions and discussions in IETF LC and IESG review though.=20 Detail level comments: 1. The readability of the document could be much improved if the references to 3411 will be more exact, quoting the section where a referred diagram, paragraph or statement quoted or reproduced here is taken from.=20 2. I found many instances of inconsistent use of 2119 conventions - some examples may be found in 3.1.1, 3.2.2.2, 3.3.1 3. I believe that Appendix B or some derivative of it includes useful information about the rationale of some of the major design decisions and I would suggest to keep it.=20 4. If Appendix C remains with void content I would suggest to take it out.=20 Regards, Dan =20 =20 > -----Original Message----- > From: Juergen Quittek [mailto:quittek@netlab.nec.de]=20 > Sent: Friday, December 15, 2006 5:03 PM > To: isms@ietf.org > Subject: [Isms] working group last call on draft-ietf-isms-tmsm-05 >=20 > Dear all, >=20 > This is the working group last call on the "Transport=20 > Subsystem for the Simple Network Management Protocol (SNMP)"=20 > to be found at=20 > . >=20 > The authors and the chairs think that this document is mature=20 > enough for last call. Since the holidays are coming, the=20 > last call period is not two weeks as usual, but three weeks. >=20 > Please do review the document and post your comments on this=20 > list until January 8, 2007. Please also post to the list if=20 > you have read the document and are fine with it. It is very=20 > useful to know how many people have read the document. >=20 > Thanks, >=20 > Juergen Q. > --=20 > Juergen Quittek quittek@netlab.nec.de Tel: +49=20 > 6221 4342-115 > NEC Europe Ltd., Network Laboratories Fax: +49=20 > 6221 4342-155 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany =20 > http://www.netlab.nec.de >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jan 08 10:49:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wkw-0001Rj-NV; Mon, 08 Jan 2007 10:49:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wkv-0001Rc-J0 for isms@ietf.org; Mon, 08 Jan 2007 10:49:49 -0500 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3wkq-0006Q9-9h for isms@ietf.org; Mon, 08 Jan 2007 10:49:49 -0500 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe2.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 10:49:40 -0500 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 last call on draft-ietf-isms-tmsm-05 Date: Mon, 8 Jan 2007 10:49:41 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565605A4A31@MABOSEVS2.ets.enterasys.com> In-Reply-To: <20070104074347.GB6362@noname> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] working group last call on draft-ietf-isms-tmsm-05 Thread-Index: Accv1By9+Yf+b5gSSBibVcj01ck1vADZpvMg From: "Nelson, David" To: X-OriginalArrivalTime: 08 Jan 2007 15:49:40.0644 (UTC) FILETIME=[9BB08640:01C7333C] X-imss-version: 2.045 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 have read this document and think that it's in pretty good shape. Some specific comments follow: Document Header: Will this document update existing RFCs, e.g. 3411 or 3417? There is no "Updates:" field in the header. Section 2. I would drop the metaphor of the "gun". The metaphor of the "guard" is fine without the resort to firearms. Just a "political correctness" nit. I think it would help to further elaborate the relationship of this document to RFC 3411 (Architecture) and 3417 (Transport Mappings). Section 3.1.1 In the last sentence, since there are three alternatives listed, I don't think the correct wording is "either". Section 3.2.1 Could paragraphs 3 - 6 be eliminated? This seems to be reviewing design issues/choices for SNMPv3 that one would assume to be documented elsewhere. In paragraph 8, motivation is spelled wrong. Section 3.2.1.2 Typo in bullet item 2). Superfluous asterisk. Section 3.2.3 In paragraph 6, "to have an security" should be "to have a security". Section 4 This section indicates that the diagrams are incomplete. That would seem to be a "comment magnet" in the absence of an explanation of why the incompleteness of the diagrams does not impact the completeness of the document. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jan 09 01:18:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4AJZ-0005DN-SO; Tue, 09 Jan 2007 01:18:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4AJY-0005DE-8x for isms@ietf.org; Tue, 09 Jan 2007 01:18:28 -0500 Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4AJX-00023s-7R for isms@ietf.org; Tue, 09 Jan 2007 01:18:28 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 7C9C811D6CA; Mon, 8 Jan 2007 22:17:53 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Mon, 08 Jan 2007 22:17:53 -0800 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 441f623df000f14368137198649cb083 Cc: Subject: [Isms] tmsm comments X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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 There was no timezone specified in the call for comments, so I'm going to assume that midnight my time is appropriate. Thus, these are 1 hour and 45 minutes early! In general, I think the document is fine. I do have various comments and one major objection and one major concern. The one marked with ***s I think is a show stopper. The one marked with ###s is a "bad thing" but I won't be obnoxious about it. Architecture of newly created "layer" not clearly spelled out up front? I guess I'd like to see the diagram in 3.2.1 higher in the doc. ----- It is possible but difficult to define external mechanisms that handle the distribution of keys for use by the USM approach. It's been done a number of times (the DH MIB proves it's possible and has been used), but is still not the point... Bootstrapping USM was not the issue operators wanted solved. They didn't want a coupled or bootstrapable user base, they wanted a single one that wasn't specific to SNMP. ----- From an operational perspective, it is highly desirable to use security mechanisms that can unify the administrative security management for SNMPv3, command line interfaces (CLIs) and other management interfaces. The use of security services provided by lower layers is the approach commonly used for the CLI, and is also the approach being proposed for NETCONF [I-D.ietf-netconf-ssh]. This document describes a Transport Subsystem extension to the RFC3411 architecture. A transition sentence between those 2 paragraphs would be nice. Maybe end the second one with: This document describes a Transport Subsystem extension to the RFC3411 architecture. This extension specifies how other lower layer protocols with common security infrastructures can be used underneath the SNMP protocol and the desired goal of unified administrative security can be met. [I just like saying "unified administrative security".] ----- +-------------------------------------------------------------------+ | SNMP entity | | | | +-------------------------------------------------------------+ | ... That diagram needs an introduction to it. Like: The "Transport Subsystem" is defined in RFC3411 as a component of the SNMP Engine. The following diagram depicts its place in the SNMP architecture framework: ----- According to [RFC3411], it is not required to protect against denial of service or traffic analysis. Can we change it to: "it is not required to protect against denial of service or traffic analysis, but it should not make those threats significantly worse". ----- It has been a long-standing requirement that SNMP be able to work when the network is unstable, to enable network troubleshooting and repair. The UDP approach has been considered to meet that need well, with an assumption that getting small messages through, even if out of order, is better than getting no messages through. There has been a long debate about whether UDP actually offers better support than TCP when the underlying IP or lower layers are unstable. There has been recent discussion of whether operators actually use SNMP to troubleshoot and repair unstable networks. There has been discussion of ways SNMP could be extended to better support management/monitoring needs when a network is running just fine. Use of a TCP transport, for example, could enable larger message sizes and more efficient table retrievals. These two paragraphs seem out of place? The text, though interesting and potentially informative, don't connect with anything else nearby. I suspect a point needs to be made after them along the lines of: "This document does not try to argue one way or another about which protocols are better for use in which situations as there is very little technical data upon which to draw conclusions from." ----- Transport models MUST be able to coexist with other transport models, and may be designed to utilize either TCP or UDP or SCTP. Or any other future protocol layer? ----- IETF standards typically require one mandatory to implement solution, with the capability of adding new mechanisms in the future. Part of the motivstion of developing transport models is to develop support for secure transport protocols, such as a transport model that utilizes the Secure Shell protocol. Any transport model should define one minimum-compliance security mechanism, preferably one which is already widely used to secure the transport layer protocol. That last sentence is a bit odd. EG, if the UDP transport document was written today would it state that USM is the mandatory to implement security model for use if SNMP/UDP was implemented? It's hard to tell what you're getting at here. Or would the SSH transport, which you talk about below, specify that SSH is mandatory to implement? Or would the SSH transport indicate that a particular set of auth/priv algs be mandatory? Not sure which level of requirement you're talking about ("security mechanism" is vague). ----- The RFC3411 architecture,and the USM assume that a security model is ^ needs space ----- To accommodate this, the ASIs for the transport subsystem, the messaging subsystem, and the security subsystem will be extended to pass security-model- independent values, and a cache of transport-specific information. Based on the above text, the following diagram seems out of place. Add another paragraph stating: The following diagram depicts the complete SNMPv3 architecture including the Transport Subsystem defined in this document: Then the diagram also has "*"s under the MP and Security subsystems. Not sure why? They're not talked about. ----- 3.2.1.1. USM and the RFC3411 Architecture The following diagrams illustrate the difference in the security ^^^^^^^^ processing done by the USM model and the security processing potentially done by a transport model. there isn't any "following diagrams". Maybe you mean "lists" Actually, that paragraph may be long in the 3.2.1 section heading instead? ----- 3.2.1.1 - 3.2.1.3: new lines are needed before the first numbered bullet in each of these sections. ----- A secure transport model will establish an encrypted tunnel between the transport models of two SNMP engines. One transport model instance encrypts all messages, and the other transport model instance decrypts the messages. -> "...will establish an authenticated and/or encrypted tunnel between..." (encryption isn't required) And the last sentence should be deleted. It implies unidirectional and it's not really needed so I'd delete instead of fixing it. I'd be tempted to use "session" instead of tunnel. Only because many people read "tunnel" and think "encryption" (though tunnels can be authenticating only) ----- 3.2.2.1. securityName Binding For SNMP access control to function properly, security processing must establish a securityModel identifier, a securityLevel, and a securityName, which is the security model independent identifier for a principal. The message processing subsystem relies on a security model, such as USM, to play a role in security that goes beyond protecting the message - it provides a mapping between the USM- specific principal to a security-model independent securityName which can be used for subsequent processing, such as for access control. Can we remove USM from that paragraph? The first is probably fine as an example, but the second should be replaced with "Security Model". ----- For outgoing messages, even when a secure transport model will provide the security services, it is necessary to have an security model because it is the security model that actually creates the message from its component parts. Whether there are any security services provided by the security model for an outgoing message is model-dependent. Shouldn't it be mentioned that care MUST be taken to ensure that a SNMP engine is sending packets out over a transport using credentials that are legal for that engine to use on behalf of that user? I worry about the case where an engine has multiple transports open and is "tricked" into sending a message through the wrong transport. ----- ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### It is important to note that the architecture described in [RFC3411] does not include a session selector in the Abstract Service Interfaces, and neither is that done for the transport subsystem, so an SNMP application cannot select the session except by passing a unique combination of transport type, transport address, securityName, securityModel, and securityLevel. PLEASE don't talk about how restricted the architecture is due to the parameters the ASI have available to them. The SNMPv3 working group fought this battle over whether or not to include them and decided that parameters should be include but are not binding and shouldn't be treated as an API or a fixed list of things to pass around. Your statement above only solidifies the "bad" aspects of the ASIs. You can continue to provide the list of what an application must provide to the lower layer systems, but please don't say "so an SNMP application cannot..." because it can if it treats the ASIs as they were intended. ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### ----- *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Responses are expected to be returned using the same session that carried the corresponding request message. Reuse of sessions is not required for conformance. Um... IMHO, this should be a MUST. There are security implications if you send a response over a different session than the request came in over. Different sessions may use different cryptographic properties (algorithms, etc). Plus, once you start doing that you can actually play with the timing of messages as they arrive at the other end by slowing one session down and not the other, etc. This, IMHO, is critical that responses go back on the same session. *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ----- If each session uses new session keys, then messages cannot be replayed from one session to another. Can you be more specific about what you're trying to say there? Does that mean that if I have a GET operation that tries one session and fails to get a response I have to do what exactly before I'm allowed to resend it on another session? is changing the message ID sufficient? This is actually a good thing, don't get me wrong, I'm just trying to understand it. Cryptographically resending the exact same message in another session under a different key does provide some extra comparison information to an attacker. But the text doesn't really state the real goals and requirements here. [though SNMP messages already suffer from fairly regular bytes that fall into the block size of the algorithms being used so I'm not sure you're actually protecting against that much analysis by blocking a resend] ----- SNMPv3 was designed to support multiple levels of security, selectable on a per-message basis by an SNMP application, because there is not much value in using encryption for a Commander Generator to poll for non-sensitive performance data on thousands of interfaces ^ ^ add "potentially" ----- 4.2. Command Responder This diagram shows how a Command Responder or Notification Receiver application registers for handling a pduType, how a PDU is dispatched to the application after an SNMP message is received, and how the Response is (asynchronously) send back to the network. Is this the diagram that was changed (4.1 says it was taken from the other, so I'm assuming it was this one)? If so then you should state how it was changed. ----- 5.2. tmStateReference For each message or transport session, information about the message security is stored in a cache, which may inlcude model- and ^^^^^^^ [I didn't do a spell check and generally don't consider myself worthy to point out grammar issues, but this jumped out at me :-] ----- and if state information is available when a session is closed, the session state information should also be released. Unless the management system indicates that the state should remain around for a longer period of time to allow for data collection about the session to occur. See David Perkins for details. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jan 09 04:30:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4DIy-0003MT-NN; Tue, 09 Jan 2007 04:30:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4DIw-0003MC-QU for isms@ietf.org; Tue, 09 Jan 2007 04:30:02 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4DIu-0003nL-Da for isms@ietf.org; Tue, 09 Jan 2007 04:30:02 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 5FE3B59737 for ; Tue, 9 Jan 2007 10:29:55 +0100 (CET) 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 15083-03; Tue, 9 Jan 2007 10:29:52 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 4EF0757AC7; Tue, 9 Jan 2007 10:28:19 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 9BABC961AA2; Tue, 9 Jan 2007 10:28:17 +0100 (CET) Date: Tue, 9 Jan 2007 10:28:17 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Subject: Re: [Isms] working group last call on draft-ietf-isms-tmsm-05 Message-ID: <20070109092817.GA4299@boskop.local> Mail-Followup-To: isms@ietf.org References: <20070104074347.GB6362@noname> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070104074347.GB6362@noname> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 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 Thu, Jan 04, 2007 at 08:43:47AM +0100, Juergen Schoenwaelder wrote: > I like to remind you that we have a last call running. Please read > and send us your comments or at least an > indication that you read the document and have no specific comments. As originally announced, the WG last call for this document did end yesterday. We like to thank all those reviewers who have already sent their comments to the mailing list and the chairs. The chairs solicited a number of additional reviews and some of the contacted reviewers asked for some additional time. Given the vacation period, we gave them some more time to complete their reviews (until the end of the week) and hence we will in general accept additional reviews until the end of the week. Next week, we will start working through the comments. Of course, people can comment on the comments already now - you do not have to wait until next week. ;-) /js -- Juergen Schoenwaelder {International|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 From isms-bounces@lists.ietf.org Tue Jan 09 14:29:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4MfV-0001E5-0y; Tue, 09 Jan 2007 14:29:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4MfT-0001Dw-GZ for isms@ietf.org; Tue, 09 Jan 2007 14:29:55 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4MfO-0006gg-Aq for isms@ietf.org; Tue, 09 Jan 2007 14:29:55 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l09JThQ26399; Tue, 9 Jan 2007 14:29:43 -0500 (EST) 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 Date: Tue, 9 Jan 2007 13:29:39 -0600 Message-ID: In-Reply-To: <20070104075755.GF6446@boskop.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: please consider reviewing draft-ietf-isms-tmsm-05.txt Thread-Index: Accv1hXygN3JJjoXR2y1uoavWN1LnQES4gVA From: "David Levi" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Juergen Quittek Subject: [Isms] RE: please consider reviewing draft-ietf-isms-tmsm-05.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 Juergen, I've read through the document, it looks pretty good. I've not been keeping track of the isms wg recently, but I think you've arrived at a good approach. -Dave -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 Sent: Thursday, January 04, 2007 2:58 AM To: Levi, David (SC100:323) Cc: Juergen Quittek Subject: please consider reviewing draft-ietf-isms-tmsm-05.txt Hi, the ISMS working group is currently doing a last call on . The abstract says: This document describes a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document describes 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 discusses some key aspects that need to be considered for any transport model for SNMP. It would be very helpful if you can review the document. Please send your comments or an indication that you reviewed the document without specific comments to the ISMS working group. It would be nice to have feedback by early next week (original last call deadline was set to January 8th). /js --=20 Juergen Schoenwaelder {International|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 From isms-bounces@lists.ietf.org Wed Jan 10 13:43:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4iQ6-0003DQ-A0; Wed, 10 Jan 2007 13:43:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4iQ5-0003DH-3P for isms@ietf.org; Wed, 10 Jan 2007 13:43:29 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4iQ3-0007H8-Go for isms@ietf.org; Wed, 10 Jan 2007 13:43:29 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 1D1C157D5A for ; Wed, 10 Jan 2007 19:43:27 +0100 (CET) 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 29018-05; Wed, 10 Jan 2007 19:43:23 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 5982A5627E; Wed, 10 Jan 2007 19:43:23 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 78E68996D2F; Wed, 10 Jan 2007 19:42:21 +0100 (CET) Date: Wed, 10 Jan 2007 19:42:21 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20070110184221.GC19151@boskop.local> Mail-Followup-To: isms@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: Subject: [Isms] [case@snmp.com: Re: please consider reviewing draft-ietf-isms-tmsm-05.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, I am forwarding a message from Jeff Case who also was invited to review the last call document. Note that Jeff is not on the ISMS mailing list so please CC him in any followup discussions. /js ----- Forwarded message from Jeff Case ----- Date: Mon, 8 Jan 2007 17:23:06 -0500 (EST) From: Jeff Case To: j.schoenwaelder@iu-bremen.de Subject: Re: please consider reviewing draft-ietf-isms-tmsm-05.txt Cc: dharrington@huawei.com hello juergen and dave thanks for your note, juergen, and the invitation to review your ID [if you want the WG to see this, you will need to repost this note to the list ... this "from" address is not a member of the WG list] per your request, i have taken a few hours to read draft-ietf-isms-tmsm-05.txt and provide a few brief comments i wish i could invest more time in a detailed review, but that just isn't possible today two major comments worthy of mention 1. a project funded by a portion of the US government has been working for over a year on a project with goals that are somewhat similar to those of your efforts and i think it is possible that you and they are not aware of one another i would almost certainly get myself in trouble if i were to take the liberty of identifying them to you but unless you object (which i can't imagine), i will take the liberty of bringing your work to their attention and they can identify themselves and jump in and participate if they wish to [and are free to do so] ... if they are able to do so, i think you two sets of folks would both benefit from talking to each other and i want to encourage that the above referenced project has been in the implementation and evaluation phase for some time now, and as such, its maturity may provide some valuable lessons learned to be incorporated into the current draft (and i think their work could benefit from the strong architectural underpinnings found in your draft 2. i mention this because the experience with the project causes me to question one of the draft's fundamental tenets -- that you can do what you want to do without being forced to compromise anything in arch, v3mp, and/or usm in particular, while your design probably works flawlessly for gets and sets, and might work for traps as well, it would be helpful if you could explain to me how informs work in a way that is consistent with the above specs (yes, i read and reread page 15 several times including the waffle words found therein but maybe i am just dense and/or missed something somewhere else) for me personally, one of the most interesting things in the draft is how your design validates something we productized several years ago but took a step farther than your design ... the product uses an encrypted tunnel (e.g., through an ssl hole in a firewall), sends/receives traffic from manager apps to one or more remote forwarder(s) inside the security enclave(s) (or the DMZ), and can turn it back into an snmp packet which is sent onward with a more traditional transport mapping, and any one of the valid message model/security model combos (and vice versa in the other direction) so, i do believe that the more simple thing that the draft attempts to standardize can be made workable (if it isn't already as presently written) i also do miss working with you guys and wish i had more time to do so again ... happy new year best, jdc [if you reply only to the list and don't copy me, i won't see it] ----------- Jeff Case Founder and Chief Technical Officer SNMP Research, Inc. 3001 Kimberlin Heights Road Knoxville, TN 37920 USA +1 865 573 1434 (voice) +1 865 573 9197 (fax) case@snmp.com www.snmp.com >Date: Thu, 4 Jan 2007 08:53:02 +0100 >From: Juergen Schoenwaelder >To: Jeff Case >Subject: please consider reviewing draft-ietf-isms-tmsm-05.txt >Message-ID: <20070104075302.GD6446@boskop.local> >Reply-To: j.schoenwaelder@iu-bremen.de > >Hi, > >the ISMS working group is currently doing a last call on >. The abstract says: > > This document describes a Transport Subsystem, extending the Simple > Network Management Protocol (SNMP) architecture defined in RFC 3411. > This document describes 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 discusses some key aspects that need to be considered for any > transport model for SNMP. > >It would be very helpful if you can review the document. Please send >your comments or an indication that you reviewed the document without >specific comments to the ISMS working group. It would be nice to have >feedback by early next week (original last call deadline was set to >January 8th). > >/js > >-- >Juergen Schoenwaelder {International|Jacobs} University Bremen > P.O. Box 750 561, 28725 Bremen, Germany ----- End forwarded message ----- _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 10 13:52:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4iYl-000091-Gp; Wed, 10 Jan 2007 13:52:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4iYk-000062-Jl for isms@ietf.org; Wed, 10 Jan 2007 13:52:26 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4iYj-0000UV-57 for isms@ietf.org; Wed, 10 Jan 2007 13:52:26 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 9DB7757D5A; Wed, 10 Jan 2007 19:52:24 +0100 (CET) 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 29774-02; Wed, 10 Jan 2007 19:52:21 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 376665627E; Wed, 10 Jan 2007 19:52:21 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id AEC1A996D51; Wed, 10 Jan 2007 19:52:13 +0100 (CET) Date: Wed, 10 Jan 2007 19:52:13 +0100 From: Juergen Schoenwaelder To: Jeff Case Message-ID: <20070110185213.GD19151@boskop.local> Mail-Followup-To: Jeff Case , isms@ietf.org References: <200701082223.RAA03729@seymour39.snmp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701082223.RAA03729@seymour39.snmp.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: isms@ietf.org Subject: [Isms] Re: please consider reviewing draft-ietf-isms-tmsm-05.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 On Mon, Jan 08, 2007 at 05:23:06PM -0500, Jeff Case wrote: Jeff, first of all, thanks for taking the time to review the document. My comments to your comments are inline... > two major comments worthy of mention > > 1. a project funded by a portion of the US government has > been working for over a year on a project with goals > that are somewhat similar to those of your efforts and i > think it is possible that you and they are not aware of > one another > > i would almost certainly get myself in trouble if i were > to take the liberty of identifying them to you but unless > you object (which i can't imagine), i will take the liberty > of bringing your work to their attention and they can > identify themselves and jump in and participate if they wish > to [and are free to do so] ... if they are able to do so, > i think you two sets of folks would both benefit from talking > to each other and i want to encourage that > > the above referenced project has been in the implementation > and evaluation phase for some time now, and as such, its > maturity may provide some valuable lessons learned to be > incorporated into the current draft (and i think their work > could benefit from the strong architectural underpinnings > found in your draft Please point "the project" to the ISMS WG and our documents. Comments should be sent to the WG mailing list. > 2. i mention this because the experience with the project > causes me to question one of the draft's fundamental > tenets -- that you can do what you want to do without being > forced to compromise anything in arch, v3mp, and/or usm > > in particular, while your design probably works flawlessly for > gets and sets, and might work for traps as well, it would > be helpful if you could explain to me how informs work in > a way that is consistent with the above specs > (yes, i read and reread page 15 several times including the > waffle words found therein but maybe i am just dense and/or > missed something somewhere else) As technical contributor, I do not really see problems with informs; for me informs are not harder than traps. It would help me (and likely the whole WG) if you can elaborate where you see problems, that is where the transport subsystem compromises arch, v3mp, and/or usm. /js -- Juergen Schoenwaelder {International|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 From isms-bounces@lists.ietf.org Wed Jan 10 18:22:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4mlz-0002Tw-78; Wed, 10 Jan 2007 18:22:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4mlx-0002Tr-Qy for isms@ietf.org; Wed, 10 Jan 2007 18:22:21 -0500 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4mlw-0007Xe-JK for isms@ietf.org; Wed, 10 Jan 2007 18:22:21 -0500 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 l0ANMF9Q008989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jan 2007 18:22:16 -0500 (EST) Date: Wed, 10 Jan 2007 18:22:14 -0500 From: Jeffrey Hutzelman To: Wes Hardaker , isms@ietf.org Subject: Re: [Isms] tmsm comments Message-ID: <73551A8F99E9C13BC4A203CD@sirius.fac.cs.cmu.edu> In-Reply-To: References: Originator-Info: login-token=Mulberry:01ZBFXQc55zLWwXM/Cl4+HsPuDjmzrRdDRhoWmmpE=; 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: 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, January 08, 2007 10:17:53 PM -0800 Wes Hardaker wrote: > If each session uses new session keys, then messages > cannot be replayed from one session to another. > > Can you be more specific about what you're trying to say there? Does > that mean that if I have a GET operation that tries one session and > fails to get a response I have to do what exactly before I'm allowed > to resend it on another session? is changing the message ID > sufficient? The answer should be "nothing". I believe what the quoted text is trying to say is that if each session uses new keys, then a cross-session replay attack will be unsuccessful; that is, an attacker cannot successfully replay on one session a message he observed from another session. A good security protocol (including SSH) will also protect against replay attacks _within_ a session; that is, an attacker cannot successfully replay a message observed earlier in the same session. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 10 20:06:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4oOF-0006nl-5b; Wed, 10 Jan 2007 20:05:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4nd4-00016H-0b for isms@ietf.org; Wed, 10 Jan 2007 19:17:14 -0500 Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4nd1-0007DA-Ll for isms@ietf.org; Wed, 10 Jan 2007 19:17:13 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id DFB2411E012; Wed, 10 Jan 2007 16:15:32 -0800 (PST) From: Wes Hardaker To: Jeffrey Hutzelman Subject: Re: [Isms] tmsm comments Organization: Sparta References: <73551A8F99E9C13BC4A203CD@sirius.fac.cs.cmu.edu> Date: Wed, 10 Jan 2007 16:15:32 -0800 In-Reply-To: <73551A8F99E9C13BC4A203CD@sirius.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Wed\, 10 Jan 2007 18\:22\:14 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Wed, 10 Jan 2007 20:05:58 -0500 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org >>>>> "JH" == Jeffrey Hutzelman writes: draft> If each session uses new session keys, then messages draft> cannot be replayed from one session to another. draft> WH> Can you be more specific about what you're trying to say there? Does WH> that mean that if I have a GET operation that tries one session and WH> fails to get a response I have to do what exactly before I'm allowed WH> to resend it on another session? is changing the message ID WH> sufficient? JH> The answer should be "nothing". I believe what the quoted text is JH> trying to say is that if each session uses new keys, then a JH> cross-session replay attack will be unsuccessful; that is, an attacker JH> cannot successfully replay on one session a message he observed from JH> another session. JH> A good security protocol (including SSH) will also protect against JH> replay attacks _within_ a session; that is, an attacker cannot JH> successfully replay a message observed earlier in the same JH> session. Ah. It does make sense in that context. When reading it I was implying it was a requirement that the SNMP engine would have to implement, not a requirement to imposed on a transport. From a transport perspective sending a generic message received from above of any kind, I agree that's a necessary requirement. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jan 12 11:42:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5PUY-0008DL-P3; Fri, 12 Jan 2007 11:42:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5PUW-0008Cf-1A for isms@ietf.org; Fri, 12 Jan 2007 11:42:56 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H5PUS-0005S3-T8 for isms@ietf.org; Fri, 12 Jan 2007 11:42:55 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0CGgewX022570 for ; Fri, 12 Jan 2007 10:42:48 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 10:42:40 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 17:42:39 +0100 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 Date: Fri, 12 Jan 2007 17:42:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: working group last call on draft-ietf-isms-tmsm-05 Thread-Index: Acc2aKjqD7lBolk9SnKcZYgyHC7Tnw== From: "Wijnen, Bert \(Bert\)" To: X-OriginalArrivalTime: 12 Jan 2007 16:42:39.0195 (UTC) FILETIME=[ABE7EAB0:01C73668] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1fb4c76a9d88e8fb8b791f63f8d1b07f Cc: Subject: [Isms] RE: working group last call on draft-ietf-isms-tmsm-05 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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 have read and reviewd this document. Here are my comments. First Kudo's to the authors/editors. Pretty good work. Although have quite a set of comments/questions, I think the document is in pretty good shape.=20 But probably based on my (and other) comments (I have seen) one more rev may make sense. - I am completely confused by 3rd para of sect 3.2.1 In SNMPv2, there were many problems of side effects between subsystems caused by the manipulation of MIB objects, especially those related to authentication and authorization, because many of the parameters were stored in shared MIB objects, and different models and protocols could assign different values to the objects. Contributors assumed slightly different shades of meaning depending on the models and protocols being used. As the shared MIB module design was modified to accommodate a specific model, other models which used the same MIB objects would be broken. I wonder: - which SNMPv2 do you mean? SNMPv2c ?? Something else?=20 maybe you can use a citation/reference - I have no idea which MIB objects you are talking about, so I cannot judege if anything was broken andd if so why/how. - What are you rtying to convey or justifty in this para? - is it needed at all? - I am also somehwta confusd by the next para (4th para in sect 3.2.1): Abstract Service Interfaces (ASIs) were developed to pass model- independent parameters. The models were required to translate from their model-dependent formats into a model-independent format, defined using model-independent semantics, which would not impact other models. It probably has to do with the English here that seems pretty weird=20 to me (but then, my native tongue is not English). - IN sect 3.2.1 on page 8: Parameters have been provided in the ASIs to pass model-independent information about the authentication that has been provided. These parameters include a model-independent identifier of the security "principal", the security model used to perform the authentication, and which SNMP-specific security features were applied to the message (authentication and/or privacy). Do we leave it up to the reader to connect/link the various phrases into securityName, securityModel and securityLevel? Why are we not very clear and name the things as we have named them in 3411? - Further in section 3.2.1, page 8: Parameters have been provided in the ASIs to pass model-independent transport address information. These parameters utilize the transportDomain and transportAddress Is that last sentence not finished? And is it causing confusion? I wonder if this has any relation to the TransPortDomain/TransportAddress TCs in RFC3419. I think not. I think you are just saying that the model-independent parameters transportDomain and transportAddress (as used in RFc3411) are used. - The figure on page 9, when I compare it with the figure on page 24 of RFc3411, makes me wonder:=20 Are we completely doing away with RFC3417 ?? I guess we're not completely doing away with it are we? Maybe I'll find it further down in the document, but I fnot, we may need some words about that. - 2nd para in sect 3.2.2.1 , my comments inline The securityName MUST be bound to the mechanism-specific s/bound to/mapped from/ ?? is it really binding it or is it mapping? authenticated identity, and this mapping MUST be done for incoming messages before the security model passes securityName to the message processing model via the processIncoming() ASI. This translation from a mechanism-specific authenticated identity to a securityName MAY be done by the transport model, and the securityname is then s/securityname/securityName/ provided to the security model to be passed to the message processing model. So I think it is passed via the tmStateReference, no?=20 If so would it be usefull to say so? Or do we prefer to leave it vague? - last para of sect 3.2.2.1 If the type of authentication provided by the transport layer (e.g. TLS) is considered adequate to secure and/or encrypt the message, but inadequate to provide the desired granularity of access control (e.g. user-based), then a second authentication (e.g., one provided via a RADIUS server) MAY be used to provide the authentication identity which is bound to the securityName. This approach would require a good analysis of the potential for man-in-the-middle attacks or masquerade possibilities. It does not say anything about at what point in the process steps this mapping from RADIUS authenticated identity to a securityName needs to take place. Maybe we want to leave that open. But it seems to me that the least we can say is that: it MUST bde done for incoming messages before the security model passes securityName to the message processing model via the processIncoming() ASI.=20 - sect 3.2.2.2. starts with: A transport model that provides security services should take care to not violate the separation of authentication and authorization in the RFC3411 architecture. The isAccessAllowed() primitive is used for passing security-model independent parameters between the subsystems of the architecture. That last sentence seems to put a big claim there. It is only ONE of the primitives (ASIs) for passing (xxx-model) independent parameters. I might word it as: RFC3411 architecture. The isAccessAllowed() primitive is used for passing security-model independent parameters to an Access Control Model (like VACM) and passes Security Model independent parameters for the Access Control Model to use. - Next para in sect 3.2.2.2 states: Mapping of (securityModel, securityName) to an access control policy I think I would add securityLevel in there as well. It is clearly included in the decision process (as per figure in sect 3.1 of RFC3415) and is also security model related (some may not be able to do a specific level, like SNMPv1 over UDP cannot do authNoPriv or authPriv). I see that you later state that some Access Control Models (well your=20 wording uses inconsistent terms from RFC3411, but anyway) MAY need a securityLevel. So maybe that is why you left it out here, but certainly, it is a required parameter on the isAccessAllowed(). - To come back to terminology in sect 3.2.2.2. It states: An authorization model (in the access control subsystem) MAY require authentication by certain securityModels and a minimum securityLevel to allow access to the data. Mmm.. so now we also have an "authorization model" ?? I guess you do mean the Access Control Model (in the Access Control Subsystem) ?? - sect 3.2.2.2 Transport models that provide secure transport are an enhancement for the SNMPv3 privacy and authentication, but they are not a significant improvement for the authorization (access control) needs of SNMPv3. Are they an "enhancement"? Or are they an "addition" ?? I would say the latter. =20 Also, the are an addition for "SNMP message privacy...". You can also=20 enhance SNMPv1 and SNMPv2c privacy with it. Further, I believe that USM can also be used for as possible SNMPv4, and so again I do not see why you think it is SNMPv3 privacy specific. or SNMPv3 specific w.r.t. aithorization. - sect 3.2.2.2 A transport model must not specify how the securityModel and securityName could be dynamically mapped to an access control mechanism, such as a VACM-style groupName. The mapping of (securityModel, securityName) to a groupName is a VACM-specific mechanism for naming an access control policy, and for tying the named policy to the addressing capabilities of the data modeling language (e.g. SMIv2 [RFC2578]), the operations supported, and other factors. Providing a binding outside the Access Control subsystem I learn new things everyday. Hopefully I can leanr something new again. What is/are: the addressing capabilities of the data modeling language (e.g. SMIv2 Am I the only one who is confused by that? And a few lines further: or Windows domains. The preferred approach is to pass the model- independent security parameters via the isAccessAllowed() ASI, and perform the mapping from the model-independent security parameters to an authorization-model-dependent access policy within the access control model. Why is this not the RECOMMENDED approach? We did the architectural modularization with a purpose did we not. SO I would be strong and say RECOMMENDED instead of "preferred" Pls also change "authorization-model-dependent" into "Access Control Model dependent" - sect 3.2.3, 5th para on page 13 states: When using a secure transport model, security parameters MAY be provided through means other than carrying them in the SNMP message. The parameters MAY be provided by SNMP applications for outgoing messages, and the parameters for incoming messages MAY be extracted from the transport layer by the transport model before the message is passed to the message processing subsystem. I am somehwat confused by the 2nd sentence.=20 I thought that for an outgoing message the SNMP appas MUST provide the required security parameters. Possibly you mean that in cases like a response they get picked up from the cached parameters of the incoming request (to which is being responded), but I find the capitalzied MAY confusing. It seems to say that for example a Comamnd Generator can choose to NOT pass any security parameters and would still be=20 compliant? I am confused. - section 3.3 and onwards talks about a "transport type" and "transport address". Is that intentionally deviating from transportDomain and transportAddress as used earlier in the document? I.e. the paramaters being passed in the ASIs? - last para of sect 3.3.1 (page 15/16) states: If a session can be reused for a different type of message, but a receiver is not prepared to accept different message types over the same session, then the message MAY be dropped by the receiver. This may strongly affect the usefulness of session reuse, and transport models should define a standard behavior for this circumstance. Mmm... "type of message" ? I only see this term occur once in RFC3411. It basically is the PDU type. But OK, I can live with it. I am worried about the fact that "a transport model needs to define standard behaviour for this". How/where does a transport model know about the message type (or PDU type) ?? The pduType is passed between Dispatcher and MP model (in the ASIs), but I do not see it passed from the dispatcher to transport subsystem. Is the TM=20 suppsoed to go dig into the PDU itself? I hope not. - In your sect 4.2, I would add that the diagram is from RFC3411. Oteghrwise people might think there was/is a change. - In sect 4. You state that some info is missing in 4.6.1. and 4.6.2 in 3411. You then show (repeat) the diagrams from 4.6.1. and 4.6.2 in your sections 4.1. and 4.2. But no further diagram extension to "complete" them? I am missing the purpose of this? Is that just me? I had expected the completed diagram, no? For example I had expected to see the sendMessage and recvMessage in a renewed diagram. (By the way, why no use "receiveMessage" instead of "recvMessage"? we have many long ASI names already, and I hate all these abbreviation for no reason). - I am not 100% sure, but is it correct that section 5.1. about the securityStateReference is not adding any new (or changing any existing) information compared to RFC3411? If so, I would prefer we state that explicitly. If it does add something, pls make it clear what is being added/changed. - Section 5.2 I think (but it is not clear) that the transport model should save a mapping from transport security/authentication ID to seucirtyName so the the Security Model can pick it up and pass it back as an OUT parameter on the processIncomingMessage ASI,. no? - 6.2. Processing for an Outgoing Message The sendMessage ASI is used to pass a message from the Dispatcher to the appropriate transport model for sending. statusInformation =3D sendMessage( IN destTransportDomain -- transport domain to be used IN destTransportAddress -- transport address to be used IN outgoingMessage -- the message to send IN outgoingMessageLength -- its length IN tmStateReference -- reference to transport state ) Would it be usefull to add a not that the tmStateReference is not always filled out? Let us say that I have just started my SNMP manager, now I am going to send my first SNMP GET Request. I would use above ASI (I think). But what is the content of tmStateRefrence here? Will it be filled upon return? I can see that when I want to call sendMEssage to send a response that the tmStateRefrence contains the info that came in on the request. - 6.3.1. Processing an Incoming Message Is there any difference for an incoming response compared to a incoming request? Not clear to me. - 7. Security Considerations This document describes an architectural approach that would permit I would: s/would permit/permits/ - I am not sure I understand why RFC2578 needs to be a normative reference - I have not checked appendix A - Appendix B says: This appendix considers why a cache-based approach was selected for passing parameters. This section may be removed from subsequent revisions of the document. I recommend to keep this appendix. It will/may help us remember (in 5 or 10 years from now) why we did this. So remove the 2nd sentence. - I guess Appendix C will get removed ;-) NITS: - page 4: the approach being proposed for NETCONF [I-D.ietf-netconf-ssh]. change citation to [RFC4741] I know you could not know the RFCnumber when rev 5 was done. But if you do an update, then pls include this. - Sect 3.1 Is there a good reason to list the threaths in a different order=20 as is done in RFC3414 page 5? Mmm... I see they are in the same order as in RFC3411 pages 6/7. So ignore my rambling. - Section 3.2.1 Mmm.. the terminology used looks similar, but not the same as in RFC3411. And I wonder if it would not be better to use the same terms. I would also use same capitlized words. In fact you do use the RFC3411 terms in the figure on page 5. TMSM RFC3411 messaging subsystem Message Processing Subsystem application subsystem Application(s) access control subsystem Access Control Subsystem I would also change "transport subsystem" to Transport Subsystem"=20 just for consistency in capitalization. In fact in the figure, and in some other places you already do so. - In section 3.2.1.1 I see a few cases of tautologie=20 - USM model (USM =3D User-based Security Model) - USM security model - Further in sect 3.1.1, my comments inlined in a copy of the text: 3.2.1.1. USM and the RFC3411 Architecture The following diagrams illustrate the difference in the security mmm.. where are thos diagrams? Is a diagram not a drawing/figure or some such? or ist it just text? processing done by the USM model and the security processing potentially done by a transport model. The USM security model is encapsulated by the messaging model, because the messaging model needs to perform the following steps (for I wonder if the "because" is correct. In any event, the list below has many things in it that have nothing to do with the fact that the USM is encapsulated in the Message Processing Model (not that I use the RFC3411 term) incoming messages) 1) decode the ASN.1 (messaging model) I would change that in "determine the Message Processing Model" now it sounds as if it is completely doing the ASN.1 decoding before it calls USM. It only partially does that. 2) determine the SNMP security model and parameters (messaging model) 3) decrypt the encrypted portions of the message (security model) 4) translate parameters to model-independent parameters (security model) this step is completely inside Security Model, no? in fact step 3,4,5 are all just one call from the Message Processing Model to the Security Model, namely the processIncomingMsg ASI (Sect 4.4.2 in 3411) 5) determine which application should get the decrypted portions (messaging model), and This is done outside of the Message Processing Model (even in the figure on page 9 of tmsm document) namely it is "PDU Dispatch" in the "Dispatcher" 6) pass on the decrypted portions with model-independent parameters. The USM approach uses SNMP-specific message security and parameters. Not 100% sure what that last sentence means. Probably you mean to=20 tell us that an SNMPv3 message does have a USM specific set of security parameters. The SNMPv3 message format is specified in RFC3412 and indeed for has reserved/allocated a space for ALL Security Model to pass Security Model specific parameters. From RFC3412: -- security model-specific parameters -- format defined by Security Model msgSecurityParameters OCTET STRING, =20 If some Security Model does not need it, then it can be the zero-length OCTET STRING. - In sect 3.2.1.2, snippets of the text with my comments inline: 2*) translate parameters to model-independent parameters (transport model) Does that asterisk have special meaning? Or is it just a typo. I guess the latter. 3) determine the SNMP security model and parameters (transport model) Mmm... is that determined by the TM at the receiving end? Is it then filled in in the SNMPv3 message? Or is it checked against=20 what is in there already? If a message is secured using non-SNMP-specific message security and parameters, then the transport model should provide the translation from the authenticated identity (e.g., an SSH user name) to the securityName in step 3. Mmm... I think I would reword into: If a message is secured using secure transport layer, then the related transport model should provide the translation from the authenticated identity (e.g., an SSH user name) to the securityName in step 3. =20 after all, "non-SNMP-specific message security" could also be something that has nothing to do with the transport layer (I have no idea what yet) and so it would be strange to mandate that e TM would have to fill our parameters, no? But aside from that, I wonder if/how this works. once we move from the Transport Model to the Dispatcher, then the Dispatcher calls the Message Processinge Model via prepareDataElements ASI. That ASI has an OUT parameter for securityName. So what will=20 happen if we have filled out the securityName in step 3? =20 I guess, we want the Transport Model to map these transport-layer-security parameters into model-independent security parameters, save them in the tmStateReference and then later, when the Message Processing Model calls the Transport Security Model, they get filled in into the securityName (and other parameters). Assuming that I correctly understand how these transport layer security parameters get mapped, saved and then passed around, I think the steps in sect 3.2.1.2 may rather confuse people. If I completely mis-understand it, then I there are inconsistencies in your document, because in sect 6.1 on page 23, you state The OUT parameters of the prepareOutgoingMessage() ASI are used to pass information from the message processing model to the dispatcher and on to the transport model: And in the ASI on page 22, the securityName is still listed (as I expected by the way) as an OUT parameter. =20 - In sections 3.2.1, 3.2.1.1 and 3.2.1.2 you explain the agent-side and the process steps (and the order of those steps) for an incoming message. I can easily see how to map the manager side for the picture. I wonder if it makes sense to check if we need to say anything about sending a (i.e. an outgoing) message? The sequence of steps there is also different. Can people easily determine that based on these 3 sections? - Maybe it is my skill in English, but in sect 3.2.1.3,=20 I would change After a transport layer tunnel is established, then SNMP messages can conceptually be sent through the tunnel from one SNMP engine to another SNMP engine. Once the tunnel is established, multiple SNMP into: After a transport layer tunnel is established, then SNMP messages can be sent through the tunnel from one SNMP engine to the other SNMP engine. Once the tunnel is established, multiple SNMP I am not sure if the word "conceptually" is needed/useful. What do you try to convey? For me, they can just be sent, no? Also, toy cannot send the messages to just "another", but just to one, namely the one you are conne3cted to, other engine.=20 Further, I would change: another SNMP engine. Once the tunnel is established, multiple SNMP messages may be able to be passed through the same tunnel. into another SNMP engine. Once the tunnel is established, multiple SNMP messages can be passed through the same tunnel. it is shorter, but also, the meaning is somewhat different and clearer I think (at least in my ear). - sect 3.2.2.2 RFC3411 architecture. The isAccessAllowed() primitive is used for Why is this now a "primitive" and while it is an ASI in the 4th para on page 12: independent security parameters via the isAccessAllowed() ASI, and Pls try to be consistent. I see however that we did this also on RFC341x document. SO feel free to ignore this one if you like. - I think the first MAY on page 14 could be lower case, or maybe even better could be replcaed by "can". The capitalized MAY/MUST/SHOULD and such are for compliance=20 information. I don't think that is the situation here, is it? - I also see no reason for a capitalized MAY in the last para on page 15. - Last para in sect 3.3.3 I think the first capitalized MAY would better be a lower case may. =20 TYPOs: - page 6, sect 3.1 Using a protocol in a manner for which it was not designed has numerous problems. The advertised security characteristics of a protocol may depend on its being used as designed; when used in other in last line: s/its/it/ ?? - 3rd para page 8: The design of a transport subsystem must abide the goals of the RFC3411 architecture defined in [RFC3411]. To that end, this transport subsystem proposal uses a modular design that will permit s/abide/abide by/ ?? s/RFC3411 architecture/SNMP architecture/ ??=20 I can live with RFC3411 architecture though. I see it comes back several times. I find it strange though to name an architecure after an RFC number. =20 s/proposal// -- by the time this is an RFC it is no longer a proposal is it? - 4 para on page 8 the motivstion of developing transport models is to develop support s/motivstion/motivation/ - last para page 8 The RFC3411 architecture,and the USM assume that a security model is called by a message-processing model and will perform multiple s/,and/, and/ s/message-processing model/Message Processing Model/ I hope you get the gist here on consistency of terms/terminology. I think I would also do s/USM/Security Subsystem/ - section 4.4. Some secure transports may have a notion of sessions, while other secure transports might provide channels or other session-like thing. s/thing/things/ ?? =20 - last para page 20 The information saved should include the model-independent parameters (transportDomain, transportAddress, securityName, securityModel, and securityLevel), related security parameters, and other information needed to imatch the response with the request. The Message s/imatch/match/ Bert _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jan 12 16:34:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5U2Y-0001X9-4G; Fri, 12 Jan 2007 16:34:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5U2W-0001Wp-6O for isms@ietf.org; Fri, 12 Jan 2007 16:34:20 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5U2T-0007FK-SQ for isms@ietf.org; Fri, 12 Jan 2007 16:34:20 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id F305D56205; Fri, 12 Jan 2007 22:34:16 +0100 (CET) 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 07934-07; Fri, 12 Jan 2007 22:34:12 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id B9D3755E1A; Fri, 12 Jan 2007 22:34:12 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 8BC41998664; Fri, 12 Jan 2007 22:34:11 +0100 (CET) Date: Fri, 12 Jan 2007 22:34:11 +0100 From: Juergen Schoenwaelder To: "Wijnen, Bert (Bert)" Subject: Re: [Isms] RE: working group last call on draft-ietf-isms-tmsm-05 Message-ID: <20070112213411.GA26744@boskop.local> Mail-Followup-To: "Wijnen, Bert (Bert)" , isms@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Fri, Jan 12, 2007 at 05:42:34PM +0100, Wijnen, Bert (Bert) wrote: > I have read and reviewd this document. Here are my comments. > > First Kudo's to the authors/editors. Pretty good work. > Although have quite a set of comments/questions, I think > the document is in pretty good shape. > > But probably based on my (and other) comments (I have seen) > one more rev may make sense. Thanks for your rather detailed review. This is much appreciated (as are all the other reviews of course). /js -- Juergen Schoenwaelder {International|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 From isms-bounces@lists.ietf.org Thu Jan 18 12:21:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7awq-0002zI-Qn; Thu, 18 Jan 2007 12:21:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7awn-0002vk-I3 for isms@ietf.org; Thu, 18 Jan 2007 12:21:10 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7awk-0000gF-6t for isms@ietf.org; Thu, 18 Jan 2007 12:21:09 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 459AD574D1; Thu, 18 Jan 2007 18:21:03 +0100 (CET) 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 15765-07; Thu, 18 Jan 2007 18:21:00 +0100 (CET) Received: from wavelan1.dynip.doc.ic.ac.uk (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 06CD14D33A; Thu, 18 Jan 2007 18:21:00 +0100 (CET) Received: by wavelan1.dynip.doc.ic.ac.uk (Postfix, from userid 501) id C93169C6546; Thu, 18 Jan 2007 18:20:56 +0100 (CET) Date: Thu, 18 Jan 2007 18:20:56 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Subject: Re: [Isms] working group last call on draft-ietf-isms-tmsm-05 Message-ID: <20070118172056.GA19071@wavelan1.dynip.doc.ic.ac.uk> Mail-Followup-To: isms@ietf.org, Juergen Quittek References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Juergen Quittek 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 Fri, Dec 15, 2006 at 04:03:00PM +0100, Juergen Quittek wrote: > This is the working group last call on the "Transport Subsystem for > the Simple Network Management Protocol (SNMP)" to be found at > . [...] > Please do review the document and post your comments on this list until > January 8, 2007. Please also post to the list if you have read the document > and are fine with it. It is very useful to know how many people have read > the document. The 1st WG last call on is complete. We received several good reviews and many concrete suggestions for improvements - many thanks to the reviewers. We will produce an updated version before the ID cutoff to address the issues raised during the last call. /js -- Juergen Schoenwaelder {International|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 From isms-bounces@lists.ietf.org Fri Jan 26 15:50:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAY1V-0000xP-H3; Fri, 26 Jan 2007 15:50:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAY1L-0000q7-15; Fri, 26 Jan 2007 15:50:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAY1K-0004I4-Iv; Fri, 26 Jan 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 7076C26F2B; Fri, 26 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HAY1K-0004Nj-Am; Fri, 26 Jan 2007 15:50:02 -0500 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, 26 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-transport-security-model-02.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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-02.txt Pages : 28 Date : 2007-1-26 This memo describes a Transport Security Model for the Simple Network Management Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-transport-security-model-02.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-02.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-02.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-1-26105008.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-transport-security-model-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-transport-security-model-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-26105008.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 Jan 29 18:49:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgFO-0003w0-F0; Mon, 29 Jan 2007 18:49:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgFN-0003vu-4S for isms@lists.ietf.org; Mon, 29 Jan 2007 18:49:13 -0500 Received: from omr2.networksolutionsemail.com ([205.178.146.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBgFM-00085J-FW for isms@lists.ietf.org; Mon, 29 Jan 2007 18:49:13 -0500 Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l0TNnCfi001507 for ; Mon, 29 Jan 2007 18:49:12 -0500 Received: (qmail 5748 invoked by uid 78); 29 Jan 2007 23:49:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr2.lb.hosting.dc2.netsol.com with SMTP; 29 Jan 2007 23:49:11 -0000 Message-ID: <45BE880C.6020806@andybierman.com> Date: Mon, 29 Jan 2007 15:49:32 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: isms@lists.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 031b5f42d6d2cd097710e6b68613cb36 Cc: Subject: [Isms] review of draft-ietf-isms-tmsm-05 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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 was asked to review the transport subsystem draft. I hope these comments help. Andy Review of draft-ietf-isms-tmsm-05 Abstract This section is a bit redundant and vague. It is not very clear why a transport sub-system is needed, and is being added now, so many years after SNMP Arch was done. I know SNMP doesn't like to confine any system components, so there is "an" architecture instead of "the" architecture, but IMO, this document needs to be more normative, and more clear about what is being defined (normative) vs. discussed (informational). 2. Motivation The home security analogy is not very clear. Consider introducing this section with a sentence that securing a network protocol is like securing a home or business, and make it clear that this intro relates to the following paragraphs in this section. This document describes a Transport Subsystem extension to the RFC3411 architecture. Which approach (of the 3 choices) does this document take? The diagram on pg. 5 should be introduced and quickly explained where this document fits into the diagram. pg. 6: SNMP continues to work without any surprises. Expand or add an example of the kind of surprise that this document addresses. I assume you mean non-transparent inter-operability with an SNMP peer by "no surprises". That should be explained here. pg 7: Transport models MUST be able to coexist with other transport models, and may be designed to utilize either TCP or UDP or SCTP. The section leading up to this last sentence is really good, but SCTP is not mentioned at all, and then this summary sentence suggests supporting it. In the first sentence, suggest changing "other transport models" to "each other". pg. 8: missing space The RFC3411 architecture,and the USM assume that a security model is ^ pg. 9 diagram: Can you highlight what is new vs. already in place for SNMP? There is a caption that says (traditional SNMP agent) but this is not clear, since it shows new transports TCP, SSH, and TLS. It is an excellent diagram, but could be explained a bit more. Sec 3.2.1 General: It is not clear what is existing and what is new in these procedures. 3.2.1.1. USM and the RFC3411 Architecture The following diagrams illustrate the difference in the security Do you mean previous diagram, since this is on pg. 10? 3.2.2. Access Control Requirements General: Would help to have an executive summary at the start of this section (like a table) that lists what new things the 3.2.2.* sections are going to explain. 3.2.2.1. securityName Binding processing model via the processIncoming() ASI. This translation should remove parens ^^ If the type of authentication provided by the transport layer (e.g. (several places) missing comma ^ pg 12: A transport model must not specify how the securityModel and securityName could be dynamically mapped to an access control mechanism, such as a VACM-style groupName. The mapping of (securityModel, securityName) to a groupName is a VACM-specific mechanism for naming an access control policy, and for tying the named policy to the addressing capabilities of the data modeling language (e.g. SMIv2 [RFC2578]), the operations supported, and other factors. Providing a binding outside the Access Control subsystem might create dependencies that could make it harder to develop alternate models of access control, such as one built on UNIX groups or Windows domains. The preferred approach is to pass the model- independent security parameters via the isAccessAllowed() ASI, and perform the mapping from the model-independent security parameters to an authorization-model-dependent access policy within the access control model. To provide support for protocols which simultaneously send information for authentication and authorization, such as RADIUS [RFC2865], model-specific authorization information MAY be cached or otherwise made available to the access control subsystem, e.g., via a MIB table similar to the vacmSecurityToGroupTable, so the access control subsystem can create an appropriate binding between the model-independent securityModel and securityName and a model-specific access control policy. This may be highly undesirable, however, if it creates a dependency between a transport model or a security model and an access control model, just as it is undesirable for a transport model to create a dependency between an SNMP message version and the security provided by a transport model. A summary table gathering all the requirements from large paragraphs (like the 2 above) would be helpful. 3.2.3. Security Parameter Passing Requirements A table summarizing the security parameters would be helpful. It would be useful to refer back to the diagram as to the specific information flow or ASI in question. This document describes a cache mechanism, into which the transport model puts information about the transport and security parameters Describes or defines? A section number reference would be good here. 3.3. Session Requirements Some secure transports may have a notion of sessions, while other secure transports might provide channels or other session-like thing. s/thing/mechanism/ Throughout this document, the term session is used in a broad sense to cover sessions, channels, and session-like things. Session refers s/things/mechanisms/ It is important to note that the architecture described in [RFC3411] does not include a session selector in the Abstract Service Interfaces, and neither is that done for the transport subsystem, so an SNMP application cannot select the session except by passing a unique combination of transport type, transport address, securityName, securityModel, and securityLevel. This seems like a very important paragraph (and requirement). It would be nice to explain why all these parameters are needed to identify a session. All transport models should discuss the impact of sessions on SNMP usage, including how to establish/open a transport session (i.e., how it maps to the concepts of session-like things of the underlying protocol), how to behave when a session cannot be established, how to close a session properly, how to behave when a session is closed improperly, the session security properties, session establishment overhead, and session maintenance overhead. To reduce redundancy, this document will discuss aspects that are expected to be common to all transport model sessions. IMO, 'define' (not 'discuss') should be used when referring to standards track documents. A summary (somewhere in the doc) of all the requirements this spec defines + another summary of the requirements that are expected to be defined externally. 3.3.1. Session Establishment Requirements SNMP Applications typically have no knowledge of whether the session that will be used to carry commands was initially established as a notification session, or a request-response session, and SHOULD NOT make any assumptions based on knowing the direction of the session. Is this true? Why doesn't the session initiator know what type of session is being requested? If an administrator or transport model designer wants to differentiate a session established for different purposes, such as a notification session versus a request-response session, the application can use different securityNames or transport addresses (e.g., port 161 vs. port 162) for different purposes. Is this a normative definition? Maybe a use case and example diagram would be helpful. An SNMP engine containing an application that initiates communication, e.g., a Command Generator or Notification Originator, MUST be able to attempt to establish a session for delivery if a session does not yet exist. If a session cannot be established then the message is discarded. Does the application know it is establishing a session? Are the sessions just a transport layer mechanism? Some explanation of the document I should have read before starting this document should be in the Introduction section. If a session can be reused for a different type of message, but a receiver is not prepared to accept different message types over the same session, then the message MAY be dropped by the receiver. This may strongly affect the usefulness of session reuse, and transport models should define a standard behavior for this circumstance. IMO, this document should define the behavior, and not pass it to the transport implementation. Silently dropping messages in a purposely undefined way is not good standards practice. 3.3.2. Session Maintenance Requirements A transport model can tear down sessions as needed. It may be necessary for some implementations to tear down sessions as the result of resource constraints, for example. I am unclear on the session model here wrt/ which components are aware of sessions. Does the application initiate session control or not? I usually think of sessions as user-controlled and user-configured inactivity timeout. Is that what is meant by resource constraints? The decision to tear down a session is implementation-dependent. Why? Why isn't session control requirements part of the standard? 3.3.3. Message security versus session security ... SNMPv3 was designed to support multiple levels of security, selectable on a per-message basis by an SNMP application, because there is not much value in using encryption for a Commander Generator to poll for non-sensitive performance data on thousands of interfaces every ten minutes; the encryption may add significant overhead to processing of the messages. Should note that this non-sensitive polling is an example, not imply this is the only reason for per-message security. 4.1. Command Generator or Notification Originator This diagram from RFC3411 4.6.1 shows how a Command Generator or Notification Originator application [RFC3413] requests that a PDU be sent, and how the response is returned (asynchronously) to that application. I don't see how the diagrams in sec 4. relate to sessions and to the transport sub-system. 5. Cached Information and References This document differentiates the tmStateReference from the securityStateReference. Suggest providing some context as to what these variables are, and how they are different. 5.1. securityStateReference A Message Processing Model has the responsibility for explicitly releasing the cached data if such data is no longer needed. To enable this, an abstract securityStateReference data element is passed from the Security Model to the Message Processing Model. The cached security data may be implicitly released via the generation of a response, or explicitly released by using the stateRelease primitive, as described in RFC3411 section 4.5.1." Is securityStateReference a new construct or something from RFC 3411? The information saved should include the model-independent parameters (transportDomain, transportAddress, securityName, securityModel, and securityLevel), related security parameters, and other information needed to imatch the response with the request. The Message sp. ^^^^^^ If the transport model connection is closed between the time a Request is received and a Response message is being prepared, then the Response message MAY be discarded. What other options would be appropriate? 5.2. tmStateReference For each message or transport session, information about the message security is stored in a cache, which may inlcude model- and sp. ^^^^^^^ 6. Abstract Service Interfaces An error indication may return an OID and value for an incremented counter and a value for securityLevel, and values for contextEngineID and contextName for the counter, and the securityStateReference if the information is available at the point where the error is detected. Which error indication? Response to what operation? 6.2. Processing for an Outgoing Message The sendMessage ASI is used to pass a message from the Dispatcher to the appropriate transport model for sending. statusInformation = sendMessage( IN destTransportDomain -- transport domain to be used IN destTransportAddress -- transport address to be used IN outgoingMessage -- the message to send IN outgoingMessageLength -- its length IN tmStateReference -- reference to transport state ) Are there any changes to this ASI? What is the purpose of this section? 6.3. Processing an Incoming SNMP Message 6.3.1. Processing an Incoming Message If one does not exist, the Transport Model will need to create an entry in a Local Configuration Datastore referenced by tmStateReference. This information will include transportDomain, transportAddress, the securityModel, the securityLevel, and the securityName, plus any model or mechanism-specific details. How this information is determined is model-specific. Model-specific? This is kind of a new term. Implementation-specific has been raised so far, but not this. 6.3.2. Prepare Data Elements from Incoming Messages The abstract service primitive from the Dispatcher to a Message Processing Model for a received message is: .... Note that tmStateReference has been added to this ASI. Should explain how the ASI semantics change due to the new parameter. 6.3.3. Processing an Incoming Message Should explain how the ASI semantics change due to the new parameter. 7. Security Considerations secret keys does not result in disclosure of past session keys. The editors recommend that each proposed transport model include a discussion in its security considerations of whether perfect forward security is appropriate for the transport model. The editors recommend does not sound very official. Since the cache and LCD will contain security-related parameters, they should be kept in protected storage. What exactly is meant by protected? [I-D.ietf-netconf-ssh] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure Shell (SSH)", draft-ietf-netconf-ssh-06 (work in progress), March 2006. Update reference to RFC 4742. Appendix A. Parameter Table Following is a CSV formatted matrix useful for tracking data flows into and out of the dispatcher, transport, message, and security subsystems. Import this into your favorite spreadsheet or other CSV compatible application. You will need to remove lines feeds from the second, third, and fourth lines, which needed to be wrapped to fit into RFC limits. A.1. ParameterList.csv Not clear what this section is for. The syntax is very cryptic. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms