From isms-bounces@lists.ietf.org Thu Sep 06 16:17:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITNky-0000ju-VW; Thu, 06 Sep 2007 16:15:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITNkl-0000X8-Nw; Thu, 06 Sep 2007 16:15:03 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITNkl-0005Em-98; Thu, 06 Sep 2007 16:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D36E7175AB; Thu, 6 Sep 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ITNkk-0007qY-4I; Thu, 06 Sep 2007 16:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 06 Sep 2007 16:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-radius-usage-00.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 : Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models Author(s) : K. Narayan, D. Nelson Filename : draft-ietf-isms-radius-usage-00.txt Pages : 14 Date : 2007-9-6 This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service by Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell Transport Model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-usage-00.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-radius-usage-00.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-radius-usage-00.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-9-6152408.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-radius-usage-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-radius-usage-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-6152408.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@lists.ietf.org Fri Sep 07 03:28:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITYEt-0006yl-H3; Fri, 07 Sep 2007 03:26:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITYEs-0006yg-JU for isms@ietf.org; Fri, 07 Sep 2007 03:26:50 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITYEr-0005Bi-Vb for isms@ietf.org; Fri, 07 Sep 2007 03:26:50 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F37086404 for ; Fri, 7 Sep 2007 09:26:49 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 12444-05; Fri, 7 Sep 2007 09:26:44 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1130786406; Fri, 7 Sep 2007 09:26:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E868C32B8EC; Fri, 7 Sep 2007 09:26:40 +0200 (CEST) Date: Fri, 7 Sep 2007 09:26:40 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20070907072640.GA3495@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [Isms] isms core documents last call status X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, the WG last call on the core ISMS documents has so far resulted in the following reviews (let me know if the data below is incorrect): draft-ietf-isms-tmsm-09.txt BW, TP, JS draft-ietf-isms-transport-security-model-05.txt BW, TP, DR, JS draft-ietf-isms-secshell-08.txt BW, WH, JS [BW] = Bert Wijnen [TP] = Tom Petch [DR] = Dan Romascanu [JS] = Joe Salowey [WH] = Wes Hardacker While some very good people reviewed the documents, it would surely not hurt to have some additional reviews. If there are more people here who have read the documents but kept silence since they did not have an issue to post, please let me know. If you did not manage to read the documents due to vacation time, please still consider to review the documents and send comments by the end of next week (September 15th) or contact me if you need more time. I am now going through the discussions in detail in order to classify the issues that were brought up to see which are editorial, which are technical and if there are any issues where the resolution is not clear. Once I have assembled this list, I will post it here for WG review and ask Dave to revise the documents. I hope we can deliver the core documents to the IESG soon. Since I have to write up the paper work for submission to the IESG, I am also interested to hear about people planning to implement or experiment with the ISMS technology. While there have been several indications in the past, it surely helps me if people interested to implement/experiment contact me again so that I have an up-to-date view on things. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 07 04:06:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITYpk-0007pS-Or; Fri, 07 Sep 2007 04:04:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITYpj-0007jH-FD for isms@ietf.org; Fri, 07 Sep 2007 04:04:55 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITYpi-0002IS-7r for isms@ietf.org; Fri, 07 Sep 2007 04:04:55 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-outbound.avaya.com with ESMTP; 07 Sep 2007 04:04:51 -0400 X-IronPort-AV: i="4.20,220,1186372800"; d="scan'208"; a="62503649:sNHT11132226" 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] isms core documents last call status Date: Fri, 7 Sep 2007 10:04:10 +0200 Message-ID: In-Reply-To: <20070907072640.GA3495@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] isms core documents last call status Thread-Index: AcfxIJC6dIuQnNVZR86haFK93eQp2gAAotuQ References: <20070907072640.GA3495@elstar.local> From: "Romascanu, Dan (Dan)" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 Juergen, I have also read draft-ietf-isms-tmsm-09 and have no major comments or issues by now. The second paragraph in 1.3 may cause some discussions later, if it said just that non capitalized words would normally be interpreted as in plain English it would be good enough and non-controversial IMO. This is not major however.=20 I have read a previous version of draft-ietf-isms-secshell and was happy enough about where this was going. If I will have tome to read the latest version and comment back I'll let you know.=20 Dan =20 =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Friday, September 07, 2007 10:27 AM > To: isms@ietf.org > Subject: [Isms] isms core documents last call status >=20 > Hi, >=20 > the WG last call on the core ISMS documents has so far=20 > resulted in the following reviews (let me know if the data=20 > below is incorrect): >=20 > draft-ietf-isms-tmsm-09.txt BW, TP, JS > draft-ietf-isms-transport-security-model-05.txt BW, TP, DR, JS > draft-ietf-isms-secshell-08.txt BW, WH, JS >=20 > [BW] =3D Bert Wijnen > [TP] =3D Tom Petch > [DR] =3D Dan Romascanu > [JS] =3D Joe Salowey > [WH] =3D Wes Hardacker >=20 > While some very good people reviewed the documents, it would=20 > surely not hurt to have some additional reviews. If there are=20 > more people here who have read the documents but kept silence=20 > since they did not have an issue to post, please let me know.=20 > If you did not manage to read the documents due to vacation=20 > time, please still consider to review the documents and send=20 > comments by the end of next week (September 15th) or contact=20 > me if you need more time. >=20 > I am now going through the discussions in detail in order to=20 > classify the issues that were brought up to see which are=20 > editorial, which are technical and if there are any issues=20 > where the resolution is not clear. Once I have assembled this=20 > list, I will post it here for WG review and ask Dave to=20 > revise the documents. I hope we can deliver the core=20 > documents to the IESG soon. >=20 > Since I have to write up the paper work for submission to the=20 > IESG, I am also interested to hear about people planning to=20 > implement or experiment with the ISMS technology. While there=20 > have been several indications in the past, it surely helps me=20 > if people interested to implement/experiment contact me again=20 > so that I have an up-to-date view on things. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 07 04:20:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITZ3B-0003Dv-Fx; Fri, 07 Sep 2007 04:18:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITZ39-0003Dl-0h for isms@ietf.org; Fri, 07 Sep 2007 04:18:47 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITZ38-0006cA-JC for isms@ietf.org; Fri, 07 Sep 2007 04:18:46 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01AD6863E7; Fri, 7 Sep 2007 10:18:46 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 18177-03; Fri, 7 Sep 2007 10:18:41 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D4A8A55F77; Fri, 7 Sep 2007 10:18:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 024A332B9FC; Fri, 7 Sep 2007 10:18:39 +0200 (CEST) Date: Fri, 7 Sep 2007 10:18:39 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Subject: Re: [Isms] isms core documents last call status Message-ID: <20070907081839.GB3537@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , isms@ietf.org References: <20070907072640.GA3495@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Fri, Sep 07, 2007 at 10:04:10AM +0200, Romascanu, Dan (Dan) wrote: > I have also read draft-ietf-isms-tmsm-09 and have no major comments or > issues by now. The second paragraph in 1.3 may cause some discussions > later, if it said just that non capitalized words would normally be > interpreted as in plain English it would be good enough and > non-controversial IMO. This is not major however. > > I have read a previous version of draft-ietf-isms-secshell and was happy > enough about where this was going. If I will have tome to read the > latest version and comment back I'll let you know. Thanks for letting me know and yes it would be nice if you can also take a look at the latest version of the secshell document. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 07 11:17:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITfYI-0000SI-Ku; Fri, 07 Sep 2007 11:15:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITfYG-0000Rz-T7 for isms@ietf.org; Fri, 07 Sep 2007 11:15:20 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITfYG-0007g1-9O for isms@ietf.org; Fri, 07 Sep 2007 11:15:20 -0400 Received: from pc6 (1Cust140.tnt30.lnd3.gbr.da.uu.net [62.188.122.140]) by astro.systems.pipex.net (Postfix) with SMTP id 7FFCAE0000D1; Fri, 7 Sep 2007 16:15:16 +0100 (BST) Message-ID: <029d01c7f158$a7b4ab80$0601a8c0@pc6> From: "tom.petch" To: , References: <20070907072640.GA3495@elstar.local> Subject: Re: [Isms] isms core documents last call status Date: Fri, 7 Sep 2007 16:07:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Juergen You are right that I have commented on tmsm and I would regard my comments on the use of security name and security level (and I deliberately do not use the RFC3411 terminology here) therein as technical and (as yet) unresolved. Jeffrey has rightly pointed out that words can be found to support a position - eg sshtm - but I think that an architecture document should be clearer than that, particularly over the issue of values being transformed. Also, it is not obvious what can and cannot be achieved, as with USM over SSH, which currently appears infeasible. The sshtm I-D is more restrictive and so is not such a problem; but I can see a future working group trying to make sense of tmsm in the way we have tried to make sense of eg authoritative, context engines, informs etc Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: Sent: Friday, September 07, 2007 9:26 AM Subject: [Isms] isms core documents last call status > Hi, > > the WG last call on the core ISMS documents has so far resulted in the > following reviews (let me know if the data below is incorrect): > > draft-ietf-isms-tmsm-09.txt BW, TP, JS > draft-ietf-isms-transport-security-model-05.txt BW, TP, DR, JS > draft-ietf-isms-secshell-08.txt BW, WH, JS > > [BW] = Bert Wijnen > [TP] = Tom Petch > [DR] = Dan Romascanu > [JS] = Joe Salowey > [WH] = Wes Hardacker > > While some very good people reviewed the documents, it would surely > not hurt to have some additional reviews. If there are more people > here who have read the documents but kept silence since they did not > have an issue to post, please let me know. If you did not manage to > read the documents due to vacation time, please still consider to > review the documents and send comments by the end of next week > (September 15th) or contact me if you need more time. > > I am now going through the discussions in detail in order to classify > the issues that were brought up to see which are editorial, which are > technical and if there are any issues where the resolution is not > clear. Once I have assembled this list, I will post it here for WG > review and ask Dave to revise the documents. I hope we can deliver the > core documents to the IESG soon. > > Since I have to write up the paper work for submission to the IESG, I > am also interested to hear about people planning to implement or > experiment with the ISMS technology. While there have been several > indications in the past, it surely helps me if people interested to > implement/experiment contact me again so that I have an up-to-date > view on things. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Sep 09 03:13:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUGx8-00078o-TP; Sun, 09 Sep 2007 03:11:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUGx7-00072w-Ea for isms@ietf.org; Sun, 09 Sep 2007 03:11:29 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUGx6-0006Ts-05 for isms@ietf.org; Sun, 09 Sep 2007 03:11:29 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id E821E8627D for ; Sun, 9 Sep 2007 09:11:26 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 04161-04; Sun, 9 Sep 2007 09:11:22 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7296B56AD0; Sun, 9 Sep 2007 09:11:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 81E9532E0C2; Sun, 9 Sep 2007 09:11:21 +0200 (CEST) Date: Sun, 9 Sep 2007 09:11:21 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20070909071121.GA7025@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Isms] Nomcom 2007 - 2008: Nominations Close on September 10, 2007 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, just in case we have people here who have not seen this yet: http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg04056.html Please consider nominating people so that the Nomcom can do a good job. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 11 02:58:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUzfh-00012z-Hw; Tue, 11 Sep 2007 02:56:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUzff-00012l-Uo for isms@ietf.org; Tue, 11 Sep 2007 02:56:27 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUzfe-00016B-GM for isms@ietf.org; Tue, 11 Sep 2007 02:56:27 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7453A86416; Tue, 11 Sep 2007 08:56:25 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 09848-07; Tue, 11 Sep 2007 08:56:20 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4BB0E863E7; Tue, 11 Sep 2007 08:56:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 807EF33460B; Tue, 11 Sep 2007 08:56:16 +0200 (CEST) Date: Tue, 11 Sep 2007 08:56:16 +0200 From: Juergen Schoenwaelder To: "Wijnen, Bert (Bert)" Message-ID: <20070911065616.GA16313@elstar.local> Mail-Followup-To: "Wijnen, Bert (Bert)" , dbharrington@comcast.net, 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.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: dbharrington@comcast.net, isms@ietf.org Subject: [Isms] Re: sendMessage and receiveMessage ASIs in draft-ietf-isms-tmsm-09.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Wed, Aug 08, 2007 at 11:46:16AM +0200, Wijnen, Bert (Bert) wrote: > For my own understanding, can you confirm that > > the sendMessage ASI and the receiveMessage ASI would > fit in RFC3411 scenario Diagrams (sect 4.6.1 and 4.6.2) > and would take the place of the > > "Send SNMP (Request) Message to Network" > "Receive SNMP (Response) Message from Network" > > respectively? > > If so, I wonder if it would be good to say so, or to add such > a scenario diagram to the I-D. I think the sendMessage ASI and the receiveMessage ASI do indeed match the mentioned elements in the diagram. If David agrees as well, I think we should add a sentences stating this (I am not sure it is worth to repeat the whole diagram - but I do not feel strongly). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 11 03:04:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUzlY-000646-86; Tue, 11 Sep 2007 03:02:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUzlX-00063y-L5 for isms@ietf.org; Tue, 11 Sep 2007 03:02:31 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUzlX-0002rC-1X for isms@ietf.org; Tue, 11 Sep 2007 03:02:31 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 97D11863E6; Tue, 11 Sep 2007 09:02:29 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 10539-02-3; Tue, 11 Sep 2007 09:02:24 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B82F95ACDE; Tue, 11 Sep 2007 09:02:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 018AE334651; Tue, 11 Sep 2007 09:02:17 +0200 (CEST) Date: Tue, 11 Sep 2007 09:02:17 +0200 From: Juergen Schoenwaelder To: "Wijnen, Bert (Bert)" Message-ID: <20070911070217.GB16313@elstar.local> Mail-Followup-To: "Wijnen, Bert (Bert)" , David Harrington , 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.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: isms@ietf.org Subject: [Isms] Re: tmStateReference in draft-ietf-isms-tmsm-09.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Wed, Aug 08, 2007 at 12:17:56PM +0200, Wijnen, Bert (Bert) wrote: > I am confused by the last 2 paragraphs in sect 6.2 > > The prepareOutgoingMessage ASI passes tmStateReference from the > Message Processing Subsystem to the dispatcher. How or if the > Message Processing Subsystem modifies or utilizes the contents of the > cache is message-processing-model-specific. > > This may sound underspecified, but keep in mind that a message > processing model might have access to all the information from the > cache and from the message, and have no need to call a Security Model > to do any processing; an application might choose a Security Model > such as USM to authenticate and secure the SNMP message, but also > utilize a secure transport such as that provided by the SSH Transport > Model to send the message to its destination. > > specifically the wording "an application...". > Applications in our RFC3411 context are CG or CR or NO or NR or such. > I am sure that is not intended here. But then, what is an "application" > in this sentence above? > > I am also not sure we should speak about the MPM to "not call a > security model". From our architectural point of view, the MPM > will ALWAYS call a security model. If an implementation does a > shortcut, that is up to them... but should we discuss that here? > > I am similarly confused by the "an application..." in section 6.4 > last paragraph. I am wondering whether this issue can be solved by simply deleting the second quoted paragraph since I am not sure it adds value. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 11 03:09:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUzqG-00032q-Ln; Tue, 11 Sep 2007 03:07:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUzqF-00032l-FW for isms@ietf.org; Tue, 11 Sep 2007 03:07:23 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUzqF-0002w4-2f for isms@ietf.org; Tue, 11 Sep 2007 03:07:23 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l8B76eN6022930; Tue, 11 Sep 2007 02:07:12 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 02:06:51 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 09:06:49 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 11 Sep 2007 09:06:46 +0200 Message-ID: In-Reply-To: <20070911065616.GA16313@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: sendMessage and receiveMessage ASIs indraft-ietf-isms-tmsm-09.txt Thread-Index: Acf0QOIsQnMNUDp+TbSlg9DEyWyy9gAAUzhQ References: <20070911065616.GA16313@elstar.local> From: "Wijnen, Bert \(Bert\)" To: X-OriginalArrivalTime: 11 Sep 2007 07:06:49.0322 (UTC) FILETIME=[528B2CA0:01C7F442] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: dbharrington@comcast.net, isms@ietf.org Subject: [Isms] RE: sendMessage and receiveMessage ASIs indraft-ietf-isms-tmsm-09.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 Thanks. Adding a few words to make the statement would be good. Personally, I think that adding one diagram might be useful too (the less people have to switch between multiple docs, the easier). But I won't get hung up on that. Bert Wijnen =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Tuesday, September 11, 2007 8:56 AM > To: Wijnen, Bert (Bert) > Cc: dbharrington@comcast.net; isms@ietf.org > Subject: Re: sendMessage and receiveMessage ASIs=20 > indraft-ietf-isms-tmsm-09.txt >=20 > On Wed, Aug 08, 2007 at 11:46:16AM +0200, Wijnen, Bert (Bert) wrote: > > For my own understanding, can you confirm that > >=20 > > the sendMessage ASI and the receiveMessage ASI would > > fit in RFC3411 scenario Diagrams (sect 4.6.1 and 4.6.2) > > and would take the place of the > >=20 > > "Send SNMP (Request) Message to Network" > > "Receive SNMP (Response) Message from Network" > >=20 > > respectively? > >=20 > > If so, I wonder if it would be good to say so, or to add such a=20 > > scenario diagram to the I-D. >=20 > I think the sendMessage ASI and the receiveMessage ASI do=20 > indeed match the mentioned elements in the diagram. If David=20 > agrees as well, I think we should add a sentences stating=20 > this (I am not sure it is worth to repeat the whole diagram -=20 > but I do not feel strongly). >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 11 03:24:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV05a-0001cc-1l; Tue, 11 Sep 2007 03:23:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV05Y-0001Ys-N9 for isms@ietf.org; Tue, 11 Sep 2007 03:23:12 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV05X-0003Ef-SE for isms@ietf.org; Tue, 11 Sep 2007 03:23:12 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6974D86404; Tue, 11 Sep 2007 09:23:11 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 12142-03-59; Tue, 11 Sep 2007 09:23:06 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3930F86426; Tue, 11 Sep 2007 09:22:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 734283346E4; Tue, 11 Sep 2007 09:22:36 +0200 (CEST) Date: Tue, 11 Sep 2007 09:22:36 +0200 From: Juergen Schoenwaelder To: "Wijnen, Bert (Bert)" Subject: Re: [Isms] my review of: Message-ID: <20070911072236.GC16313@elstar.local> Mail-Followup-To: "Wijnen, Bert (Bert)" , David Harrington , 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.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Wed, Aug 08, 2007 at 04:57:57PM +0200, Wijnen, Bert (Bert) wrote: > Just nits I think. > > > - Sect 2.4, 5th line > to the appropriate Transport Model through a series of APIs, as > s/API/ASI/ !!?? > > also one but last line in sect 2.4 > a series of APIs, as described in "Transport Subsystem for the Simple > s/API/ASI/ !!?? Yes, seems an editorial fix to me. > - section 6: 6. Overview > > Maybe change that section title to MIB Module Overview? > > - ::= { snmpModules xxxx } > > Is there a good reason to put this underneath that snmpModules branch? > I do understand we have the snmpUsmMIB (so to be consistent this one > should be named snmpTsmMIB) and related MIB modules under snmpModules. > So from that point it makes sense. > > But we have stated (in RFC4181) that an OID is just an OID and > MIB modules should go under mib-2. > And we have no-where specified IANA guidelines as to how/when to > assign new values under snmpModules. > > I know that some other WG wants to put their MIB modules under a > common branch of their own as well... and they are (as we speak) > getting push-back from our AD. The question is why we have snmpModules in the first place and whether we continue to root SNMP modules under snmpModules or treat them as all other modules. The SNMP-USM-AES-MIB was probably the last one rooted under snmpModules - so SNMP addons have been rooted in the not too distant past. I suggest Dan provides advise whether we continue to use snmpModules or declare that we declare snmpModules was a bad idea and we stop assigning things below snmpModules (and perhaps this can then be documented in the IANA documents so we don't forget about this and we can make tools to check for this). I am fine with changing tsmMIB to snmpTsmMIB. > - tsmInvalidCache OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION "The number of messages dropped because the > tmStateReference referred to an invalid cache. > > This value is not persistent across reboots. > " > ::= { tsmStats 1 } Perhaps rename to tsmInvalidCacheReferences? > tsmInadequateSecurity OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION "The number of incoming messages dropped because > the actual securityLevel provided was less than > the requested securityLevel. > > This value is not persistent across reboots. > " > ::= { tsmStats 2 } Perhaps rename to tsmInadequateSecurityLevels? > According to our CLRs, the names/descriptors should express plurality. > Not that I cannot live with them being named as is? Just that we as > MIB doctors should probably follow our own CLRs. > > I do not understand why we need to say something about "persistency"? > We May want to state that discontinuties only can occur at a reboot > or restart of the agent? I suggest to simply drop the sentences about persistence since the default in SNMP land is that counters do not persist across reboots (or at least sysUpTime will indicate a discontinuity). > - I also see: > > tsmGroups OBJECT IDENTIFIER ::= { tsmConformance 1 } > tsmCompliances OBJECT IDENTIFIER ::= { tsmConformance 2 } > > > While RFC4181 suggests: > > xxxMIB > | > +-- xxxNotifications(0) > +-- xxxObjects(1) > +-- xxxConformance(2) > | > +-- xxxCompliances(1) > +-- xxxGroups(2) > > So first compliances, then groups. OK, lets just flip the two things. > - I get somehwat worried when following (In IANA Considerations > section): > > 2. a value, preferably 4, to identify the Transport Security Model, > in the Security Models registry at > http://www.iana.org/assignments/snmp-number-spaces. This should > > Because if you go to http://www.iana.org/assignments/smi-numbers and > search for "SNMP Management Architecture:" you will find that the > number > space is listed there as well. So for now I guess IANA should update > both locations. But probably it is best if theu only maintain it in > one > place. > > The http://www.iana.org/assignments/snmp-number-spaces uses current > RFCs as references. The http://www.iana.org/assignments/smi-numbers > uses > old RFC226x as references. > > I will report this "duplicate registry" issue to IANA seperately. The duplicate registry needs to be worked out with IANA. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 11 03:45:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV0Oy-0004Xc-7Y; Tue, 11 Sep 2007 03:43:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV0Ow-0004XX-TV for isms@ietf.org; Tue, 11 Sep 2007 03:43:14 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV0Ow-0003fs-1S for isms@ietf.org; Tue, 11 Sep 2007 03:43:14 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D9B586427; Tue, 11 Sep 2007 09:43:13 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 13723-10; Tue, 11 Sep 2007 09:43:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B86C86424; Tue, 11 Sep 2007 09:43:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 990BC3347AD; Tue, 11 Sep 2007 09:43:06 +0200 (CEST) Date: Tue, 11 Sep 2007 09:43:06 +0200 From: Juergen Schoenwaelder To: "Wijnen, Bert (Bert)" Subject: Re: [Isms] my review of: draft-ietf-isms-secshell-08.txt Message-ID: <20070911074306.GD16313@elstar.local> Mail-Followup-To: "Wijnen, Bert (Bert)" , David Harrington , jsalowey@cisco.com, 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.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Thu, Aug 09, 2007 at 12:17:13PM +0200, Wijnen, Bert (Bert) wrote: > > Some of these are NITs, I know that. > > - I think the abstract should also mention that there is a MIB module > defined in this document. > > - I think the last para of sect 1.2 can/should be removed, or at least > the > RFC-Editor should be instructed to do so. editorial > - Sect 1.4 > > The work will address ... > > The work will include ... > > Maybe better: This document addresses ... > This document includes/defines ... editorial > - sect 5.1 and 5.1 > I assume that SSH_MSG_USERAUTH_REQUEST and SSH_MSG_CHANNEL_DATA > are specified somewhere in the SSH RFC(s)? Maybe a citation to > such RFC(s) is useful at these points. there were suggestions in the discussion to actually be less precise concerning SNMP messages and this seems to solve this issue > - top of page 15: > 45 Extract any implementation-specific parameters from the LCD > 6) Pass the wholeMessage to SSH for encapsulation in an > SSH_MSG_CHANNEL_DATA message. > > what is "45"? Should that be "5)" > But the whole first sentence seems to not belong here? editorial > - Should we root this MIB module under snmpModules? > see my arguments in my review of the MIB module in > draft-ietf-isms-transport-security-model-05.txt > > If we do keep it under snmpModules, then > sshtmMIB MODULE-IDENTITY > possibly would be better > snmpSshtmMIB MODULE-IDENTITY > to be consistent with the other MIB modules under snmpModules. > > - Copyright in MIB module should be IETF Trust, not ISOC > > - I see: > sshtmGroups OBJECT IDENTIFIER ::= { sshtmConformance 1 } > sshtmCompliances OBJECT IDENTIFIER ::= { sshtmConformance 2 } > > while RFC4181 suggests: > > xxxMIB > | > +-- xxxNotifications(0) > +-- xxxObjects(1) > +-- xxxConformance(2) > | > +-- xxxCompliances(1) > +-- xxxGroups(2) > > i.e. first compliances, then groups. This needs to be dealt with according the resolution we achieve for the TMS document. > - For SnmpSSHAddress ::= TEXTUAL-CONVENTION I read: > > "Represents either a hostname encoded in ASCII > using the IDNA protocol, as specified in RFC3490, followed by > a colon ':' (ASCII character 0x3A) and a decimal port number > in ASCII, or an IP address followed by a colon ':' > (ASCII character 0x3A) and a decimal port number in ASCII. > The name SHOULD be fully qualified whenever possible. > > I am not well versed/experienced in IDNA. But is IDNA a protocol? > The title of 3490 reads > Internationalizing Domain Names in Applications (IDNA) > And are we indeed speaking of a hostname, or of a domain name, or > of both? I can't quickly determine that. So I wonder if/hope that > we can be clearer here. Seems to have been resolved in the discussion. > I also assume (although this is not explicitly stated) that if we > speak about an IP address, that it is a dotted decimal for > IPv4 and and a colon separated IPv6 address in ASCII? Yes/no? > > I am concerned that for > SnmpUDPAddress ::= TEXTUAL-CONVENTION > DISPLAY-HINT "1d.1d.1d.1d/2d" > we use a / sign to separate the port from the IPv4 address > and here we use a colon (:). > I must admit that (RFC3419) also uses : > TransportAddressIPv4 ::= TEXTUAL-CONVENTION > DISPLAY-HINT "1d.1d.1d.1d:2d" > > And what do we use for IPv6 addresses/ports? The SnmpUDPAddress notation goes back to the old days where a common notation for transport endpoints did not exist yet. Nowadays, it is common to read a.b.c.d/e as a prefix and a.b.c.d:e as an IPv4 transport endpoint and [::]:e as an IPv6 transport endpoint. There is an RFC specifying this IPv6 notion and we might just refer to it; I think the latest document is RFC 3986 which obsoletes RFC 2732. Note that also RFC 3419 uses the now more common notation and breaks with the old SnmpUDPAddress notation. > Further I read: > > When this textual convention is used as a syntax of an > index object, there may be issues with the limit of 128 > sub-identifiers specified in SMIv2, STD 58. In this case, > the OBJECT-TYPE declaration MUST include a 'SIZE' clause > to limit the number of potential instance sub-identifiers." > > Mmm.. we do not normally enforce (i.e. MUST language) that a SIZE > clause must be used. We allo the DESCIRPTION clause to explain > that implementers must be aware and cater for OID limitations. > So do we really want that MUST language here? I think this text was copied from RFC 3419 which actually has MUST language. RFC 4181 only RECOMMENDS to MIB documents are explicit by either including SIZE constraints or specifying things in the row DESCRIPTION clause. Since RFC 4181 is newer than RFC 3419, I suggest that we adopt RFC 4181 language here. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 11 04:06:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV0k2-0007rA-8D; Tue, 11 Sep 2007 04:05:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV0k1-0007r0-2I for isms@ietf.org; Tue, 11 Sep 2007 04:05:01 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV0k0-0004Jy-El for isms@ietf.org; Tue, 11 Sep 2007 04:05:00 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id B3F9786426; Tue, 11 Sep 2007 10:04:59 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 16178-01; Tue, 11 Sep 2007 10:04:53 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15FE786421; Tue, 11 Sep 2007 10:04:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 539F83348D5; Tue, 11 Sep 2007 10:04:52 +0200 (CEST) Date: Tue, 11 Sep 2007 10:04:52 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Subject: Re: [Isms] WGLC comments - draft-ietf-isms-transport-security-model-05.txt Message-ID: <20070911080452.GF16313@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , 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.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Thu, Aug 09, 2007 at 01:56:23PM +0200, Romascanu, Dan (Dan) wrote: > > 1. Is RFC 2828 referred by other security-related documents? I find this > document problematic, there is a revision on the table IESG table that > has also problems and I decided that I cannot support it because among > other inadequate terminology concerning SNMP and management aspects. The > way it is mentioned in Section 1.2 may be interpreted that with the > right timing this document could be relevant, which is not the case IMO. > I would either ignore it, or just mention that the terminology in this > document is not intended to be consistent with RFC 2828. There seems to be consensus that it is fine to stick with the SNMP terminology here. Furthermore, it seems we are doing better if we avoid an explicit reference to RFC 2828 since there is an update pending. So I propose that David wordsmiths the text to say we use SNMP terminology and to avoid explicit references to sources of other terminology. > 2. It would be good to include the comment that MIB objects defined here > SHOULD not be referenced in other documents in the MIB module itself, > maybe in the DESCRIPTION clause. > > 3. Bert already mentioned the issue of > > ::= { snmpModules xxxx } > > Actually I believe there is a justification of consistency with the > snmpUsmMIB which was defined prior to RFC 4181 if the authors believe > that this is important, but I agree that snmpTsmMIB is a better MIB. > > If you do take this path, I believe that you should clarify in the IANA > considerations section that the policy of further assignments of new > values under snmpModules is Standards Action. So I suggest we stick to snmpModules, change the OID descriptiors for the module identity to have an snmp prefix, and document for IANA that registrations under snmpModules requires a Standards Action. > 4. Some abbreviations (MPM, ASI) are being reused from other SNMP > documents as RFC 3411 without being expanded at first occurrence or the > origin being referred to. editorial /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 11 04:26:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV13V-0001M5-Ng; Tue, 11 Sep 2007 04:25:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV13V-0001Kk-5f for isms@ietf.org; Tue, 11 Sep 2007 04:25:09 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV13T-0002ol-QW for isms@ietf.org; Tue, 11 Sep 2007 04:25:09 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 54199863DF; Tue, 11 Sep 2007 10:25:07 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 18507-01-2; Tue, 11 Sep 2007 10:25:02 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 297F19A7; Tue, 11 Sep 2007 10:24:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2ACED334973; Tue, 11 Sep 2007 10:24:59 +0200 (CEST) Date: Tue, 11 Sep 2007 10:24:59 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Subject: Re: [Isms] barely a review: secshell-08 Message-ID: <20070911082459.GG16313@elstar.local> Mail-Followup-To: Wes Hardaker , 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.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Fri, Aug 10, 2007 at 10:24:38PM -0700, Wes Hardaker wrote: > > I didn't get as far into it as I had hoped, but I do support the > document based on what I've read so far and think it's important work. > > misc points: > > introduction: > Secure Shell Protocol => Secure Shell Protocol (SSH) [RFC4251?] editorial > 1.2: > acting as either manager or agent or both => > acting in either manager or agent or both roles > > SNMP applications included in the engine => > SNMP application types being implemented > > (the SNMP applications don't sit in the engine, so the original > wording doesn't meet the SNMP architecture). > > USM => User-Based Security Model (USM) [RFC3414] > > delete the last paragraph (todo markings) editorial > 1.3: > design decision*s* => design decision > > These MIB objects SHOULD NOT be referenced in other documents > > That one kind of bothers me. Generally in the IETF, we encourage > cross-reuse among MIB modules and here you're specifically saying > pretend this one doesn't exist if you're working on something else. > I'm not really fond of that notion. I do understand the rational > for wanting to do it, but I don't think you gain anything in the > end and you certainly loose the ability to do some possible future > reuse. I think this can be solved by simply deleting all text except the first sentence: In keeping with the RFC 3411 design decisions to use self-contained documents, this memo includes the elements of procedure plus associated MIB objects which are needed for processing the Secure Shell Transport Model for SNMP. The rest of the paragraph is trying to explain the motivation for the RFC 3411 design decision but it may not really be needed to repeat this in every SNMP document since section 1.5 of RFC 3411 explains this well enough. > 1.4: > USM typically utilizes => USM utilizes > > not deploying SNMPv3 at this point in time => > not deploying SNMPv3 > > to minimize the time until deployment is possible => > to minimize deployment time > > 4th paragarph, 1st sentence: does the work properly allow for future > SSH extensions to add authentication capabilities (I believe it is > supposed to). If so, that should probably be noted in this sentence. editorial /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 11 04:37:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV1DM-0003VT-4g; Tue, 11 Sep 2007 04:35:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV1DL-0003VO-KZ for isms@ietf.org; Tue, 11 Sep 2007 04:35:19 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV1DL-0004sK-5K for isms@ietf.org; Tue, 11 Sep 2007 04:35:19 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l8B8Yu1u003136; Tue, 11 Sep 2007 03:35:17 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 03:34:57 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 10:34:55 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 11 Sep 2007 10:34:52 +0200 Message-ID: In-Reply-To: <20070911070217.GB16313@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: tmStateReference in draft-ietf-isms-tmsm-09.txt Thread-Index: Acf0Qb9YW3KPxhNBRDSgCrovK4lmmQADLIvA References: <20070911070217.GB16313@elstar.local> From: "Wijnen, Bert \(Bert\)" To: X-OriginalArrivalTime: 11 Sep 2007 08:34:55.0598 (UTC) FILETIME=[A168E0E0:01C7F44E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: isms@ietf.org Subject: [Isms] RE: tmStateReference in draft-ietf-isms-tmsm-09.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 Inline Bert Wijnen =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Tuesday, September 11, 2007 9:02 AM > To: Wijnen, Bert (Bert) > Cc: David Harrington; isms@ietf.org > Subject: Re: tmStateReference in draft-ietf-isms-tmsm-09.txt >=20 > On Wed, Aug 08, 2007 at 12:17:56PM +0200, Wijnen, Bert (Bert) wrote: > =20 > > I am confused by the last 2 paragraphs in sect 6.2 > >=20 > > The prepareOutgoingMessage ASI passes tmStateReference from the > > Message Processing Subsystem to the dispatcher. How or if the > > Message Processing Subsystem modifies or utilizes the=20 > contents of the > > cache is message-processing-model-specific. > >=20 > > This may sound underspecified, but keep in mind that a message > > processing model might have access to all the=20 > information from the > > cache and from the message, and have no need to call a=20 > Security Model > > to do any processing; an application might choose a=20 > Security Model > > such as USM to authenticate and secure the SNMP message, but also > > utilize a secure transport such as that provided by the=20 > SSH Transport > > Model to send the message to its destination. > >=20 > > specifically the wording "an application...". > > Applications in our RFC3411 context are CG or CR or NO or=20 > NR or such. > > I am sure that is not intended here. But then, what is an=20 > "application" > > in this sentence above? > >=20 > > I am also not sure we should speak about the MPM to "not call a=20 > > security model". From our architectural point of view, the MPM will=20 > > ALWAYS call a security model. If an implementation does a shortcut,=20 > > that is up to them... but should we discuss that here? > >=20 > > I am similarly confused by the "an application..." in=20 > section 6.4 last=20 > > paragraph. >=20 > I am wondering whether this issue can be solved by simply=20 > deleting the second quoted paragraph since I am not sure it=20 > adds value. >=20 That would do it for me. But iirc, DBH thinks it is important. I am not hung up on it. But I stay confused if it is kept. Removing the 2nd para above, does still leave the use of "an application.." in sect 6.4, right? Bert > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 11 04:51:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV1RG-0001Sy-5x; Tue, 11 Sep 2007 04:49:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV1RE-0001S8-Pk for isms@ietf.org; Tue, 11 Sep 2007 04:49:40 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV1RE-0005Dq-5U for isms@ietf.org; Tue, 11 Sep 2007 04:49:40 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id B10A531FB; Tue, 11 Sep 2007 10:49:39 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 20793-02-7; Tue, 11 Sep 2007 10:49:34 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62A0886428; Tue, 11 Sep 2007 10:49:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 64BC2334B3D; Tue, 11 Sep 2007 10:49:15 +0200 (CEST) Date: Tue, 11 Sep 2007 10:49:15 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] SNMP-SSH-TM-MIB session info Message-ID: <20070911084915.GA16577@elstar.local> Mail-Followup-To: David Harrington , 'ISMS WG' References: <000001c7ddc1$b8ad72f0$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c7ddc1$b8ad72f0$6702a8c0@china.huawei.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Mon, Aug 13, 2007 at 11:50:49AM -0400, David Harrington wrote: > SNMP does not have sessions; the only sessions are sessions of the > transport protocol. This module counts sessions. We have no way of > knowing whether, for example, SSH chooses to close a session without > telling us. We can only count how many times we called openSession, > and how many times we called closeSession ASIs. We do not know how > many sessions the SSH implementation can handle, or how many SSH > sessions are currently open. I think we should eliminate the > sshtmSessionCurrent and sshtmSessionMaxSupported objects. I agree. But speaking as a technical contributor and implementor, I would actually support the inclusion for counters that count the number of times openSession() and closeSession() have been invoked since frequent calls to open / close SSH sessions can very well be an issue worth being able to easily detect (and sticking the counter into the code for this is really easy). So my proposal would be to delete sshtmSessionCurrent and sshtmSessionMaxSupported and instead add: sshtmSessionOpens OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an openSession() request has been executed. " ::= { sshtmSession 1 } sshtmSessionCloses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times a closeSession() request has been executed. " ::= { sshtmSession 2 } Note that we have to be clear how the counters related to each other. One option is that sshtmSessionOpens and sshtmSessionCloses count all open and close requests, regardless whether they success of fail. The counter sshtmSessionOpenErrors would then count all open errors while sshtmSessionUserAuthFailures and sshtmSessionChannelOpenFailures would then only count these specific failures. In other words, sshtmSessionOpenErrors = sshtmSessionUserAuthFailures + sshtmSessionChannelOpenFailures + sshtmSessionOpens = sshtmSessionOpenErrors + The alternative is that sshtmSessionOpens only counts successful opens and then we would have the total number of opens as the sum of sshtmSessionOpens and sshtmSessionOpenErrors. I can go either way as long as the relationship between the counters is clearly defined. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 11 04:56:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV1WF-0007aF-5i; Tue, 11 Sep 2007 04:54:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV1WD-0007Zr-D0 for isms@ietf.org; Tue, 11 Sep 2007 04:54:49 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV1WC-0005bQ-M8 for isms@ietf.org; Tue, 11 Sep 2007 04:54:49 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l8B8skAW010617; Tue, 11 Sep 2007 03:54:46 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 03:54:46 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 10:54:44 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Isms] my review of: draft-ietf-isms-secshell-08.txt Date: Tue, 11 Sep 2007 10:54:33 +0200 Message-ID: In-Reply-To: <20070911074306.GD16313@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] my review of: draft-ietf-isms-secshell-08.txt Thread-Index: Acf0R4CtbS7LJdZvSMy8sdJjAaH11gACdc/g References: <20070911074306.GD16313@elstar.local> From: "Wijnen, Bert \(Bert\)" To: X-OriginalArrivalTime: 11 Sep 2007 08:54:44.0077 (UTC) FILETIME=[65CC61D0:01C7F451] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org I am OK with suggested resolutions. Bert Wijnen =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Tuesday, September 11, 2007 9:43 AM > To: Wijnen, Bert (Bert) > Cc: David Harrington; jsalowey@cisco.com; isms@ietf.org > Subject: Re: [Isms] my review of: draft-ietf-isms-secshell-08.txt >=20 > On Thu, Aug 09, 2007 at 12:17:13PM +0200, Wijnen, Bert (Bert) wrote: > >=20 > > Some of these are NITs, I know that. > >=20 > > - I think the abstract should also mention that there is a=20 > MIB module > > defined in this document. > >=20 > > - I think the last para of sect 1.2 can/should be removed,=20 > or at least=20 > > the > > RFC-Editor should be instructed to do so. >=20 > editorial > =20 > > - Sect 1.4 > >=20 > > The work will address ... > >=20 > > The work will include ... > >=20 > > Maybe better: This document addresses ... > > This document includes/defines ... >=20 > editorial >=20 > > - sect 5.1 and 5.1 > > I assume that SSH_MSG_USERAUTH_REQUEST and SSH_MSG_CHANNEL_DATA > > are specified somewhere in the SSH RFC(s)? Maybe a citation to > > such RFC(s) is useful at these points. >=20 > there were suggestions in the discussion to actually be less=20 > precise concerning SNMP messages and this seems to solve this issue >=20 > > - top of page 15: > > 45 Extract any implementation-specific parameters from the LCD > > 6) Pass the wholeMessage to SSH for encapsulation in an > > SSH_MSG_CHANNEL_DATA message. > >=20 > > what is "45"? Should that be "5)" > > But the whole first sentence seems to not belong here? >=20 > editorial >=20 > > - Should we root this MIB module under snmpModules?=20 > > see my arguments in my review of the MIB module in > > draft-ietf-isms-transport-security-model-05.txt > >=20 > > If we do keep it under snmpModules, then=20 > > sshtmMIB MODULE-IDENTITY > > possibly would be better > > snmpSshtmMIB MODULE-IDENTITY > > to be consistent with the other MIB modules under snmpModules. > > > > - Copyright in MIB module should be IETF Trust, not ISOC > >=20 > > - I see: > > sshtmGroups OBJECT IDENTIFIER ::=3D { sshtmConformance 1 } > > sshtmCompliances OBJECT IDENTIFIER ::=3D { sshtmConformance 2 } > >=20 > > while RFC4181 suggests: > >=20 > > xxxMIB > > | > > +-- xxxNotifications(0) > > +-- xxxObjects(1) > > +-- xxxConformance(2) > > | > > +-- xxxCompliances(1) > > +-- xxxGroups(2) > >=20 > > i.e. first compliances, then groups. >=20 > This needs to be dealt with according the resolution we=20 > achieve for the TMS document. > =20 > > - For SnmpSSHAddress ::=3D TEXTUAL-CONVENTION I read: > >=20 > > "Represents either a hostname encoded in ASCII > > using the IDNA protocol, as specified in RFC3490,=20 > followed by > > a colon ':' (ASCII character 0x3A) and a decimal port number > > in ASCII, or an IP address followed by a colon ':' > > (ASCII character 0x3A) and a decimal port number in ASCII. > > The name SHOULD be fully qualified whenever possible. > >=20 > > I am not well versed/experienced in IDNA. But is IDNA a protocol? > > The title of 3490 reads > > Internationalizing Domain Names in Applications (IDNA) > > And are we indeed speaking of a hostname, or of a domain name, or > > of both? I can't quickly determine that. So I wonder if/hope that > > we can be clearer here. >=20 > Seems to have been resolved in the discussion. >=20 > > I also assume (although this is not explicitly stated) that if we > > speak about an IP address, that it is a dotted decimal for > > IPv4 and and a colon separated IPv6 address in ASCII? Yes/no? > >=20 > > I am concerned that for=20 > > SnmpUDPAddress ::=3D TEXTUAL-CONVENTION > > DISPLAY-HINT "1d.1d.1d.1d/2d" > > we use a / sign to separate the port from the IPv4 address > > and here we use a colon (:). > > I must admit that (RFC3419) also uses : > > TransportAddressIPv4 ::=3D TEXTUAL-CONVENTION > > DISPLAY-HINT "1d.1d.1d.1d:2d" > >=20 > > And what do we use for IPv6 addresses/ports? >=20 > The SnmpUDPAddress notation goes back to the old days where a=20 > common notation for transport endpoints did not exist yet.=20 > Nowadays, it is common to read a.b.c.d/e as a prefix and=20 > a.b.c.d:e as an IPv4 transport endpoint and [::]:e as an IPv6=20 > transport endpoint. There is an RFC specifying this IPv6=20 > notion and we might just refer to it; I think the latest=20 > document is RFC 3986 which obsoletes RFC 2732. Note that also=20 > RFC 3419 uses the now more common notation and breaks with=20 > the old SnmpUDPAddress notation. >=20 > > Further I read: > >=20 > > When this textual convention is used as a syntax of an > > index object, there may be issues with the limit of 128 > > sub-identifiers specified in SMIv2, STD 58. In this case, > > the OBJECT-TYPE declaration MUST include a 'SIZE' clause > > to limit the number of potential instance sub-identifiers." > >=20 > > Mmm.. we do not normally enforce (i.e. MUST language) that a SIZE > > clause must be used. We allo the DESCIRPTION clause to explain > > that implementers must be aware and cater for OID limitations. > > So do we really want that MUST language here? >=20 > I think this text was copied from RFC 3419 which actually has=20 > MUST language. RFC 4181 only RECOMMENDS to MIB documents are=20 > explicit by either including SIZE constraints or specifying=20 > things in the row DESCRIPTION clause. Since RFC 4181 is newer=20 > than RFC 3419, I suggest that we adopt RFC 4181 language here. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 11 04:56:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV1WH-0007bX-9X; Tue, 11 Sep 2007 04:54:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV1WF-0007bB-LQ for isms@ietf.org; Tue, 11 Sep 2007 04:54:51 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV1WE-0003bi-CZ for isms@ietf.org; Tue, 11 Sep 2007 04:54:51 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l8B8slkZ010635; Tue, 11 Sep 2007 03:54:47 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 03:54:47 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 10:54:44 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Isms] my review of: Date: Tue, 11 Sep 2007 10:52:13 +0200 Message-ID: In-Reply-To: <20070911072236.GC16313@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] my review of: Thread-Index: Acf0RKAIYi60aOCbTkCM3qvcWtb3FQADA3gQ References: <20070911072236.GC16313@elstar.local> From: "Wijnen, Bert \(Bert\)" To: X-OriginalArrivalTime: 11 Sep 2007 08:54:44.0483 (UTC) FILETIME=[660A5530:01C7F451] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 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 Inline Bert Wijnen =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Tuesday, September 11, 2007 9:23 AM > To: Wijnen, Bert (Bert) > Cc: David Harrington; isms@ietf.org > Subject: Re: [Isms] my review of: >=20 > On Wed, Aug 08, 2007 at 04:57:57PM +0200, Wijnen, Bert (Bert) wrote: > > Just nits I think. > >=20 > >=20 > > - Sect 2.4, 5th line > > to the appropriate Transport Model through a series of APIs, as > > s/API/ASI/ !!?? > >=20 > > also one but last line in sect 2.4 > > a series of APIs, as described in "Transport Subsystem=20 > for the Simple > > s/API/ASI/ !!?? >=20 > Yes, seems an editorial fix to me. > =20 yep > > - section 6: 6. Overview > >=20 > > Maybe change that section title to MIB Module Overview? > >=20 > > - ::=3D { snmpModules xxxx } > >=20 > > Is there a good reason to put this underneath that=20 > snmpModules branch? > > I do understand we have the snmpUsmMIB (so to be=20 > consistent this one > > should be named snmpTsmMIB) and related MIB modules under=20 > snmpModules. > > So from that point it makes sense. > >=20 > > But we have stated (in RFC4181) that an OID is just an OID and > > MIB modules should go under mib-2.=20 > > And we have no-where specified IANA guidelines as to how/when to > > assign new values under snmpModules. > >=20 > > I know that some other WG wants to put their MIB modules under a=20 > > common branch of their own as well... and they are (as we speak) > > getting push-back from our AD. >=20 > The question is why we have snmpModules in the first place=20 > and whether we continue to root SNMP modules under=20 > snmpModules or treat them as all other modules. The=20 > SNMP-USM-AES-MIB was probably the last one rooted under=20 > snmpModules - so SNMP addons have been rooted in the not too=20 > distant past. I suggest Dan provides advise whether we=20 > continue to use snmpModules or declare that we declare=20 > snmpModules was a bad idea and we stop assigning things below=20 > snmpModules (and perhaps this can then be documented in the=20 > IANA documents so we don't forget about this and we can make=20 > tools to check for this). >=20 I am OK with leaving it up to Dan. As I stated, I can live with it. It only seems we are not consistent with the messages we give in RFC4181. > I am fine with changing tsmMIB to snmpTsmMIB. >=20 Thanks. Adds to our consistency I think. > > - tsmInvalidCache OBJECT-TYPE > > SYNTAX Counter32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION "The number of messages dropped because the > > tmStateReference referred to an invalid cache. > >=20 > > This value is not persistent across reboots. > > " > > ::=3D { tsmStats 1 } >=20 > Perhaps rename to tsmInvalidCacheReferences? >=20 sounds good > > tsmInadequateSecurity OBJECT-TYPE > > SYNTAX Counter32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION "The number of incoming messages dropped because > > the actual securityLevel provided was less than > > the requested securityLevel. > >=20 > > This value is not persistent across reboots. > > " > > ::=3D { tsmStats 2 } >=20 > Perhaps rename to tsmInadequateSecurityLevels? >=20 sounds good > > According to our CLRs, the names/descriptors should=20 > express plurality. > > Not that I cannot live with them being named as is? Just=20 > that we as > > MIB doctors should probably follow our own CLRs. > >=20 > > I do not understand why we need to say something about=20 > "persistency"? > > We May want to state that discontinuties only can occur=20 > at a reboot > > or restart of the agent? >=20 > I suggest to simply drop the sentences about persistence=20 > since the default in SNMP land is that counters do not=20 > persist across reboots (or at least sysUpTime will indicate a=20 > discontinuity). >=20 THanks. That solves it for me. > > - I also see: > >=20 > > tsmGroups OBJECT IDENTIFIER ::=3D { tsmConformance 1 } > > tsmCompliances OBJECT IDENTIFIER ::=3D { tsmConformance 2 } > >=20 > >=20 > > While RFC4181 suggests: > >=20 > > xxxMIB > > | > > +-- xxxNotifications(0) > > +-- xxxObjects(1) > > +-- xxxConformance(2) > > | > > +-- xxxCompliances(1) > > +-- xxxGroups(2) > >=20 > > So first compliances, then groups. >=20 > OK, lets just flip the two things. >=20 Yes please. That would make us in accodance with rfc4181 and would be more consistent with other such definitions. > > - I get somehwat worried when following (In IANA Considerations > > section): > >=20 > > 2. a value, preferably 4, to identify the Transport=20 > Security Model, > > in the Security Models registry at > > http://www.iana.org/assignments/snmp-number-spaces. =20 > This should > >=20 > > Because if you go to=20 > http://www.iana.org/assignments/smi-numbers and > > search for "SNMP Management Architecture:" you will find=20 > that the=20 > > number > > space is listed there as well. So for now I guess IANA=20 > should update > > both locations. But probably it is best if theu only=20 > maintain it in=20 > > one > > place. > >=20 > > The http://www.iana.org/assignments/snmp-number-spaces=20 > uses current > > RFCs as references. The=20 > http://www.iana.org/assignments/smi-numbers > > uses > > old RFC226x as references. > >=20 > > I will report this "duplicate registry" issue to IANA seperately. >=20 > The duplicate registry needs to be worked out with IANA. >=20 I have been in discussion with IANA, and they fixed it. Iirc, then MIB doctors list was copied on the conversations. Bert > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Sep 12 02:58:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVM9o-0006ZC-Ug; Wed, 12 Sep 2007 02:57:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVM9o-0006Yu-7r for isms@ietf.org; Wed, 12 Sep 2007 02:57:04 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVM9m-0007sL-Ir for isms@ietf.org; Wed, 12 Sep 2007 02:57:04 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E66286515; Wed, 12 Sep 2007 08:57:01 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31654-07-5; Wed, 12 Sep 2007 08:56:55 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E2AA686428; Wed, 12 Sep 2007 08:56:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 22B2E335E0F; Wed, 12 Sep 2007 08:56:48 +0200 (CEST) Date: Wed, 12 Sep 2007 08:56:48 +0200 From: Juergen Schoenwaelder To: "tom.petch" Subject: Re: [Isms] Working Group Last Call tmsm-09 Message-ID: <20070912065648.GA18470@elstar.local> Mail-Followup-To: "tom.petch" , ISMS WG References: <00c701c7db25$8e0f78c0$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00c701c7db25$8e0f78c0$0601a8c0@pc6> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: ISMS WG X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Fri, Aug 10, 2007 at 09:36:34AM +0200, tom.petch wrote: > Eeee, reading this does not get any easier > > a) I would like to see more words on susbsystem/model/mapping since it has been > a > source of confusion on this list and is likely to be so to a wider audience. I > know that RFC3411 explains this point but I read that document several times > without getting it. I am looking at para. 2 towards the end. Where it says > "This document defines a Transport Subsystem extension" > that is ambiguous; an extension to the Transport Subsystem or an > extension to the architecture? and later it says > > "through an SNMP Transport Model [RFC3417]. Such a Transport Model " > well no; in the absence of a susbsystem, as now, there can be no model. > > I suggest the following instead > "The current RFC3411 architecture does not encompass transport (although RFC3417 > does define transport mappings). This document adds a transport subsystem, > based on the third approach, to the architecture, and this enables the use of > existing security mechanisms such as TLS [RFC4346] or SSH [RFC4251] within the > enhanced RFC3411 architecture. > > A companion document [I-D.draft-ietf-isms-secshell-08] defines a transport model > which is based on SSH while [I-D.ietf-isms-transport-security-model] defines a > security model which uses this approach" > > (I am a believer in stating the obvious when that may not be obvious to someone > who has not been following isms for four years:-). good suggestion - editorial > b) 3.2.1.1 /is/in/ editorial > c) 3.2.1.2 I think that the transport model MUST be aware of the mapping between > securityName and transportspecificName else how can it select the right > transport? I think an SNMP application passed the transportDomain and transportAddress to the dispatcher in the sendPdu() ASI and hence the dispatcher knows the transport to be used. Or was your point that you want the text If a message is secured using a secure transport layer, then the Transport Model should provide the translation from the authenticated identity (e.g., an SSH user name) to the securityName in step 3. to be changed such that it reads If a message is secured using a secure transport layer, then the Transport Model provides the translation from the authenticated identity (e.g., an SSH user name) to the securityName in step 2. > d) ... and that is in step 2 not step 3. editorial > e) 3.3.1 is the use of 'agent' here wilful? I notice that the term is banned in > 'transport-security-model' editorial > f) 3.3.2 would seem to preclude the renegotiation of keys, a recommended > practice during a long running session. Suggest a rewording of the two > sentences starting 'Cryptographic keys ...' to > > "Fresh session keys should be established at the beginning of each session in > order to provide authentication, integrity and confidentiality, whichever of > these services are required." As technical contributor, I am actually uneasy with both the existing text and the suggested improvement since there are cases where you really like to use session resumption due to the very short lifetime of the underlying connections and the computational costs associated with creating session keys. Perhaps we should just state that the transport model should have a feature to establish and renegotiate session keys instead of requiring this to happen at the beginning of each session. > g) 4 /pdutype/pduType/ editorial > h) 5.2 'The tmStateReference captured > during processing of an incoming message SHOULD include a transport- > specific session identifier.' > > I think that the nature of this identifier MUST be specified, either in the > security or transport model. Getting it wrong invalidates the security and it > is not obvious what it should; the right answers for TLS and SSH are quite > different. I do not see why this needs to be specified - this identifier never leaves the agent and is thus purely internal to the implementation and the precise format of this identifier actually to some extend also depends on the libraries that you use. Sure, the TSM and the *TMs need to agree on the format of these identifiers so that they do not mix up identifiers but I as a technical contributor consider this implementation detail. (We use magic numbers at the beginning of a struct to deal with this but I believe this is implementation detail.) > i) > 'The Transport Subsystem architecture document will reflect the SNMPv3 > WG's decision that **architecturally** this is a SHOULD. > The decision is security-model-dependent, and the Transport Security > Model will make it a MUST.' > > I am still seeing a 'MUST' in this section. Dave Harrington, can you please check? > j) 6.2 I am still puzzled by the absence of prepareResponseMessage and cannot > see how it works without it Dave Harrington, can you please look at this? I think Tom makes a point that prepareResponseMessage should also have an OUT tmStateReference. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Sep 12 10:21:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVT4h-00010I-1a; Wed, 12 Sep 2007 10:20:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVT4f-000107-Hx for isms@ietf.org; Wed, 12 Sep 2007 10:20:13 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVT4e-0008PE-7s for isms@ietf.org; Wed, 12 Sep 2007 10:20:13 -0400 Received: from pc6 (1Cust86.tnt2.lnd4.gbr.da.uu.net [62.188.131.86]) by galaxy.systems.pipex.net (Postfix) with SMTP id 3254BE00097E; Wed, 12 Sep 2007 15:20:06 +0100 (BST) Message-ID: <077801c7f53e$c4ce9980$0601a8c0@pc6> From: "tom.petch" To: , "Romascanu, Dan (Dan)" References: <20070911080452.GF16313@elstar.local> Subject: Re: [Isms] WGLC comments -draft-ietf-isms-transport-security-model-05.txt Date: Wed, 12 Sep 2007 15:07:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -101.0 (---------------------------------------------------) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Romascanu, Dan (Dan)" Cc: Sent: Tuesday, September 11, 2007 10:04 AM Subject: Re: [Isms] WGLC comments -draft-ietf-isms-transport-security-model-05.txt > On Thu, Aug 09, 2007 at 01:56:23PM +0200, Romascanu, Dan (Dan) wrote: > > > > 1. Is RFC 2828 referred by other security-related documents? I find this > > document problematic, there is a revision on the table IESG table that > > has also problems and I decided that I cannot support it because among > > other inadequate terminology concerning SNMP and management aspects. The > > way it is mentioned in Section 1.2 may be interpreted that with the > > right timing this document could be relevant, which is not the case IMO. > > I would either ignore it, or just mention that the terminology in this > > document is not intended to be consistent with RFC 2828. > > There seems to be consensus that it is fine to stick with the SNMP > terminology here. Furthermore, it seems we are doing better if we > avoid an explicit reference to RFC 2828 since there is an update > pending. So I propose that David wordsmiths the text to say we use > SNMP terminology and to avoid explicit references to sources of other > terminology. > RFC4949 has indeed superseded RFC2828 and I now understand that the former lacks the community support enjoyed by the latter so I am content for the explicit reference to an RFC to be omitted, keeping David's text about using terminology consistent with STD62, something like 'This document favors terminology consistency with the existing IETF SNMPv3 Standard (STD62) particularly with regard to security. This is consistent with the IESG decision not to require the SNMPv3 terminology be modified to reflect more recent developments when SNMPv3From isms-bounces@lists.ietf.org Wed Sep 12 10:21:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVT4h-00010I-1a; Wed, 12 Sep 2007 10:20:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVT4f-000107-Hx for isms@ietf.org; Wed, 12 Sep 2007 10:20:13 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVT4e-0008PE-7s for isms@ietf.org; Wed, 12 Sep 2007 10:20:13 -0400 Received: from pc6 (1Cust86.tnt2.lnd4.gbr.da.uu.net [62.188.131.86]) by galaxy.systems.pipex.net (Postfix) with SMTP id 3254BE00097E; Wed, 12 Sep 2007 15:20:06 +0100 (BST) Message-ID: <077801c7f53e$c4ce9980$0601a8c0@pc6> From: "tom.petch" To: , "Romascanu, Dan (Dan)" References: <20070911080452.GF16313@elstar.local> Subject: Re: [Isms] WGLC comments -draft-ietf-isms-transport-security-model-05.txt Date: Wed, 12 Sep 2007 15:07:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -101.0 (---------------------------------------------------) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Romascanu, Dan (Dan)" Cc: Sent: Tuesday, September 11, 2007 10:04 AM Subject: Re: [Isms] WGLC comments -draft-ietf-isms-transport-security-model-05.txt > On Thu, Aug 09, 2007 at 01:56:23PM +0200, Romascanu, Dan (Dan) wrote: > > > > 1. Is RFC 2828 referred by other security-related documents? I find this > > document problematic, there is a revision on the table IESG table that > > has also problems and I decided that I cannot support it because among > > other inadequate terminology concerning SNMP and management aspects. The > > way it is mentioned in Section 1.2 may be interpreted that with the > > right timing this document could be relevant, which is not the case IMO. > > I would either ignore it, or just mention that the terminology in this > > document is not intended to be consistent with RFC 2828. > > There seems to be consensus that it is fine to stick with the SNMP > terminology here. Furthermore, it seems we are doing better if we > avoid an explicit reference to RFC 2828 since there is an update > pending. So I propose that David wordsmiths the text to say we use > SNMP terminology and to avoid explicit references to sources of other > terminology. > RFC4949 has indeed superseded RFC2828 and I now understand that the former lacks the community support enjoyed by the latter so I am content for the explicit reference to an RFC to be omitted, keeping David's text about using terminology consistent with STD62, something like 'This document favors terminology consistency with the existing IETF SNMPv3 Standard (STD62) particularly with regard to security. This is consistent with the IESG decision not to require the SNMPv3 terminology be modified to reflect more recent developments when SNMPv3 was advanced to Full Standard.' I find this hard to write, needing to be clear what is being alluded to without setting a load of hares running in all directions; needs to be coy but not too coy. Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Sep 12 10:21:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVT4l-00012M-Bw; Wed, 12 Sep 2007 10:20:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVT4k-000127-PG for isms@ietf.org; Wed, 12 Sep 2007 10:20:18 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVT4j-0008Pm-II for isms@ietf.org; Wed, 12 Sep 2007 10:20:18 -0400 Received: from pc6 (1Cust86.tnt2.lnd4.gbr.da.uu.net [62.188.131.86]) by galaxy.systems.pipex.net (Postfix) with SMTP id B3EB3E00097E; Wed, 12 Sep 2007 15:20:13 +0100 (BST) Message-ID: <077a01c7f53e$c7e37aa0$0601a8c0@pc6> From: "tom.petch" To: , "Wijnen, Bert (Bert)" References: <20070911070217.GB16313@elstar.local> Subject: Re: [Isms] Re: tmStateReference in draft-ietf-isms-tmsm-09.txt Date: Wed, 12 Sep 2007 15:10:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -101.0 (---------------------------------------------------) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Wijnen, Bert (Bert)" Cc: Sent: Tuesday, September 11, 2007 9:02 AM Subject: [Isms] Re: tmStateReference in draft-ietf-isms-tmsm-09.txt > On Wed, Aug 08, 2007 at 12:17:56PM +0200, Wijnen, Bert (Bert) wrote: > > > I am confused by the last 2 paragraphs in sect 6.2 > > > > The prepareOutgoingMessage ASI passes tmStateReference from the > > Message Processing Subsystem to the dispatcher. How or if the > > Message Processing Subsystem modifies or utilizes the contents of the > > cache is message-processing-model-specific. > > > > This may sound underspecified, but keep in mind that a message > > processing model might have access to all the information from the > > cache and from the message, and have no need to call a Security Model > > to do any processing; an application might choose a Security Model > > such as USM to authenticate and secure the SNMP message, but also > > utilize a secure transport such as that provided by the SSH Transport > > Model to send the message to its destination. > > > > specifically the wording "an application...". > > Applications in our RFC3411 context are CG or CR or NO or NR or such. > > I am sure that is not intended here. But then, what is an "application" > > in this sentence above? > > Bert I am puzzled that you are confused:-) I read "an application" in this cont was advanced to Full Standard.' I find this hard to write, needing to be clear what is being alluded to without setting a load of hares running in all directions; needs to be coy but not too coy. Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Sep 12 10:21:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVT4l-00012M-Bw; Wed, 12 Sep 2007 10:20:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVT4k-000127-PG for isms@ietf.org; Wed, 12 Sep 2007 10:20:18 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVT4j-0008Pm-II for isms@ietf.org; Wed, 12 Sep 2007 10:20:18 -0400 Received: from pc6 (1Cust86.tnt2.lnd4.gbr.da.uu.net [62.188.131.86]) by galaxy.systems.pipex.net (Postfix) with SMTP id B3EB3E00097E; Wed, 12 Sep 2007 15:20:13 +0100 (BST) Message-ID: <077a01c7f53e$c7e37aa0$0601a8c0@pc6> From: "tom.petch" To: , "Wijnen, Bert (Bert)" References: <20070911070217.GB16313@elstar.local> Subject: Re: [Isms] Re: tmStateReference in draft-ietf-isms-tmsm-09.txt Date: Wed, 12 Sep 2007 15:10:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -101.0 (---------------------------------------------------) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Wijnen, Bert (Bert)" Cc: Sent: Tuesday, September 11, 2007 9:02 AM Subject: [Isms] Re: tmStateReference in draft-ietf-isms-tmsm-09.txt > On Wed, Aug 08, 2007 at 12:17:56PM +0200, Wijnen, Bert (Bert) wrote: > > > I am confused by the last 2 paragraphs in sect 6.2 > > > > The prepareOutgoingMessage ASI passes tmStateReference from the > > Message Processing Subsystem to the dispatcher. How or if the > > Message Processing Subsystem modifies or utilizes the contents of the > > cache is message-processing-model-specific. > > > > This may sound underspecified, but keep in mind that a message > > processing model might have access to all the information from the > > cache and from the message, and have no need to call a Security Model > > to do any processing; an application might choose a Security Model > > such as USM to authenticate and secure the SNMP message, but also > > utilize a secure transport such as that provided by the SSH Transport > > Model to send the message to its destination. > > > > specifically the wording "an application...". > > Applications in our RFC3411 context are CG or CR or NO or NR or such. > > I am sure that is not intended here. But then, what is an "application" > > in this sentence above? > > Bert I am puzzled that you are confused:-) I read "an application" in this context as meaning eg a CG or NO. RFC3411 4.1.1. 'The PDU Dispatcher provides the following primitive for an application to send an SNMP Request or Notification to another SNMP entity:' ....... ' IN transportDomain -- transport domain to be used IN transportAddress -- transport address to be used IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model to use' so the application chooses the securityModel and secure transport; I see no problem with the text. Removing the paragraph removes the mention of USM over secure transport. OK, this combination is problematic, as has been pointed out already, but if the conclusion is that it is impossible, then I would like that explicit, not implicit in the removal of a paragraph. > > I am also not sure we should speak about the MPM to "not call a > > security model". From our architectural point of view, the MPM > > will ALWAYS call a security model. If an implementation does a > > shortcut, that is up to them... but should we discuss that here? > > I agree, calling the SM should be mandatory even if it is no-op. > > I am similarly confused by the "an application..." in section 6.4 > > last paragraph. > Again, I am puzzled that you are confused; this paragraph makes sense to me. Tom Petch > I am wondering whether this issue can be solved by simply deleting the > second quoted paragraph since I am not sure it adds value. > > /js > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms ext as meaning eg a CG or NO. RFC3411 4.1.1. 'The PDU Dispatcher provides the following primitive for an application to send an SNMP Request or Notification to another SNMP entity:' ....... ' IN transportDomain -- transport domain to be used IN transportAddress -- transport address to be used IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model to use' so the application chooses the securityModel and secure transport; I see no problem with the text. Removing the paragraph removes the mention of USM over secure transport. OK, this combination is problematic, as has been pointed out already, but if the conclusion is that it is impossible, then I would like that explicit, not implicit in the removal of a paragraph. > > I am also not sure we should speak about the MPM to "not call a > > security model". From our architectural point of view, the MPM > > will ALWAYS call a security model. If an implementation does a > > shortcut, that is up to them... but should we discuss that here? > > I agree, calling the SM should be mandatory even if it is no-op. > > I am similarly confused by the "an application..." in section 6.4 > > last paragraph. > Again, I am puzzled that you are confused; this paragraph makes sense to me. Tom Petch > I am wondering whether this issue can be solved by simply deleting the > second quoted paragraph since I am not sure it adds value. > > /js > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Sep 12 12:13:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVUog-0002AK-H3; Wed, 12 Sep 2007 12:11:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVUof-000297-6k for isms@ietf.org; Wed, 12 Sep 2007 12:11:49 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVUoe-0008QC-R4 for isms@ietf.org; Wed, 12 Sep 2007 12:11:49 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CE6E86566; Wed, 12 Sep 2007 18:11:47 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 23554-06-9; Wed, 12 Sep 2007 18:11:42 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 29D428654E; Wed, 12 Sep 2007 18:11:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 623443368A6; Wed, 12 Sep 2007 18:11:29 +0200 (CEST) Date: Wed, 12 Sep 2007 18:11:29 +0200 From: Juergen Schoenwaelder To: "Wijnen, Bert (Bert)" Message-ID: <20070912161129.GA19711@elstar.local> Mail-Followup-To: "Wijnen, Bert (Bert)" , David Harrington , isms@ietf.org References: <20070911070217.GB16313@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: isms@ietf.org Subject: [Isms] Re: tmStateReference in draft-ietf-isms-tmsm-09.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Tue, Sep 11, 2007 at 10:34:52AM +0200, Wijnen, Bert (Bert) wrote: > > I am wondering whether this issue can be solved by simply > > deleting the second quoted paragraph since I am not sure it > > adds value. > > > > That would do it for me. > But iirc, DBH thinks it is important. > I am not hung up on it. But I stay confused if it is kept. > > Removing the 2nd para above, does still leave the > use of "an application.." in sect 6.4, right? Perhaps this paragraph can go as well. There is a more general question concerning combinations such as USM over SSH which I think comes up in another thread and perhaps we need explicit text about this that will allow us to replace these two paragraphs. But I have to re-read the other threads again first... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 13 02:56:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVibA-0003R9-0s; Thu, 13 Sep 2007 02:54:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVib7-0003P9-TV for isms@ietf.org; Thu, 13 Sep 2007 02:54:45 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVib6-0004yb-K1 for isms@ietf.org; Thu, 13 Sep 2007 02:54:45 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l8D6r1UF008575; Thu, 13 Sep 2007 01:54:35 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 01:53:46 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 08:53:44 +0200 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] Re: tmStateReference in draft-ietf-isms-tmsm-09.txt Date: Thu, 13 Sep 2007 08:53:35 +0200 Message-ID: In-Reply-To: <077a01c7f53e$c7e37aa0$0601a8c0@pc6> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Re: tmStateReference in draft-ietf-isms-tmsm-09.txt Thread-Index: Acf1SBGBcRNF3fPcSAuox3zIxxqGdwAio1ZQ References: <20070911070217.GB16313@elstar.local> <077a01c7f53e$c7e37aa0$0601a8c0@pc6> From: "Wijnen, Bert \(Bert\)" To: "tom.petch" , X-OriginalArrivalTime: 13 Sep 2007 06:53:44.0374 (UTC) FILETIME=[D3811D60:01C7F5D2] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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 Maybe I read/interpreted "an application may use.." instead of "an application may choose....". Even so, if we DO mean NO or CG, then maybe we should say that, that takes away at least some of the potential confusion in my mind. But I have to go reread/study now that I see your comments. Bert Wijnen =20 > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com]=20 > Sent: Wednesday, September 12, 2007 3:11 PM > To: j.schoenwaelder@jacobs-university.de; Wijnen, Bert (Bert) > Cc: isms@ietf.org > Subject: Re: [Isms] Re: tmStateReference in=20 > draft-ietf-isms-tmsm-09.txt >=20 > > Tom Petch >=20 > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "Wijnen, Bert (Bert)" > Cc: > Sent: Tuesday, September 11, 2007 9:02 AM > Subject: [Isms] Re: tmStateReference in draft-ietf-isms-tmsm-09.txt >=20 >=20 > > On Wed, Aug 08, 2007 at 12:17:56PM +0200, Wijnen, Bert (Bert) wrote: > > > > > I am confused by the last 2 paragraphs in sect 6.2 > > > > > > The prepareOutgoingMessage ASI passes tmStateReference from the > > > Message Processing Subsystem to the dispatcher. How or if the > > > Message Processing Subsystem modifies or utilizes the=20 > contents of the > > > cache is message-processing-model-specific. > > > > > > This may sound underspecified, but keep in mind that a message > > > processing model might have access to all the=20 > information from the > > > cache and from the message, and have no need to call a=20 > Security Model > > > to do any processing; an application might choose a=20 > Security Model > > > such as USM to authenticate and secure the SNMP=20 > message, but also > > > utilize a secure transport such as that provided by=20 > the SSH Transport > > > Model to send the message to its destination. > > > > > > specifically the wording "an application...". > > > Applications in our RFC3411 context are CG or CR or NO or=20 > NR or such. > > > I am sure that is not intended here. But then, what is an=20 > "application" > > > in this sentence above? > > > >=20 > Bert >=20 > I am puzzled that you are confused:-) I read "an=20 > application" in this context as meaning eg a CG or NO. RFC3411 4.1.1. > 'The PDU Dispatcher provides the following primitive for an > application to send an SNMP Request or Notification to=20 > another SNMP entity:' > ....... > ' IN transportDomain -- transport domain to be used > IN transportAddress -- transport address to be used > IN messageProcessingModel -- typically, SNMP version > IN securityModel -- Security Model to use' > so the application chooses the securityModel and secure=20 > transport; I see no problem with the text. >=20 > Removing the paragraph removes the mention of USM over secure=20 > transport. OK, this combination is problematic, as has been=20 > pointed out already, but if the conclusion is that it is=20 > impossible, then I would like that explicit, not implicit in=20 > the removal of a paragraph. >=20 > > > I am also not sure we should speak about the MPM to "not call a=20 > > > security model". From our architectural point of view,=20 > the MPM will=20 > > > ALWAYS call a security model. If an implementation does a=20 > shortcut,=20 > > > that is up to them... but should we discuss that here? > > > >=20 > I agree, calling the SM should be mandatory even if it is no-op. >=20 > > > I am similarly confused by the "an application..." in section 6.4=20 > > > last paragraph. > > >=20 > Again, I am puzzled that you are confused; this paragraph=20 > makes sense to me. >=20 > Tom Petch >=20 > > I am wondering whether this issue can be solved by simply=20 > deleting the=20 > > second quoted paragraph since I am not sure it adds value. > > > > /js > > >=20 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 13 08:01:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnOG-0006Jk-JM; Thu, 13 Sep 2007 08:01:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnOE-0006JB-15 for isms@ietf.org; Thu, 13 Sep 2007 08:01:47 -0400 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVnOC-00028l-NQ for isms@ietf.org; Thu, 13 Sep 2007 08:01:46 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc14) with SMTP id <20070913120143m1400je9ufe>; Thu, 13 Sep 2007 12:01:43 +0000 From: "David Harrington" To: "'Wijnen, Bert \(Bert\)'" , "'tom.petch'" , References: <20070911070217.GB16313@elstar.local><077a01c7f53e$c7e37aa0$0601a8c0@pc6> Subject: RE: [Isms] Re: tmStateReference in draft-ietf-isms-tmsm-09.txt Date: Thu, 13 Sep 2007 08:01:30 -0400 Message-ID: <00ab01c7f5fd$d2eb1060$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf1SBGBcRNF3fPcSAuox3zIxxqGdwAio1ZQAApYKaA= In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, I suspect your confusion is between a "software application" and an "SNMP application". A software application might be a commercial NMS product that utilizes the services of an SNMP stack (or contains an SNMP stack), whereas an SNMP application is within the SNMP stack. In reality, it is very possible that neither chooses anything; it might be an operator that makes the choice, and he tells the software application what to use, and then the software application tells the SNMP application what to use, and the SNMP application tells the SNMP engine what to use. Let's take choice out of the issue. I changed an "application chooses" to an "application specifies". Now it really makes no difference whether that is the software application specifying or the SNMP application specifying; they work togethet to pass the choice into the system. Overloading terms often leads to ambiguity. But the SNMPv3 WG chose application over other non-overloaded terminology (such as orangelet). Now we have to live with the decision. I believe it would be inappropriate to change "application" to "NO or CG" since there are other applications already defined (proxy) and the framework permits additional applications to be added. We should not inadvertently constrain the framework by saying that it must be an NO or a CG specifying this information. dbh > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > Sent: Thursday, September 13, 2007 2:54 AM > To: tom.petch; j.schoenwaelder@jacobs-university.de > Cc: isms@ietf.org > Subject: RE: [Isms] Re: tmStateReference in > draft-ietf-isms-tmsm-09.txt > > Maybe I read/interpreted "an application may use.." instead of "an > application may choose....". > > Even so, if we DO mean NO or CG, then maybe we should say that, > that takes away at least some of the potential confusion in my > mind. But I have to go reread/study now that I see your comments. > > Bert Wijnen > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Wednesday, September 12, 2007 3:11 PM > > To: j.schoenwaelder@jacobs-university.de; Wijnen, Bert (Bert) > > Cc: isms@ietf.org > > Subject: Re: [Isms] Re: tmStateReference in > > draft-ietf-isms-tmsm-09.txt > > > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Juergen Schoenwaelder" > > To: "Wijnen, Bert (Bert)" > > Cc: > > Sent: Tuesday, September 11, 2007 9:02 AM > > Subject: [Isms] Re: tmStateReference in draft-ietf-isms-tmsm-09.txt > > > > > > > On Wed, Aug 08, 2007 at 12:17:56PM +0200, Wijnen, Bert > (Bert) wrote: > > > > > > > I am confused by the last 2 paragraphs in sect 6.2 > > > > > > > > The prepareOutgoingMessage ASI passes > tmStateReference from the > > > > Message Processing Subsystem to the dispatcher. How > or if the > > > > Message Processing Subsystem modifies or utilizes the > > contents of the > > > > cache is message-processing-model-specific. > > > > > > > > This may sound underspecified, but keep in mind that > a message > > > > processing model might have access to all the > > information from the > > > > cache and from the message, and have no need to call a > > Security Model > > > > to do any processing; an application might choose a > > Security Model > > > > such as USM to authenticate and secure the SNMP > > message, but also > > > > utilize a secure transport such as that provided by > > the SSH Transport > > > > Model to send the message to its destination. > > > > > > > > specifically the wording "an application...". > > > > Applications in our RFC3411 context are CG or CR or NO or > > NR or such. > > > > I am sure that is not intended here. But then, what is an > > "application" > > > > in this sentence above? > > > > > > > > Bert > > > > I am puzzled that you are confused:-) I read "an > > application" in this context as meaning eg a CG or NO. > RFC3411 4.1.1. > > 'The PDU Dispatcher provides the following primitive for an > > application to send an SNMP Request or Notification to > > another SNMP entity:' > > ....... > > ' IN transportDomain -- transport domain to be used > > IN transportAddress -- transport address to be used > > IN messageProcessingModel -- typically, SNMP version > > IN securityModel -- Security Model to use' > > so the application chooses the securityModel and secure > > transport; I see no problem with the text. > > > > Removing the paragraph removes the mention of USM over secure > > transport. OK, this combination is problematic, as has been > > pointed out already, but if the conclusion is that it is > > impossible, then I would like that explicit, not implicit in > > the removal of a paragraph. > > > > > > I am also not sure we should speak about the MPM to "not call a > > > > security model". From our architectural point of view, > > the MPM will > > > > ALWAYS call a security model. If an implementation does a > > shortcut, > > > > that is up to them... but should we discuss that here? > > > > > > > > I agree, calling the SM should be mandatory even if it is no-op. > > > > > > I am similarly confused by the "an application..." in > section 6.4 > > > > last paragraph. > > > > > > > Again, I am puzzled that you are confused; this paragraph > > makes sense to me. > > > > Tom Petch > > > > > I am wondering whether this issue can be solved by simply > > deleting the > > > second quoted paragraph since I am not sure it adds value. > > > > > > /js > > > > > > > > > _______________________________________________ > 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 Sep 13 08:18:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnef-0001cR-Hn; Thu, 13 Sep 2007 08:18:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnee-0001cH-Qi for isms@ietf.org; Thu, 13 Sep 2007 08:18:44 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVned-0002nz-JP for isms@ietf.org; Thu, 13 Sep 2007 08:18:44 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc12) with SMTP id <20070913121842m1200fdu4ke>; Thu, 13 Sep 2007 12:18:42 +0000 From: "David Harrington" To: , "'tom.petch'" References: <00c701c7db25$8e0f78c0$0601a8c0@pc6> <20070912065648.GA18470@elstar.local> Subject: RE: [Isms] Working Group Last Call tmsm-09 Date: Thu, 13 Sep 2007 08:18:29 -0400 Message-ID: <00b501c7f600$32133160$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf1Cl/atCA20/hlRlOJUjkf6xHuLQA9Lx3g In-Reply-To: <20070912065648.GA18470@elstar.local> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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'm getting a little short-tempered about what i consider to be some pretty ridiciulous editorial changes, and I'm going to let it show. Ask yourself a question - does the requested change make it easier for an implementer to implement the specification or an operator to manage their network? if not, why are we wasting time? I think we may have already lost all the "customers" that wanted this solution while we waste time dotting i's and crossing t's. They want to be abel to use this technology to manage their networks! > I am looking at para. 2 towards the > end. Where it says > > "This document defines a Transport Subsystem extension" > > that is ambiguous; an extension to the Transport Subsystem or an > > extension to the architecture? Let's look at the phrase you were looking at - with the "to" included: "This document defines a Transport Subsystem extension to the RFC3411 architecture based on the third approach." Doesn't that answer the question already? Does changing this to "This document adds a transport subsystem, based on the third approach, to the architecture, ..." make it easier to manage a network securely? David Harrington dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 13 08:51:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVo9u-0000Zf-7n; Thu, 13 Sep 2007 08:51:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVo9t-0000ZU-4m for isms@ietf.org; Thu, 13 Sep 2007 08:51:01 -0400 Received: from alnrmhc16.comcast.net ([206.18.177.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVo9s-0004Wp-N8 for isms@ietf.org; Thu, 13 Sep 2007 08:51:00 -0400 Received: from newton603 (c-24-61-11-96.hsd1.nh.comcast.net[24.61.11.96]) by comcast.net (alnrmhc16) with SMTP id <20070913125059b1600bnjcme>; Thu, 13 Sep 2007 12:50:59 +0000 From: "David B. Nelson" To: "'ISMS WG'" References: <00c701c7db25$8e0f78c0$0601a8c0@pc6><20070912065648.GA18470@elstar.local> <00b501c7f600$32133160$6702a8c0@china.huawei.com> Subject: RE: [Isms] Working Group Last Call tmsm-09 Date: Thu, 13 Sep 2007 08:50:58 -0400 Message-ID: <016e01c7f604$bb5b1880$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf1Cl/atCA20/hlRlOJUjkf6xHuLQA9Lx3gAAEZOLA= In-Reply-To: <00b501c7f600$32133160$6702a8c0@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org David Harrington writes... > I'm getting a little short-tempered about what i consider to > be some pretty ridiculous editorial changes, and I'm going > to let it show. > ...why are we wasting time? I think we may have already lost > all the "customers" that wanted this solution while we > waste time dotting i's and crossing t's. Apparently trivial editorial changes can be annoying. OTOH, the document editor has editorial discretion with respect to the draft. WG consensus is [only] required for technical changes. The editor is expected to process all _reasonable_ comments. As to the timeliness of our work product, I don't think we can lay that issue at the feet of a few [trivial] editorial comments, coming in late during WGLC. That has more to do with the WG participants' rate of coming to closure on some major issues. That ship has sailed. I don't think we need to reject _meaningful_ editorial comments, at this point in time, solely on that basis. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 13 10:12:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVpQc-0003js-IM; Thu, 13 Sep 2007 10:12:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVpQb-0003iL-0E for isms@ietf.org; Thu, 13 Sep 2007 10:12:21 -0400 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVpQa-0006fv-G8 for isms@ietf.org; Thu, 13 Sep 2007 10:12:20 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc13) with SMTP id <20070913141219m13000kat3e>; Thu, 13 Sep 2007 14:12:19 +0000 From: "David Harrington" To: , "'tom.petch'" References: <00c701c7db25$8e0f78c0$0601a8c0@pc6> <20070912065648.GA18470@elstar.local> Subject: RE: [Isms] Working Group Last Call tmsm-09 Date: Thu, 13 Sep 2007 10:12:06 -0400 Message-ID: <00c501c7f610$116d16a0$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf1Cl/atCA20/hlRlOJUjkf6xHuLQA/Tqsw In-Reply-To: <20070912065648.GA18470@elstar.local> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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 disagree with the follwoing proposed text: > > I suggest the following instead > > "The current RFC3411 architecture does not encompass > transport (although RFC3417 > > does define transport mappings). This document adds a > transport subsystem, > > based on the third approach, to the architecture, and this > enables the use of > > existing security mechanisms such as TLS [RFC4346] or SSH > [RFC4251] within the > > enhanced RFC3411 architecture. > > First, I disagree with "The current RFC3411 architecture" - as compared to what? the future RFC3411 architecture? The RFC3411 architecture is cast in stone. It will never change. We are updating the architecure, and when this is published (if we ever get past all the i's and t's and get it submitted to the IESG), it will be the RFCXXXX architecture. "The current RFC3411 architecture does not encompass transport" Then what is the box labeled "Transport Mappings" in the diagram in RFc3411 section 2? Why does RFC3411 have a subsection entitiled "Transport Mappings"? What is the "Transport Mappings" in the diagram in section 3.1.3.1 and 3.1.3.2? Why is transport mentioned in every ASI? Of course it encompasses transport. It just doesn't use a formal subsystem to do so. The abstract of TMSM explains that we are adding a transport subsystem: "This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models, comparable to other subsystems in the RFC3411 architecture. As work is being done to expand the transport to include secure transport such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP." I do not quite agree that "this > enables the use of existing security mechanisms such as TLS [RFC4346] or SSH > [RFC4251]...." We could have simply used transport mappings for SSH and TLS. We did not need a subsystem to enable this. We chose to add a subsystem (and models) to make the transport terminology consistent with other portions of the architecure, and to enable consistent design and modularity of transport models. Transport mappings and transport models are effectively the same thing; newer "models" might pass transport-specific security parameters to other subsystems in the architecture. See the text in section 2.1: "The transport mappings defined in RFC3417 do not provide lower-layer security functionality, and thus do not provide transport-specific security parameters. This document updates RFC3411 and RFC3417 by defining an architectural extension and ASIs that transport mappings (models) can use to pass transport-specific security parameters to other subsystems, including transport-specific security parameters translated into the transport-independent securityName and securityLevel." I think thatis pretty clear and unambiguous, myself. David Harrington dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 13 15:26:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVuKt-0002OT-DD; Thu, 13 Sep 2007 15:26:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVuKr-0002GH-Om for isms@ietf.org; Thu, 13 Sep 2007 15:26:45 -0400 Received: from rwcrmhc15.comcast.net ([216.148.227.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVuKq-0004cm-EM for isms@ietf.org; Thu, 13 Sep 2007 15:26:45 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc15) with SMTP id <20070913192643m1500c6ihje>; Thu, 13 Sep 2007 19:26:43 +0000 From: "David Harrington" To: , "'tom.petch'" References: <00c701c7db25$8e0f78c0$0601a8c0@pc6> <20070912065648.GA18470@elstar.local> Subject: RE: [Isms] Working Group Last Call tmsm-09 Date: Thu, 13 Sep 2007 15:26:29 -0400 Message-ID: <011301c7f63b$fce6dc80$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf1Cl/atCA20/hlRlOJUjkf6xHuLQBHEfgg In-Reply-To: <20070912065648.GA18470@elstar.local> X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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, Here are my responses, inline. > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, September 12, 2007 2:57 AM > To: tom.petch > Cc: ISMS WG > Subject: Re: [Isms] Working Group Last Call tmsm-09 > > On Fri, Aug 10, 2007 at 09:36:34AM +0200, tom.petch wrote: > > Eeee, reading this does not get any easier > > > > a) I would like to see more words on > susbsystem/model/mapping since it has been > > a > > source of confusion on this list and is likely to be so to > a wider audience. I > > know that RFC3411 explains this point but I read that > document several times > > without getting it. I am looking at para. 2 towards the > end. Where it says > > "This document defines a Transport Subsystem extension" > > that is ambiguous; an extension to the Transport Subsystem or an > > extension to the architecture? and later it says > > > > "through an SNMP Transport Model [RFC3417]. Such a > Transport Model " > > well no; in the absence of a susbsystem, as now, there can > be no model. > > > > I suggest the following instead > > "The current RFC3411 architecture does not encompass > transport (although RFC3417 > > does define transport mappings). This document adds a > transport subsystem, > > based on the third approach, to the architecture, and this > enables the use of > > existing security mechanisms such as TLS [RFC4346] or SSH > [RFC4251] within the > > enhanced RFC3411 architecture. > > > > A companion document [I-D.draft-ietf-isms-secshell-08] > defines a transport model > > which is based on SSH while > [I-D.ietf-isms-transport-security-model] defines a > > security model which uses this approach" > > > > (I am a believer in stating the obvious when that may not > be obvious to someone > > who has not been following isms for four years:-). > > good suggestion - editorial commented in a separate email. > > > b) 3.2.1.1 /is/in/ > > editorial done > > > c) 3.2.1.2 I think that the transport model MUST be aware > of the mapping between > > securityName and transportspecificName else how can it > select the right > > transport? > > I think an SNMP application passed the transportDomain and > transportAddress to the dispatcher in the sendPdu() ASI and hence the > dispatcher knows the transport to be used. Or was your point that you > want the text > > If a message is secured using a secure transport layer, then the > Transport Model should provide the translation from the > authenticated > identity (e.g., an SSH user name) to the securityName in step 3. > > to be changed such that it reads > > If a message is secured using a secure transport layer, then the > Transport Model provides the translation from the authenticated > identity (e.g., an SSH user name) to the securityName in step 2. > > > d) ... and that is in step 2 not step 3. > > editorial should is more accurate because it is possible that a future transport model might not provide this translation for a valid technical reason. Removing the should makes this an implicit MUST, which I believe is an unnecessary CLR. s/step 3/step 2/ done. > > > e) 3.3.1 is the use of 'agent' here wilful? I notice that > the term is banned in > > 'transport-security-model' > > editorial It was, but I modified it for consistency. > > > f) 3.3.2 would seem to preclude the renegotiation of keys, > a recommended > > practice during a long running session. Suggest a > rewording of the two > > sentences starting 'Cryptographic keys ...' to > > > > "Fresh session keys should be established at the beginning > of each session in > > order to provide authentication, integrity and > confidentiality, whichever of > > these services are required." > > As technical contributor, I am actually uneasy with both the existing > text and the suggested improvement since there are cases where you > really like to use session resumption due to the very short lifetime > of the underlying connections and the computational costs associated > with creating session keys. Perhaps we should just state that the > transport model should have a feature to establish and renegotiate > session keys instead of requiring this to happen at the beginning of > each session. I changed the text slightly: "Cryptographic keys associated with the transport session SHOULD be used to provide authentication, integrity checking, and encryption services, as needed, for data that is communicated during the session. The cryptographic protocols used to establish keys for a Transport Model session SHOULD ensure that fresh new session keys are generated for each session." I changed the first sentence to reflect that the keys were associated with the session, without saying when they were generated, and added the "as needed" clause to reflect that not all servcies are necessarily required for all transport models. I did not change the second sentence; the SHOULD permits the valid technical exception of support for session resumption, while still including the recommendation for the start of each session. (and session resumtpion presumably is resuming the same session.) > > > g) 4 /pdutype/pduType/ > > editorial done. > > > h) 5.2 'The tmStateReference captured > > during processing of an incoming message SHOULD include > a transport- > > specific session identifier.' > > > > I think that the nature of this identifier MUST be > specified, either in the > > security or transport model. Getting it wrong invalidates > the security and it > > is not obvious what it should; the right answers for TLS > and SSH are quite > > different. > > I do not see why this needs to be specified - this identifier never > leaves the agent and is thus purely internal to the implementation and > the precise format of this identifier actually to some extend also > depends on the libraries that you use. Sure, the TSM and the *TMs need > to agree on the format of these identifiers so that they do not mix up > identifiers but I as a technical contributor consider this > implementation detail. (We use magic numbers at the beginning of a > struct to deal with this but I believe this is implementation detail.) We could define a MIB, which is a virutal interface to an implementation-specific detail, and the implementation can totally choose to ignore our standardized interface, and it would make no difference on-the-wire. So I agree that we do not need to specify this. If you have an example of how this could be a security problem, I have no problem with you creating an implementer's note advising implementers to be sure the implementation in the security models and the implementation in the transport models agree on the format, but I would certainly like to have that note explain why this is necessary for security reasons. By the way, note the plurals, in case there are multiple SMs that can work with the same TM, or multiple TMs that can work with the same SM. And, of course, we would need consensus on the content of the note. > > > i) > > 'The Transport Subsystem architecture document will reflect > the SNMPv3 > > WG's decision that **architecturally** this is a SHOULD. > > The decision is security-model-dependent, and the Transport Security > > Model will make it a MUST.' > > > > I am still seeing a 'MUST' in this section. > > Dave Harrington, can you please check? I rewrote the tmStateReference section of each document, and the elements of procedure for each document, to clarify this. > > > j) 6.2 I am still puzzled by the absence of > prepareResponseMessage and cannot > > see how it works without it > > Dave Harrington, can you please look at this? I think Tom > makes a point that > prepareResponseMessage should also have an OUT tmStateReference. done. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 13 16:58:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVvlN-0004Gb-5Q; Thu, 13 Sep 2007 16:58:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVvlL-0004GU-3z for isms@ietf.org; Thu, 13 Sep 2007 16:58:11 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVvlJ-0007RV-Ox for isms@ietf.org; Thu, 13 Sep 2007 16:58:11 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc11) with SMTP id <20070913205808m11003nur3e>; Thu, 13 Sep 2007 20:58:08 +0000 From: "David Harrington" To: "'Wijnen, Bert \(Bert\)'" , References: <20070911072236.GC16313@elstar.local> Subject: RE: [Isms] my review of: Date: Thu, 13 Sep 2007 16:57:54 -0400 Message-ID: <011701c7f648$c21d3240$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf0RKAIYi60aOCbTkCM3qvcWtb3FQADA3gQAHswn1A= In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org comments inline dbh > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > Sent: Tuesday, September 11, 2007 4:52 AM > > > > > > > - ::= { snmpModules xxxx } > > > > > > Is there a good reason to put this underneath that > > snmpModules branch? > > > I do understand we have the snmpUsmMIB (so to be > > consistent this one > > > should be named snmpTsmMIB) and related MIB modules under > > snmpModules. > > > So from that point it makes sense. > > > > > > But we have stated (in RFC4181) that an OID is just an OID and > > > MIB modules should go under mib-2. > > > And we have no-where specified IANA guidelines as to how/when to > > > assign new values under snmpModules. > > > > > > I know that some other WG wants to put their MIB > modules under a > > > common branch of their own as well... and they are (as we speak) > > > getting push-back from our AD. > > > > The question is why we have snmpModules in the first place > > and whether we continue to root SNMP modules under > > snmpModules or treat them as all other modules. The > > SNMP-USM-AES-MIB was probably the last one rooted under > > snmpModules - so SNMP addons have been rooted in the not too > > distant past. I suggest Dan provides advise whether we > > continue to use snmpModules or declare that we declare > > snmpModules was a bad idea and we stop assigning things below > > snmpModules (and perhaps this can then be documented in the > > IANA documents so we don't forget about this and we can make > > tools to check for this). > > > > I am OK with leaving it up to Dan. > As I stated, I can live with it. > It only seems we are not consistent with the messages we give in > RFC4181. Lte's see, what should we consider? Does putting it under snmpModules or mib-2 make it easier to manage a network? Does putting it under snmpModules or mib-2 make it easier to implement? Does putting it under either one make it easier for IANA? Does putting it under one or the other make it easier for application developers? I think the major argument from my point of view is I am tired of having to change this back and forth. It makes no difference where we root it. Let's call it done so we can get the document submitted to the IESG and encourage people to implement and deploy it. > > > I am fine with changing tsmMIB to snmpTsmMIB. > > > > Thanks. Adds to our consistency I think. consistency with what? the sshtmMib does not have an snmp prefix. The RFC341x MIB modules all start with SNMP- and the module identities start with snmp, and all their objects start with snmpXXX, and they root under snmpModules. That is consistency. If we root this under mib-2 rather than an snmp-specific registration point, as per 4181, then I recommend we rename SNMP-SSH-TM-MIB to simply SSHTM-MIB to make it consistent with 4181 naming conventions, and to make it consistent with the module identity and the naming used throughout the module, which follows the naming conventions described in 4181. That would be consistent with RRFC4181. > > > > - tsmInvalidCache OBJECT-TYPE > > > SYNTAX Counter32 > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION "The number of messages dropped because the > > > tmStateReference referred to an invalid cache. > > > > > > This value is not persistent across reboots. > > > " > > > ::= { tsmStats 1 } > > > > Perhaps rename to tsmInvalidCacheReferences? > > > > sounds good The reference may be perfectly valid; it is the cache that is invalid. How should a manager interpret this counter? Is it better for the NMS to have us count the number of bad references to caches, or the number of good references to bad caches, or does the NMS need to monitor both of these error conditions? Note that having a counter for this implementation-specific error condition, whether we count bad references or bad caches, is adding DEBUG information to the NM information. I just edited the OPS&Mgmt draft where it was pointed out that debug info should NOT be part of the NM data. How will instrumenting this information and making it available to my NMS make the Internet run better? > > > > tsmInadequateSecurity OBJECT-TYPE > > > SYNTAX Counter32 > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION "The number of incoming messages > dropped because > > > the actual securityLevel provided was > less than > > > the requested securityLevel. > > > > > > This value is not persistent across reboots. > > > " > > > ::= { tsmStats 2 } > > > > Perhaps rename to tsmInadequateSecurityLevels? > > > > sounds good done. Wow! my network runs much better now. > > > > According to our CLRs, the names/descriptors should > > express plurality. > > > Not that I cannot live with them being named as is? Just > > that we as > > > MIB doctors should probably follow our own CLRs. done. Wow! my network runs much better now. That 's' on the end acts like grease on my data. > > > > > > I do not understand why we need to say something about > > "persistency"? > > > We May want to state that discontinuties only can occur > > at a reboot > > > or restart of the agent? > > > > I suggest to simply drop the sentences about persistence > > since the default in SNMP land is that counters do not > > persist across reboots (or at least sysUpTime will indicate a > > discontinuity). > > > > THanks. That solves it for me. Sigh. Bert, you are the AD that compained when people didn't discuss persistence. When I add a discussion of persistence, you want it removed. done. Now it is implicit rather than explicit; I hope that improves interoperability. > > > > - I also see: > > > > > > tsmGroups OBJECT IDENTIFIER ::= { tsmConformance 1 } > > > tsmCompliances OBJECT IDENTIFIER ::= { tsmConformance 2 } > > > > > > > > > While RFC4181 suggests: > > > > > > xxxMIB > > > | > > > +-- xxxNotifications(0) > > > +-- xxxObjects(1) > > > +-- xxxConformance(2) > > > | > > > +-- xxxCompliances(1) > > > +-- xxxGroups(2) > > > > > > So first compliances, then groups. > > > > OK, lets just flip the two things. > > > > Yes please. That would make us in accodance with rfc4181 and would > be more consistent with other such definitions. > Doh! That's why my network kept crashing! good catch. > > > - I get somehwat worried when following (In IANA Considerations > > > section): > > > > > > 2. a value, preferably 4, to identify the Transport > > Security Model, > > > in the Security Models registry at > > > http://www.iana.org/assignments/snmp-number-spaces. > > This should > > > > > > Because if you go to > > http://www.iana.org/assignments/smi-numbers and > > > search for "SNMP Management Architecture:" you will find > > that the > > > number > > > space is listed there as well. So for now I guess IANA > > should update > > > both locations. But probably it is best if theu only > > maintain it in > > > one > > > place. > > > > > > The http://www.iana.org/assignments/snmp-number-spaces > > uses current > > > RFCs as references. The > > http://www.iana.org/assignments/smi-numbers > > > uses > > > old RFC226x as references. > > > > > > I will report this "duplicate registry" issue to IANA > seperately. > > > > The duplicate registry needs to be worked out with IANA. > > > > I have been in discussion with IANA, and they fixed it. > Iirc, then MIB doctors list was copied on the conversations. Am I supposed to change something in the TSM document? > > Bert > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 13 18:38:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVxJx-0003Nx-5J; Thu, 13 Sep 2007 18:38:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVxJw-0003Ns-BZ for isms@ietf.org; Thu, 13 Sep 2007 18:38:00 -0400 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVxJv-0006MX-RJ for isms@ietf.org; Thu, 13 Sep 2007 18:38:00 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc13) with SMTP id <20070913223758m13000kllqe>; Thu, 13 Sep 2007 22:37:58 +0000 From: "David B Harrington" To: "'Wijnen, Bert \(Bert\)'" , References: <20070911065616.GA16313@elstar.local> Date: Thu, 13 Sep 2007 18:37:44 -0400 Message-ID: <012001c7f656$b4973fe0$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf0QOIsQnMNUDp+TbSlg9DEyWyy9gAAUzhQAIUUA8A= In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: isms@ietf.org Subject: [Isms] RE: sendMessage and receiveMessage ASIs indraft-ietf-isms-tmsm-09.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 I added text. dbh > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > Sent: Tuesday, September 11, 2007 3:07 AM > To: j.schoenwaelder@jacobs-university.de > Cc: dbharrington@comcast.net; isms@ietf.org > Subject: RE: sendMessage and receiveMessage ASIs > indraft-ietf-isms-tmsm-09.txt > > Thanks. Adding a few words to make the statement would be good. > Personally, I think that adding one diagram might be useful too > (the less people have to switch between multiple docs, the easier). > But I won't get hung up on that. > > Bert Wijnen > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Tuesday, September 11, 2007 8:56 AM > > To: Wijnen, Bert (Bert) > > Cc: dbharrington@comcast.net; isms@ietf.org > > Subject: Re: sendMessage and receiveMessage ASIs > > indraft-ietf-isms-tmsm-09.txt > > > > On Wed, Aug 08, 2007 at 11:46:16AM +0200, Wijnen, Bert (Bert) wrote: > > > For my own understanding, can you confirm that > > > > > > the sendMessage ASI and the receiveMessage ASI would > > > fit in RFC3411 scenario Diagrams (sect 4.6.1 and 4.6.2) > > > and would take the place of the > > > > > > "Send SNMP (Request) Message to Network" > > > "Receive SNMP (Response) Message from Network" > > > > > > respectively? > > > > > > If so, I wonder if it would be good to say so, or to add such a > > > scenario diagram to the I-D. > > > > I think the sendMessage ASI and the receiveMessage ASI do > > indeed match the mentioned elements in the diagram. If David > > agrees as well, I think we should add a sentences stating > > this (I am not sure it is worth to repeat the whole diagram - > > but I do not feel strongly). > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 13 18:58:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVxdp-0004rX-3k; Thu, 13 Sep 2007 18:58:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVxdn-0004gl-GI for isms@ietf.org; Thu, 13 Sep 2007 18:58:31 -0400 Received: from rwcrmhc15.comcast.net ([216.148.227.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVxdn-0006nV-1k for isms@ietf.org; Thu, 13 Sep 2007 18:58:31 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc15) with SMTP id <20070913225829m1500c635ee>; Thu, 13 Sep 2007 22:58:30 +0000 From: "David Harrington" To: "'David Harrington'" , "'tom.petch'" , "'Jeffrey Hutzelman'" , "'ISMS WG'" References: <037c01c7db3c$9725b520$0601a8c0@pc6><016a01c7db4d$bd2fa710$6702a8c0@china.huawei.com><01af01c7dd84$15202c00$0601a8c0@pc6><000901c7ddd0$79189a20$6702a8c0@china.huawei.com><021701c7de7e$7ebcdaa0$0601a8c0@pc6><59165B4D35F9378674A70368@sirius.fac.cs.cmu.edu><00e501c7e63c$92ed4d00$0601a8c0@pc6> <020201c7e653$37290e20$6702a8c0@china.huawei.com> Subject: RE: [Isms] Working Group Last Call - securityName Date: Thu, 13 Sep 2007 18:58:15 -0400 Message-ID: <012201c7f659$92495470$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfmRccNQvkTV26ASSWC11kD7hfKEwADFbugBAGYomA= In-Reply-To: <020201c7e653$37290e20$6702a8c0@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, I have wordsmithed multiple places to help clarify this. As I recall, the WG decided initailly to define the contents of tmStateReference (around the time of the interim meeting), but later decided not to define the specifics of the tmStateReference because this is transport-specific. One way I can clarify the multiple securityname ambiguity is to define tmStateReference fields called tmSecurityName and tmSecurityLevel and then the Security Model can work with those fields. Does the WG want to go this way? dbh > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Friday, August 24, 2007 9:32 AM > To: 'tom.petch'; 'Jeffrey Hutzelman'; 'ISMS WG' > Subject: RE: [Isms] Working Group Last Call - securityName > > inline > > > > > > > > tmsm 3.2.1.2. Transport Subsystem and the RFC3411 Architecture > > > > > > > > seems clear enough > > > > > > > > 1) authenticate the principal, check integrity and > > timeliness of the > > > > message, and decrypt the message. [Transport Model] > > > > 2) translate parameters to model-independent > > parameters (Transport > > > > Model) > > > > > [...] > > You are quite right; the words are clear and exact; it was my > > understanding that > > got vaguer at this point because those words seem to > > contradict what is said in > > 3.2.1.2. I read, and read, 3.2.1.2 as saying that the Transport > Model > > translates between a transport level identifier and the (one and > only) > > securityName. I now understand that the securityModel can > > use a different > > value for securityName, based on the information it has. For > > me, 3.2.1.2 does > > not say that so I think the wording in 3.2.1.2 should be > > changed to be clearer. > > 3.2.1.1 says: > (Note that these lists are simplified for illustrative purposes, > and > do not represent all details of processing. Transport Models must > provide the detailed elements of procedure.) > > But, I will wordsmsith this to try to make it less ambiguous. > > David Harrington > 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 Fri Sep 14 04:26:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW6Vq-0007kC-9q; Fri, 14 Sep 2007 04:26:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW6Vp-0007df-Aj for isms@ietf.org; Fri, 14 Sep 2007 04:26:53 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IW6Vo-00051C-Ds for isms@ietf.org; Fri, 14 Sep 2007 04:26:53 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l8E8QWH4022502; Fri, 14 Sep 2007 03:26:39 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 03:26:36 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 10:26:31 +0200 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] Re: tmStateReference in draft-ietf-isms-tmsm-09.txt Date: Fri, 14 Sep 2007 10:25:38 +0200 Message-ID: In-Reply-To: <00ab01c7f5fd$d2eb1060$6702a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Re: tmStateReference in draft-ietf-isms-tmsm-09.txt Thread-Index: Acf1SBGBcRNF3fPcSAuox3zIxxqGdwAio1ZQAApYKaAAKzOoYA== References: <20070911070217.GB16313@elstar.local><077a01c7f53e$c7e37aa0$0601a8c0@pc6> <00ab01c7f5fd$d2eb1060$6702a8c0@china.huawei.com> From: "Wijnen, Bert \(Bert\)" To: "David Harrington" , "tom.petch" , X-OriginalArrivalTime: 14 Sep 2007 08:26:31.0569 (UTC) FILETIME=[F4396810:01C7F6A8] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a 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 OK. I can live with that Bert Wijnen =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Thursday, September 13, 2007 2:02 PM > To: Wijnen, Bert (Bert); 'tom.petch';=20 > j.schoenwaelder@jacobs-university.de > Cc: isms@ietf.org > Subject: RE: [Isms] Re: tmStateReference in=20 > draft-ietf-isms-tmsm-09.txt >=20 > Hi, >=20 > I suspect your confusion is between a "software application"=20 > and an "SNMP application". > A software application might be a commercial NMS product that=20 > utilizes the services of an SNMP stack (or contains an SNMP=20 > stack), whereas an SNMP application is within the SNMP stack. >=20 > In reality, it is very possible that neither chooses=20 > anything; it might be an operator that makes the choice, and=20 > he tells the software application what to use, and then the=20 > software application tells the SNMP application what to use,=20 > and the SNMP application tells the SNMP engine what to use. >=20 > Let's take choice out of the issue.=20 >=20 > I changed an "application chooses" to an "application=20 > specifies". Now it really makes no difference whether that is=20 > the software application specifying or the SNMP application=20 > specifying; they work togethet to pass the choice into the system. >=20 > Overloading terms often leads to ambiguity. But the SNMPv3 WG=20 > chose application over other non-overloaded terminology (such=20 > as orangelet). > Now we have to live with the decision. >=20 > I believe it would be inappropriate to change "application"=20 > to "NO or CG" since there are other applications already=20 > defined (proxy) and the framework permits additional=20 > applications to be added. We should not inadvertently=20 > constrain the framework by saying that it must be an NO or a=20 > CG specifying this information. >=20 > dbh >=20 > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > > Sent: Thursday, September 13, 2007 2:54 AM > > To: tom.petch; j.schoenwaelder@jacobs-university.de > > Cc: isms@ietf.org > > Subject: RE: [Isms] Re: tmStateReference in=20 > > draft-ietf-isms-tmsm-09.txt > >=20 > > Maybe I read/interpreted "an application may use.." instead of "an=20 > > application may choose....". > >=20 > > Even so, if we DO mean NO or CG, then maybe we should say=20 > that, that=20 > > takes away at least some of the potential confusion in my=20 > mind. But I=20 > > have to go reread/study now that I see your comments. > >=20 > > Bert Wijnen > >=20 > > > -----Original Message----- > > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > > Sent: Wednesday, September 12, 2007 3:11 PM > > > To: j.schoenwaelder@jacobs-university.de; Wijnen, Bert (Bert) > > > Cc: isms@ietf.org > > > Subject: Re: [Isms] Re: tmStateReference in=20 > > > draft-ietf-isms-tmsm-09.txt > > >=20 > > > > > > Tom Petch > > >=20 > > > ----- Original Message ----- > > > From: "Juergen Schoenwaelder" > > > > To: "Wijnen, Bert (Bert)" > > > Cc: > > > Sent: Tuesday, September 11, 2007 9:02 AM > > > Subject: [Isms] Re: tmStateReference in > draft-ietf-isms-tmsm-09.txt > > >=20 > > >=20 > > > > On Wed, Aug 08, 2007 at 12:17:56PM +0200, Wijnen, Bert > > (Bert) wrote: > > > > > > > > > I am confused by the last 2 paragraphs in sect 6.2 > > > > > > > > > > The prepareOutgoingMessage ASI passes > > tmStateReference from the > > > > > Message Processing Subsystem to the dispatcher. How > > or if the > > > > > Message Processing Subsystem modifies or utilizes the > > > contents of the > > > > > cache is message-processing-model-specific. > > > > > > > > > > This may sound underspecified, but keep in mind that > > a message > > > > > processing model might have access to all the > > > information from the > > > > > cache and from the message, and have no need to call a > > > Security Model > > > > > to do any processing; an application might choose a > > > Security Model > > > > > such as USM to authenticate and secure the SNMP > > > message, but also > > > > > utilize a secure transport such as that provided by > > > the SSH Transport > > > > > Model to send the message to its destination. > > > > > > > > > > specifically the wording "an application...". > > > > > Applications in our RFC3411 context are CG or CR or NO or > > > NR or such. > > > > > I am sure that is not intended here. But then, what is an > > > "application" > > > > > in this sentence above? > > > > > > > >=20 > > > Bert > > >=20 > > > I am puzzled that you are confused:-) I read "an application" in=20 > > > this context as meaning eg a CG or NO. > > RFC3411 4.1.1. > > > 'The PDU Dispatcher provides the following primitive for an > > > application to send an SNMP Request or Notification to another=20 > > > SNMP entity:' > > > ....... > > > ' IN transportDomain -- transport domain to be used > > > IN transportAddress -- transport address to be > used > > > IN messageProcessingModel -- typically, SNMP version > > > IN securityModel -- Security Model to use' > > > so the application chooses the securityModel and secure=20 > transport; I=20 > > > see no problem with the text. > > >=20 > > > Removing the paragraph removes the mention of USM over secure=20 > > > transport. OK, this combination is problematic, as has=20 > been pointed=20 > > > out already, but if the conclusion is that it is=20 > impossible, then I=20 > > > would like that explicit, not implicit in the removal of a=20 > > > paragraph. > > >=20 > > > > > I am also not sure we should speak about the MPM to "not call > a=20 > > > > > security model". From our architectural point of view, > > > the MPM will > > > > > ALWAYS call a security model. If an implementation does a > > > shortcut, > > > > > that is up to them... but should we discuss that here? > > > > > > > >=20 > > > I agree, calling the SM should be mandatory even if it is no-op. > > >=20 > > > > > I am similarly confused by the "an application..." in > > section 6.4 > > > > > last paragraph. > > > > > > >=20 > > > Again, I am puzzled that you are confused; this paragraph makes=20 > > > sense to me. > > >=20 > > > Tom Petch > > >=20 > > > > I am wondering whether this issue can be solved by simply > > > deleting the > > > > second quoted paragraph since I am not sure it adds value. > > > > > > > > /js > > > > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > >=20 >=20 >=20 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 14 06:03:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW819-0001Ca-60; Fri, 14 Sep 2007 06:03:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW818-0001CC-M0 for isms@ietf.org; Fri, 14 Sep 2007 06:03:18 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IW817-0000Tp-3r for isms@ietf.org; Fri, 14 Sep 2007 06:03:18 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D673865BD; Fri, 14 Sep 2007 12:03:16 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 13996-10-48; Fri, 14 Sep 2007 12:03:10 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2930686421; Fri, 14 Sep 2007 12:00:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 72101338715; Fri, 14 Sep 2007 12:00:51 +0200 (CEST) Date: Fri, 14 Sep 2007 12:00:51 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] my review of: Message-ID: <20070914100051.GB22820@elstar.local> Mail-Followup-To: David Harrington , "'Wijnen, Bert (Bert)'" , isms@ietf.org References: <20070911072236.GC16313@elstar.local> <011701c7f648$c21d3240$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011701c7f648$c21d3240$6702a8c0@china.huawei.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Thu, Sep 13, 2007 at 04:57:54PM -0400, David Harrington wrote: > > > > - tsmInvalidCache OBJECT-TYPE > > > > SYNTAX Counter32 > > > > MAX-ACCESS read-only > > > > STATUS current > > > > DESCRIPTION "The number of messages dropped because the > > > > tmStateReference referred to an invalid > cache. > > > > > > > > This value is not persistent across reboots. > > > > " > > > > ::= { tsmStats 1 } > > > > > > Perhaps rename to tsmInvalidCacheReferences? > > > > > > > sounds good > > The reference may be perfectly valid; it is the cache that is invalid. I do not want to distinguish between these two. So perhaps a better name for the counter is needed. What about tsmInvalidCaches with the description: "The number of messages dropped because the tmStateReference referred was invalid or pointed to an invalid cache." > How should a manager interpret this counter? Is it better for the NMS > to have us count the number of bad references to caches, or the number > of good references to bad caches, or does the NMS need to monitor both > of these error conditions? As I said, I do not want to distinguish between them. (Probably because in our implementation, there is not much of a difference between the two or lets say we can't really detect all cases where the reference is invalid.) > Note that having a counter for this implementation-specific error > condition, whether we count bad references or bad caches, is adding > DEBUG information to the NM information. I just edited the OPS&Mgmt > draft where it was pointed out that debug info should NOT be part of > the NM data. > > How will instrumenting this information and making it available to my > NMS make the Internet run better? It allows to detect and identify errors that may have security implications. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 14 06:26:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW8NX-0002LE-3Q; Fri, 14 Sep 2007 06:26:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW8NV-0002L4-F1 for isms@ietf.org; Fri, 14 Sep 2007 06:26:25 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IW8NU-00010O-44 for isms@ietf.org; Fri, 14 Sep 2007 06:26:25 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id A7AB4863F2; Fri, 14 Sep 2007 12:26:23 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 18915-02-38; Fri, 14 Sep 2007 12:26:16 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 08BD79B2; Fri, 14 Sep 2007 12:25:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 563E9338767; Fri, 14 Sep 2007 12:25:33 +0200 (CEST) Date: Fri, 14 Sep 2007 12:25:33 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] my review of: Message-ID: <20070914102533.GC22820@elstar.local> Mail-Followup-To: David Harrington , "'Wijnen, Bert (Bert)'" , isms@ietf.org References: <20070911072236.GC16313@elstar.local> <011701c7f648$c21d3240$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011701c7f648$c21d3240$6702a8c0@china.huawei.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Thu, Sep 13, 2007 at 04:57:54PM -0400, David Harrington wrote: > comments inline > > dbh > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > > Sent: Tuesday, September 11, 2007 4:52 AM > > > > > > > > > > > - ::= { snmpModules xxxx } > > > > > > > > Is there a good reason to put this underneath that > > > snmpModules branch? > > > > I do understand we have the snmpUsmMIB (so to be > > > consistent this one > > > > should be named snmpTsmMIB) and related MIB modules under > > > snmpModules. > > > > So from that point it makes sense. > > > > > > > > But we have stated (in RFC4181) that an OID is just an OID and > > > > MIB modules should go under mib-2. > > > > And we have no-where specified IANA guidelines as to how/when > to > > > > assign new values under snmpModules. > > > > > > > > I know that some other WG wants to put their MIB > > modules under a > > > > common branch of their own as well... and they are (as we > speak) > > > > getting push-back from our AD. > > > > > > The question is why we have snmpModules in the first place > > > and whether we continue to root SNMP modules under > > > snmpModules or treat them as all other modules. The > > > SNMP-USM-AES-MIB was probably the last one rooted under > > > snmpModules - so SNMP addons have been rooted in the not too > > > distant past. I suggest Dan provides advise whether we > > > continue to use snmpModules or declare that we declare > > > snmpModules was a bad idea and we stop assigning things below > > > snmpModules (and perhaps this can then be documented in the > > > IANA documents so we don't forget about this and we can make > > > tools to check for this). > > > > > > > I am OK with leaving it up to Dan. > > As I stated, I can live with it. > > It only seems we are not consistent with the messages we give in > > RFC4181. > > Lte's see, what should we consider? > Does putting it under snmpModules or mib-2 make it easier to manage a > network? > Does putting it under snmpModules or mib-2 make it easier to > implement? > Does putting it under either one make it easier for IANA? > Does putting it under one or the other make it easier for application > developers? > > I think the major argument from my point of view is I am tired of > having to change this back and forth. It makes no difference where we > root it. Let's call it done so we can get the document submitted to > the IESG and encourage people to implement and deploy it. > > > > > > I am fine with changing tsmMIB to snmpTsmMIB. > > > > > > > Thanks. Adds to our consistency I think. > > consistency with what? the sshtmMib does not have an snmp prefix. > The RFC341x MIB modules all start with SNMP- and the module identities > start with snmp, and all their objects start with snmpXXX, and they > root under snmpModules. That is consistency. > > If we root this under mib-2 rather than an snmp-specific registration > point, as per 4181, then I recommend we rename SNMP-SSH-TM-MIB to > simply SSHTM-MIB to make it consistent with 4181 naming conventions, > and to make it consistent with the module identity and the naming used > throughout the module, which follows the naming conventions described > in 4181. That would be consistent with RRFC4181. I hoped we get away with rough concensus to pick snmpModules and to align descriptor naming styles to other core SNMP MIB modules so that we can move forward. Bert already worked on the IANA issues. Do you really want to make this a major discussion point which will waste time and energy without being in any way relevant for getting technology defined and interoperability? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 14 06:37:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW8Xq-0001LA-AT; Fri, 14 Sep 2007 06:37:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW8Xo-0001L1-VY for isms@ietf.org; Fri, 14 Sep 2007 06:37:05 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IW8Xo-000149-AD for isms@ietf.org; Fri, 14 Sep 2007 06:37:04 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-outbound.avaya.com with ESMTP; 14 Sep 2007 06:37:03 -0400 X-IronPort-AV: i="4.20,255,1186372800"; d="scan'208"; a="65164861:sNHT12177594" 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] my review of: Date: Fri, 14 Sep 2007 12:36:18 +0200 Message-ID: In-Reply-To: <20070914102533.GC22820@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] my review of: Thread-Index: Acf2ubjO6Qu7NMO9SWmq7SwTq4vfrgAALNHQ References: <20070911072236.GC16313@elstar.local><011701c7f648$c21d3240$6702a8c0@china.huawei.com> <20070914102533.GC22820@elstar.local> From: "Romascanu, Dan (Dan)" To: , "David Harrington" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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 =20 =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Friday, September 14, 2007 1:26 PM > To: David Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] my review of: >=20 > On Thu, Sep 13, 2007 at 04:57:54PM -0400, David Harrington wrote: > > comments inline > >=20 > > dbh > >=20 > > > -----Original Message----- > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > > > Sent: Tuesday, September 11, 2007 4:52 AM > > >=20 > >=20 > > > > >=20 > > > > > - ::=3D { snmpModules xxxx } > > > > >=20 > > > > > Is there a good reason to put this underneath that > > > > snmpModules branch? > > > > > I do understand we have the snmpUsmMIB (so to be > > > > consistent this one > > > > > should be named snmpTsmMIB) and related MIB modules under > > > > snmpModules. > > > > > So from that point it makes sense. > > > > >=20 > > > > > But we have stated (in RFC4181) that an OID is just=20 > an OID and > > > > > MIB modules should go under mib-2.=20 > > > > > And we have no-where specified IANA guidelines as=20 > to how/when > > to > > > > > assign new values under snmpModules. > > > > >=20 > > > > > I know that some other WG wants to put their MIB > > > modules under a > > > > > common branch of their own as well... and they are (as we > > speak) > > > > > getting push-back from our AD. > > > >=20 > > > > The question is why we have snmpModules in the first place and=20 > > > > whether we continue to root SNMP modules under snmpModules or=20 > > > > treat them as all other modules. The SNMP-USM-AES-MIB=20 > was probably=20 > > > > the last one rooted under snmpModules - so SNMP addons=20 > have been=20 > > > > rooted in the not too distant past. I suggest Dan=20 > provides advise=20 > > > > whether we continue to use snmpModules or declare that=20 > we declare=20 > > > > snmpModules was a bad idea and we stop assigning things below=20 > > > > snmpModules (and perhaps this can then be documented in=20 > the IANA=20 > > > > documents so we don't forget about this and we can make=20 > tools to=20 > > > > check for this). > > > >=20 > > >=20 > > > I am OK with leaving it up to Dan. > > > As I stated, I can live with it. > > > It only seems we are not consistent with the messages we give in=20 > > > RFC4181. > >=20 > > Lte's see, what should we consider? > > Does putting it under snmpModules or mib-2 make it easier=20 > to manage a=20 > > network? > > Does putting it under snmpModules or mib-2 make it easier to=20 > > implement? > > Does putting it under either one make it easier for IANA? > > Does putting it under one or the other make it easier for=20 > application=20 > > developers? > >=20 > > I think the major argument from my point of view is I am tired of=20 > > having to change this back and forth. It makes no=20 > difference where we=20 > > root it. Let's call it done so we can get the document submitted to=20 > > the IESG and encourage people to implement and deploy it. > >=20 > > >=20 > > > > I am fine with changing tsmMIB to snmpTsmMIB. > > > >=20 > > >=20 > > > Thanks. Adds to our consistency I think. > >=20 > > consistency with what? the sshtmMib does not have an snmp prefix. > > The RFC341x MIB modules all start with SNMP- and the module=20 > identities=20 > > start with snmp, and all their objects start with snmpXXX,=20 > and they=20 > > root under snmpModules. That is consistency. > >=20 > > If we root this under mib-2 rather than an snmp-specific=20 > registration=20 > > point, as per 4181, then I recommend we rename SNMP-SSH-TM-MIB to=20 > > simply SSHTM-MIB to make it consistent with 4181 naming=20 > conventions,=20 > > and to make it consistent with the module identity and the=20 > naming used=20 > > throughout the module, which follows the naming conventions=20 > described=20 > > in 4181. That would be consistent with RRFC4181. >=20 > I hoped we get away with rough concensus to pick snmpModules=20 > and to align descriptor naming styles to other core SNMP MIB=20 > modules so that we can move forward. Bert already worked on=20 > the IANA issues. >=20 > Do you really want to make this a major discussion point=20 > which will waste time and energy without being in any way=20 > relevant for getting technology defined and interoperability? >=20 > /js >=20 In principle it is better to try to be consistent and when the question is 'consistent to what' use RFC 4181 as a reference whenever possible. This being said I agree that we should not turn this into a major discussion point, and would agree with any of the solutions that is being picked by the editor.=20 Dan _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 14 08:18:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWA7w-0007IK-Ds; Fri, 14 Sep 2007 08:18:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWA7v-0007HY-Ui for isms@ietf.org; Fri, 14 Sep 2007 08:18:27 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWA7v-0003Wk-IO for isms@ietf.org; Fri, 14 Sep 2007 08:18:27 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 144C0865CD; Fri, 14 Sep 2007 14:18:26 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30477-01-26; Fri, 14 Sep 2007 14:18:21 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 898FF86430; Fri, 14 Sep 2007 14:14:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BAA6B338B27; Fri, 14 Sep 2007 14:14:58 +0200 (CEST) Date: Fri, 14 Sep 2007 14:14:58 +0200 From: Juergen Schoenwaelder To: "tom.petch" Subject: Re: [Isms] Working Group Last Call - securityLevel changes Message-ID: <20070914121458.GB23252@elstar.local> Mail-Followup-To: "tom.petch" , David Harrington , 'ISMS WG' References: <001501c7e2f9$9dbd2020$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001501c7e2f9$9dbd2020$0601a8c0@pc6> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Mon, Aug 20, 2007 at 09:05:28AM +0200, tom.petch wrote: > Just to be more specific, I am suggesting adding wording to tmsm, > either what we have in secshell, that security level of the > transport SHOULD NOT be changed, or, if that is too restrictive in > the architecture, as opposed to a model, then a warning that a > change in security level could lead to a security exposure since the > security subsystem may not have access to information relevant to > the message it is processing. To me, this sounds reasonable. Tom, can you draft some concrete text? I would probably go with the warning but I have no strong feeling about this. I guess we need to see the concrete text. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 14 08:18:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWA82-0007KL-5e; Fri, 14 Sep 2007 08:18:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWA81-0007KG-Ey for isms@ietf.org; Fri, 14 Sep 2007 08:18:33 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWA80-0003FE-47 for isms@ietf.org; Fri, 14 Sep 2007 08:18:33 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE50D865DA; Fri, 14 Sep 2007 14:18:31 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30477-01-27; Fri, 14 Sep 2007 14:18:26 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2D95F8655B; Fri, 14 Sep 2007 14:15:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 61940338B42; Fri, 14 Sep 2007 14:15:08 +0200 (CEST) Date: Fri, 14 Sep 2007 14:15:08 +0200 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Subject: Re: [Isms] Working Group Last Call - securityName Message-ID: <20070914121508.GC23252@elstar.local> Mail-Followup-To: Jeffrey Hutzelman , David Harrington , "'tom.petch'" , 'ISMS WG' References: <037c01c7db3c$9725b520$0601a8c0@pc6> <016a01c7db4d$bd2fa710$6702a8c0@china.huawei.com> <01af01c7dd84$15202c00$0601a8c0@pc6> <000901c7ddd0$79189a20$6702a8c0@china.huawei.com> <021701c7de7e$7ebcdaa0$0601a8c0@pc6> <59165B4D35F9378674A70368@sirius.fac.cs.cmu.edu> <012501c7e50e$f3723700$6702a8c0@china.huawei.com> <7958D25293C8B6AA01621659@sirius.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7958D25293C8B6AA01621659@sirius.fac.cs.cmu.edu> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Wed, Aug 22, 2007 at 07:16:33PM -0400, Jeffrey Hutzelman wrote: > I think the simple thing to do here is for the TM to include a real session > identifier in the tmStateRef, and use that instead of matching to find the > correct session for a reply. > > However, even if you search for a session by matching transport address and > security parameters, having the "wrong" thing happen requires the > following: > > (1) I establish an SSH connection, authenticated as Alice. > (2) I send an authentic SNMP request using USM, with USM username Bob. > (3) While my request is being processed, I disconnect the SSH session, > then establish a new SSH session to the SNMP server _from the same > transport endpoint_, and this time authenticate as Bob. > (4) The server's response goes to my connection, because it belongs to Bob > and has the right transport address. > > In this situation, something "wrong" has happened, but it has not > compromised security, because I proved I was "Bob" when I sent the message, > and again when I established the new SSH connecton, and I even still have > to know the USM key in order to process the response. I think this can compromise security to some extend if you have USM in authNoPriv mode since the response comes back in cleartext and may contain data the attacker (who of course has to be able to authenticate him as Bob) is not allowed to see. It won't be easy in practice to mount this attack and requires a certain interesting configuration of the SNMP agent to work. But this seems a general USM "security property" if you want. With USM over UDP, after an authNoPriv request has been sent, an attacker can get the response by replacing the UDP endpoint used by the command generator's SNMP engine with its own endpoint. Sure, if you use authNoPriv, you kind of agree that anybody able to listen on the network can read the data anyway. Hence, this "attack" will only be useful if you can't sniff the network but you are able to control/replace the transport endpoints of a management system. I believe it is important to realize that with USM over SSH you get the security of USM and nothing more - and USM does not protect responses unless you use authPriv mode. Can we get away with documenting this properly in the security considerations section(s)? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 14 09:46:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWBUp-0005DC-0P; Fri, 14 Sep 2007 09:46:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWBUn-0005Cp-NW for isms@ietf.org; Fri, 14 Sep 2007 09:46:09 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWBUn-0007RW-5f for isms@ietf.org; Fri, 14 Sep 2007 09:46:09 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id A90ED86402; Fri, 14 Sep 2007 15:46:08 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08521-02-4; Fri, 14 Sep 2007 15:46:03 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 52AED55E5B; Fri, 14 Sep 2007 15:45:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 95F81338ED1; Fri, 14 Sep 2007 15:45:57 +0200 (CEST) Date: Fri, 14 Sep 2007 15:45:57 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] More questions on Security name Message-ID: <20070914134557.GD23435@elstar.local> Mail-Followup-To: David Harrington , "'Wijnen, Bert (Bert)'" , "'Joseph Salowey (jsalowey)'" , isms@ietf.org References: <015401c7e57d$7fed4f80$6702a8c0@china.huawei.com> <015c01c7e593$98d5f360$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <015c01c7e593$98d5f360$6702a8c0@china.huawei.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Thu, Aug 23, 2007 at 10:40:48AM -0400, David Harrington wrote: > > So the authoritative part of my comments should be ignore in terms > > of architectural impact. > > Again, I wish those who argued so vehemently in favor of making the > > receiving end of an INFORM authoritative were participating. > > There was (I believe, but do not recall details) more to it than > > just USM. But in our current archtecture and documents, indeed the > > architecture > > does not speak of authoritative sides. Only USM does. > > I think there may have been a number of motivations for the > authoritative difference. The main one in my mind is the use of clocks > to detect timeliness, to help prevent replay. There are certain > attacks that can be launched using replay, and causing the > re-synchronization of clocks. It is important to check timeliness > using the correct clock, and it is important to sync using the right > clock. I think this WG has spend significant efforts to find out where the notion of an authoritative engine has impact outside the USM (Bert Wijnen was specifically working on this) and we did not find one. So I think there is concensus to make the assumption that the notion of authoritative engines is USM specific and does not concern SNMP or more specifically ISMS on the architectural level. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 14 10:01:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWBjN-00031n-To; Fri, 14 Sep 2007 10:01:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWBjM-000317-O1 for isms@ietf.org; Fri, 14 Sep 2007 10:01:12 -0400 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWBjL-0007xG-S9 for isms@ietf.org; Fri, 14 Sep 2007 10:01:12 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc13) with SMTP id <20070914140110m13000ncste>; Fri, 14 Sep 2007 14:01:10 +0000 From: "David Harrington" To: "'Joseph Salowey \(jsalowey\)'" , "'Jeffrey Hutzelman'" , "'Wijnen, Bert \(Bert\)'" References: <539D70CF464B36159F3434D8@sirius.fac.cs.cmu.edu> Date: Fri, 14 Sep 2007 10:00:58 -0400 Message-ID: <015e01c7f6d7$ad55ee80$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcflC50EvsOOSJhES42fdaYXiMLsEAADQlCABG7JQMA= In-Reply-To: X-Spam-Score: 1.8 (+) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: isms@ietf.org Subject: [Isms] SSH USERNAME X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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 Joe, I'm not sure what to do with this. If I get my terminology correct, we are looking for a cryptographic binding between the user identity authenticated by SSH and the user identity used for database access control in SNMP. Are you saying that SSH will authenticate an empty username? Could we solve the problem by saying that SNMP should not accept an empty username field? If we don't use SSH_MSG_USERAUTH_REQUEST, where do we get an identifier for the SSH-authenticated entity? I think we already recognize that toolkits may not make the SSH_MSG_USERAUTH_REQUEST available to users, and users need to work through whatever APIs are provided to set the username. I'm not very commfortable that this qualifies as cryptographic binding, but it seems the be the best we can get from the SSH community. The second problem is an SSH problem that we cannot do anything about, right? So in practical terms, Can I (dbh) specify "root" in the SSH username and have SSH establish an authenticated connection for root, even if I do not have the credentials for root? Is that what you are saying? Is there any way for SNMP to even know when this is happening? Is the security area planning to fix this loophole? dbh > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Wednesday, August 22, 2007 8:08 PM > To: Jeffrey Hutzelman; Wijnen, Bert (Bert); David Harrington > Cc: isms@ietf.org > Subject: RE: [Isms] my review of: draft-ietf-isms-secshell-08.txt > > In particular I think we need to be careful of > SSH_MSG_USERAUTH_REQUEST. > First an empty username may appear in this message and second > there is a > loophole in the base SSH spec that could allow an authentication > mechanism in which the name in the username field is not an authorized > name of the authenticated party. > > > > > -----Original Message----- > > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > > Sent: Wednesday, August 22, 2007 3:22 PM > > To: Wijnen, Bert (Bert); David Harrington; Joseph Salowey (jsalowey) > > Cc: isms@ietf.org; Jeffrey Hutzelman > > Subject: Re: [Isms] my review of: draft-ietf-isms-secshell-08.txt > > > > > > > > On Thursday, August 09, 2007 12:17:13 PM +0200 "Wijnen, > Bert (Bert)" > > wrote: > > > > > - sect 5.1 and 5.1 > > > I assume that SSH_MSG_USERAUTH_REQUEST and SSH_MSG_CHANNEL_DATA > > > are specified somewhere in the SSH RFC(s)? Maybe a citation to > > > such RFC(s) is useful at these points. > > > > Yes; those are SSH protocol messages. It's actually not > > clear that SSH messages should be referenced explicitly here; > > instead, we should be talking about SSH at a rather higher > > layer. For example, SSH user authentication can be a fairly > > complex negotiation; it doesn't involve sending just one > > message. Similarly, outside the SSH protocol channels are > > presented as streams, not sequences of SSH_MSG_CHANNEL_DATA > > messages, and in particular you can't assume that your > > messages will be sent in a single channel data message or > > infer the size of an incoming message from the underlying SSH > > protocol messages. > > > > Similarly, if you are establishing a separate SSH connection > > for every session, you don't need data from the SSH channel > > open/confirmation messages, and in fact generally such data > > will not be available to you as it is buried in the details > > of the SSH protocol. If you are establishing multiple > > channels over the same SSH session, then you may need to know > > which channel is which, but this is almost certainly done > > using identifiers provided to you by your SSH implementation > > (perhaps even file descriptors) and not necessarily using SSH > > protocol data. > > > > > > > > > - For SnmpSSHAddress ::= TEXTUAL-CONVENTION I read: > > > > > > "Represents either a hostname encoded in ASCII > > > using the IDNA protocol, as specified in RFC3490, > > followed by > > > a colon ':' (ASCII character 0x3A) and a decimal > port number > > > in ASCII, or an IP address followed by a colon ':' > > > (ASCII character 0x3A) and a decimal port number in ASCII. > > > The name SHOULD be fully qualified whenever possible. > > > > > > I am not well versed/experienced in IDNA. But is IDNA a > protocol? > > > > That is a semantic question, which I'd just as soon not argue here. > > Perhaps we could say "as specified by IDNA [RFC3490]" ? > > > > > > > The title of 3490 reads > > > Internationalizing Domain Names in Applications (IDNA) > > > And are we indeed speaking of a hostname, or of a > domain name, or > > > of both? I can't quickly determine that. So I wonder > if/hope that > > > we can be clearer here. > > > > We are talking about a hostname, but hostnames are domain > > names (however, not all domain names are valid hostnames). > > > > > > > > > I also assume (although this is not explicitly stated) > that if we > > > speak about an IP address, that it is a dotted decimal for > > > IPv4 and and a colon separated IPv6 address in ASCII? Yes/no? > > > > In fact, I think we are in trouble if, for an IPv6 address, > > we don't mean a > > colon-separated address with brackets around it. Otherwise > > it may become > > rather difficult to determine where the port starts, or if it > > is present! > > > > -- Jeff > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 14 10:19:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWC13-0005Zj-Mx; Fri, 14 Sep 2007 10:19:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWC12-0005Ze-IB for isms@ietf.org; Fri, 14 Sep 2007 10:19:28 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWC11-0008MV-TE for isms@ietf.org; Fri, 14 Sep 2007 10:19:28 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 654706DB12; Fri, 14 Sep 2007 16:19:27 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 11608-02; Fri, 14 Sep 2007 16:19:20 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1332A86405; Fri, 14 Sep 2007 16:19:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5F09D338FA3; Fri, 14 Sep 2007 16:19:18 +0200 (CEST) Date: Fri, 14 Sep 2007 16:19:18 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] More questions on Security name Message-ID: <20070914141918.GE23435@elstar.local> Mail-Followup-To: David Harrington , "'Wijnen, Bert (Bert)'" , "'Joseph Salowey (jsalowey)'" , isms@ietf.org References: <015401c7e57d$7fed4f80$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <015401c7e57d$7fed4f80$6702a8c0@china.huawei.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Thu, Aug 23, 2007 at 08:02:37AM -0400, David Harrington wrote: > As I recall, no solution was found to this issue. I think we reached > consensus that > 1) if a client had already established a connection, so we have a > relevant securityname, then that connection could be reused for > notiications. This, of course, requires that appropriate entries exist in the snmpTargetTable and friends that point to this notification destination. In other words, this assumes a subscription mechanism where you establish the SSH transport and then create entries that direct notifications to the SSH session. The only issue left with this approach (as I recall) is how to garbage collect those dynamic entries in the snmpTargetTable and friends, which likely needs a sparse augmentation of the snmpTargetTable. > 2) if a notification needs to be sent, and no SSH connection exists, > then the transport model will try to create a connection. How the > credentials are supplied, and how the connectionis created is > implementation-specific. The slides from IETF67 present three > options for doing this, which may or may not work. The straight forward approach is to have an SSH user name plus whatever credentials needed for authentication on the "device" and to use the authenticated host identity as the security name (and thus as input for the access control decision). We investigated turning SSH roles around and finally concluded that this is not going to work due to security issues; at least not without a surgery of SSH (which is not our business). > 3) if a notification needs to be sent, and no SSH connection exists, > then the agent can use USM to send the notification. This is > implementation-specific. Implementation-specific magic to fallback to USM does not seem to be a solution to pursue on a standards-track. So I think we essentially have 2) and an incomplete 1). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 14 11:19:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWCxZ-0006di-VR; Fri, 14 Sep 2007 11:19:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWCxL-0006UT-NF for isms@ietf.org; Fri, 14 Sep 2007 11:19:43 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IWCxK-0000VY-Ex for isms@ietf.org; Fri, 14 Sep 2007 11:19:43 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa02101; 14 Sep 2007 11:19 EDT Date: Fri, 14 Sep 2007 11:19:31 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: David Harrington In-Reply-To: <015e01c7f6d7$ad55ee80$6702a8c0@china.huawei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: isms@ietf.org Subject: [Isms] Re: SSH USERNAME X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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 Fri, 14 Sep 2007, David Harrington wrote: > Hi Joe, > > I'm not sure what to do with this. > If I get my terminology correct, we are looking for a cryptographic > binding between the user identity authenticated by SSH and the user > identity used for database access control in SNMP. No. The ssh layer will provide you with an authenticated username, and that authentication is cryptographically bound to the communication channel (to what extent depends on the mechanism you are using, but it's generally at least reasonable, provided the client has verified the server's identity before proceeding). The relation between the ssh username and the identity used for access control in SNMP is entirely up to SNMP. SSH never sees the latter, except to the extent that the two names are the same (which will probably be the case most of the time, or possibly even all of the time; I don't remember what we ended up doing with that). > Are you saying that SSH will authenticate an empty username? > Could we solve the problem by saying that SNMP should not accept an > empty username field? > If we don't use SSH_MSG_USERAUTH_REQUEST, where do we get an > identifier for the SSH-authenticated entity? You misunderstand. The issue is very simple -- by mentioning specific SSH protocol messages at all, you are violating the abstraction. The SSH protocol is considerably more complex than the interface available to the upper-layer application, and Joe is pointing out a case where this is getting you into trouble. In a noremal SSH authentication exchange, there will typically be multiple SSH_MSG_USERAUTH_REQUEST messages. The first one will almost always have method "none", possibly an empty username, and will fail. Its main purpose is to discover what authentication methods the server supports, though it also services to discover whether the server will allow an anonymous or unauthenticated login. This complexity is not described in SSHSM, nor should it be. > The second problem is an SSH problem that we cannot do anything about, > right? > So in practical terms, Can I (dbh) specify "root" in the SSH username > and have SSH establish an authenticated connection for root, even if I > do not have the credentials for root? Is that what you are saying? There may be multiple sets of credentials that allow you to authenticate as root, even using the same mechanism. For example, on a typical machine in our computing environment, there are (currently) three DSA keys, one RSA key, and 32 Kerberos principals which can be used to log in as root. But what Joe is really saying is that it is possible to have an SSH user authentication mechanism which ignores the username entirely. In fact, the "hostbased" method permits such a mode, where only the identity of the client host is considered. This is not as useless as it might sound; such a method could be used in multi-step authentication, or in a scenario where there is a proxy trusted by the end server -- (the real user makes an SSH connection to a proxy, authenticates to it, the proxy decides whether the connection is legit, and if so, turns around and establishes a connection to the real server, which trusts whatever the proxy tells it about usernames). > Is there any way for SNMP to even know when this is happening? No. > Is the security area planning to fix this loophole? No. It's not a security bug; it's a loophole in the spec that allows someone to specify an authentication method that does something you might not have thought of. There are probably others. The point is, SSHSM doesn't have to say what SSH protocol messages to send when, any more than it has to talk about TCP connection setup, windowing, etc. Those things are all below the abstraction. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 14 11:32:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWD9Q-0007dN-1H; Fri, 14 Sep 2007 11:32:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWD9O-0007V1-8A for isms@ietf.org; Fri, 14 Sep 2007 11:32:10 -0400 Received: from mail.elbrysnetworks.com ([64.140.243.164] helo=gumby.elbrysnetworks.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IWD9M-0000jv-VA for isms@ietf.org; Fri, 14 Sep 2007 11:32:10 -0400 Received: (qmail 14040 invoked from network); 14 Sep 2007 11:32:06 -0400 Received: from vpn.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.16.8) by gumby.elbrysnetworks.com with SMTP; 14 Sep 2007 11:32:06 -0400 From: "David B. Nelson" To: References: <015e01c7f6d7$ad55ee80$6702a8c0@china.huawei.com> Subject: RE: [Isms] Re: SSH USERNAME Date: Fri, 14 Sep 2007 11:31:39 -0400 Organization: Elbrys Networks, Inc. Message-ID: <001001c7f6e4$584dab50$6501a8c0@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acf24rczYVgHbWtDSc6ev4OfVmCt7AAAN+ng X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Jeffrey Hutzelman writes... > > Is there any way for SNMP to even know when this is happening? > > No. > > > Is the security area planning to fix this loophole? > > No. It's not a security bug; it's a loophole in the spec that > allows someone to specify an authentication method that does > something you might not have thought of. There are probably > others. > > The point is, SSHSM doesn't have to say what SSH protocol messages > to send when, any more than it has to talk about TCP connection > setup, windowing, etc. Those things are all below the abstraction. Sure. Does SNMP have a way to know that SSH has performed a "meaningful" authentication? If not, is there a way for the system administrator to configure the combination of SSH and SNMP such that insufficiently "meaningful" levels of authentication are not employed with Transport Security Models? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 14 12:00:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWDar-0008HH-Gh; Fri, 14 Sep 2007 12:00:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWDab-0007z4-OI for isms@ietf.org; Fri, 14 Sep 2007 12:00:18 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IWDab-00034e-Ag for isms@ietf.org; Fri, 14 Sep 2007 12:00:17 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa02134; 14 Sep 2007 11:59 EDT Date: Fri, 14 Sep 2007 11:59:37 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Juergen Schoenwaelder Subject: Re: [Isms] Working Group Last Call - securityName In-Reply-To: <20070914121508.GC23252@elstar.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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 Fri, 14 Sep 2007, Juergen Schoenwaelder wrote: > I think this can compromise security to some extend if you have USM in > authNoPriv mode since the response comes back in cleartext and may > contain data the attacker (who of course has to be able to > authenticate him as Bob) is not allowed to see. No. If the attacker can authenticate as Bob, the attacker _is_ Bob, for all intents and purposes. He is allowed to see anything that Bob is allowed to see, and so security is not compromised by giving him information that Bob is allowed to have. Put another way, what the scenario I described means is that if a single entity possesses SSH credentials for Alice and Bob, and USM credentials for Bob, then he can (with some effort) arrange to send a request over an SSH connection authenticated as Alice and get the response over a different SSH connection authenticated as Bob. This is a little odd, and I can't think of any useful reason to do it, but it doesn't mean there is a security problem. > But this seems a general USM "security property" if you want. With > USM over UDP, after an authNoPriv request has been sent, an attacker > can get the response by replacing the UDP endpoint used by the command > generator's SNMP engine with its own endpoint. Yes. Of course, with SSH involved, a real attacker need not even replace the UDP endpoint in this case -- all he has to do is watch all the traffic sent by the CP or received by the CG. > I believe it is important to realize that with USM over SSH you get > the security of USM and nothing more - and USM does not protect > responses unless you use authPriv mode. That's not entirely true -- if you verify the SSH server's identity, you get to run USM over an encrypted tunnel. You can even do so securely. The only problem is that if we try to match outgoing messages to SSH sessions by transport address and security name instead of by "use the connection the request came in on", then you won't get the responses _at all_ unless your SSH and USM credentials agree. > Can we get away with documenting this properly in the security > considerations section(s)? I don't see a security consideration here. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 14 13:51:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFJp-0002Bv-9S; Fri, 14 Sep 2007 13:51:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFJn-0002Bi-LQ for isms@ietf.org; Fri, 14 Sep 2007 13:51:03 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWFJm-0006K3-HO for isms@ietf.org; Fri, 14 Sep 2007 13:51:03 -0400 Received: from pc6 (1Cust83.tnt13.lnd4.gbr.da.uu.net [62.188.142.83]) by blaster.systems.pipex.net (Postfix) with SMTP id 11CF6E00024E; Fri, 14 Sep 2007 18:50:59 +0100 (BST) Message-ID: <008101c7f6ee$8b768c40$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , References: <00c701c7db25$8e0f78c0$0601a8c0@pc6> <20070912065648.GA18470@elstar.local> <011301c7f63b$fce6dc80$6702a8c0@china.huawei.com> Subject: Re: [Isms] Working Group Last Call tmsm-09 Date: Fri, 14 Sep 2007 18:40:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "David Harrington" To: ; "'tom.petch'" Cc: "'ISMS WG'" Sent: Thursday, September 13, 2007 9:26 PM Subject: RE: [Isms] Working Group Last Call tmsm-09 > > Here are my responses, inline. > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Wednesday, September 12, 2007 2:57 AM > > To: tom.petch > > Cc: ISMS WG > > Subject: Re: [Isms] Working Group Last Call tmsm-09 > > > > On Fri, Aug 10, 2007 at 09:36:34AM +0200, tom.petch wrote: > > > > > > a) (in a separate e-mail) > > > > > c) 3.2.1.2 I think that the transport model MUST be aware > > of the mapping between > > > securityName and transportspecificName else how can it > > select the right > > > transport? > > > > I think an SNMP application passed the transportDomain and > > transportAddress to the dispatcher in the sendPdu() ASI and hence the > > dispatcher knows the transport to be used. Or was your point that you > > want the text > > > > If a message is secured using a secure transport layer, then the > > Transport Model should provide the translation from the > > authenticated > > identity (e.g., an SSH user name) to the securityName in step 3. > > > > to be changed such that it reads > > > > If a message is secured using a secure transport layer, then the > > Transport Model provides the translation from the authenticated > > identity (e.g., an SSH user name) to the securityName in step 2. > > > > should is more accurate because it is possible that a future transport > model might not provide this translation for a valid technical reason. > Removing the should makes this an implicit MUST, which I believe is an > unnecessary CLR. > See separate e-mail > > > > > f) 3.3.2 would seem to preclude the renegotiation of keys, > > a recommended > > > practice during a long running session. Suggest a > > rewording of the two > > > sentences starting 'Cryptographic keys ...' to > > > > > > "Fresh session keys should be established at the beginning > > of each session in > > > order to provide authentication, integrity and > > confidentiality, whichever of > > > these services are required." > > > > As technical contributor, I am actually uneasy with both the existing > > text and the suggested improvement since there are cases where you > > really like to use session resumption due to the very short lifetime > > of the underlying connections and the computational costs associated > > with creating session keys. Perhaps we should just state that the > > transport model should have a feature to establish and renegotiate > > session keys instead of requiring this to happen at the beginning of > > each session. > > I changed the text slightly: > "Cryptographic keys associated with the transport session SHOULD be > used to provide authentication, integrity checking, and encryption > services, as needed, for data that is communicated during the session. > The cryptographic protocols used to establish keys for a Transport > Model session SHOULD ensure that fresh new session keys are generated > for each session." > > I changed the first sentence to reflect that the keys were associated > with the session, without saying when they were generated, and added > the "as needed" clause to reflect that not all servcies are > necessarily required for all transport models. I did not change the > second sentence; the SHOULD permits the valid technical exception of > support for session resumption, while still including the > recommendation for the start of each session. (and session resumtpion > presumably is resuming the same session.) > OK > > > > > > > h) 5.2 'The tmStateReference captured > > > during processing of an incoming message SHOULD include > > a transport- > > > specific session identifier.' > > > > > > I think that the nature of this identifier MUST be specified, either in the > > > security or transport model. Getting it wrong invalidates the security and it > > > is not obvious what it should; the right answers for TLS and SSH are quite > > > different. > > > > I do not see why this needs to be specified - this identifier never > > leaves the agent and is thus purely internal to the implementation > and > > the precise format of this identifier actually to some extend also > > depends on the libraries that you use. Sure, the TSM and the *TMs > need > > to agree on the format of these identifiers so that they do not mix > up > > identifiers but I as a technical contributor consider this > > implementation detail. (We use magic numbers at the beginning of a > > struct to deal with this but I believe this is implementation > detail.) > > We could define a MIB, which is a virutal interface to an > implementation-specific detail, and the implementation can totally > choose to ignore our standardized interface, and it would make no > difference on-the-wire. So I agree that we do not need to specify > this. > > If you have an example of how this could be a security problem, I have > no problem with you creating an implementer's note advising > implementers to be sure the implementation in the security models and > the implementation in the transport models agree on the format, but I > would certainly like to have that note explain why this is necessary > for security reasons. By the way, note the plurals, in case there are > multiple SMs that can work with the same TM, or multiple TMs that can > work with the same SM. And, of course, we would need consensus on the > content of the note. > My issue here was/is that an identifier may or may not identify the session in a secure manner and I want it to be in a secure manner. For example, the SSH session ID is a cryptographic binding of all relevant SSHv2 connection parameters so you can trust, cryptographically, that it identifies the right session. By contrast, for TLS, the session ID is not sufficient as it is server-assigned and so could be assigned by an MITM to match a server's. And I wanted this identifier to be secure so that when passed securely to an upper layer, then that could be used for channel binding, something which I believe can solve a number of security problems and so would not want precluded at a subsystem level (eg the initial SSH or TLS transport uses weak authentication which could allow a MITM but then a further authentication by security model or application, perhaps accesssing a third party, verifies that there is no MITM). If the session identifier does not identify the session in a secure manner, then (apart from removing the option of channel binding) I think that an application may be fooled into sending data over the wrong session. SSHTM says that if a session is closed, then session state information should be discarded - I am not sure if this is enough to guard against this. Tom Petch > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 14 13:51:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFJn-0002Ba-58; Fri, 14 Sep 2007 13:51:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFJl-0002BO-De for isms@ietf.org; Fri, 14 Sep 2007 13:51:01 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWFJk-0006Ju-LT for isms@ietf.org; Fri, 14 Sep 2007 13:51:01 -0400 Received: from pc6 (1Cust83.tnt13.lnd4.gbr.da.uu.net [62.188.142.83]) by blaster.systems.pipex.net (Postfix) with SMTP id 3BD84E0001C7; Fri, 14 Sep 2007 18:50:56 +0100 (BST) Message-ID: <008001c7f6ee$8a60d680$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , References: <00c701c7db25$8e0f78c0$0601a8c0@pc6> <20070912065648.GA18470@elstar.local> <011301c7f63b$fce6dc80$6702a8c0@china.huawei.com> Subject: Re: [Isms] Working Group Last Call tmsm-09c Date: Fri, 14 Sep 2007 18:38:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Separate reply for issue c) Tom Petch ----- Original Message ----- From: "David Harrington" To: ; "'tom.petch'" Cc: "'ISMS WG'" Sent: Thursday, September 13, 2007 9:26 PM Subject: RE: [Isms] Working Group Last Call tmsm-09 > > Here are my responses, inline. > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Wednesday, September 12, 2007 2:57 AM > > To: tom.petch > > Cc: ISMS WG > > Subject: Re: [Isms] Working Group Last Call tmsm-09 > > > > On Fri, Aug 10, 2007 at 09:36:34AM +0200, tom.petch wrote: > > > Eeee, reading this does not get any easier > > > > > > > > c) 3.2.1.2 I think that the transport model MUST be aware > > of the mapping between > > > securityName and transportspecificName else how can it > > select the right > > > transport? > > > > I think an SNMP application passed the transportDomain and > > transportAddress to the dispatcher in the sendPdu() ASI and hence the > > dispatcher knows the transport to be used. Or was your point that you > > want the text > > > > If a message is secured using a secure transport layer, then the > > Transport Model should provide the translation from the > > authenticated > > identity (e.g., an SSH user name) to the securityName in step 3. > > > > to be changed such that it reads > > > > If a message is secured using a secure transport layer, then the > > Transport Model provides the translation from the authenticated > > identity (e.g., an SSH user name) to the securityName in step 2. > > > > should is more accurate because it is possible that a future transport > model might not provide this translation for a valid technical reason. > Removing the should makes this an implicit MUST, which I believe is an > unnecessary CLR. > I was hoping for an implicit (or even explicit) MUST. This is for me the one unresolved issue, and one which has been discussed further, by others, since my initial e-mail. Taking a step back from the details of cache, elements of procedure and ASI, what I would like (future) models to be able to do is a) map the name used in setting up the session into a different one, in the TM; mapping can be an identity mapping b) map the original name or the different one into the securityName used for access control and in the sendPdu/processPdu, in the SM; mapping can be an identity mapping c) responses can be forced to go back over the same session as requests came in on d) application can select the session, pre-existing or new (using transportDomain, transportAddress, securityModel, securityName, securityLevel) (eg so a NO can use a pre-exisiting CG/CR session) e) a secure transport may offer a greater level of security than an application requested but the application need not be aware of this all of which I think has been agreed over the life of this group. So I work through the subsystems as amended by tmsm to see if this is possible, if the right parameters are passed in the right places, by cache and ASI; and I look for MUSTs to ensure it is, that a TM will do what it needs to to enable a SM to play its part to achieve this. Mostly, my suggestions have been accepted, albeit with an improvement in the wording, but it is around security name and security level that I still see difficulties. And, as the recent discussion of USM over SSH showed (USM uses name from securityParameters and has no knowledge of what the TM is using), I think it not obvious from tmsm what is and is not possible. Tom Petch /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 14 13:51:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFJp-0002Bv-9S; Fri, 14 Sep 2007 13:51:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFJn-0002Bi-LQ for isms@ietf.org; Fri, 14 Sep 2007 13:51:03 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWFJm-0006K3-HO for isms@ietf.org; Fri, 14 Sep 2007 13:51:03 -0400 Received: from pc6 (1Cust83.tnt13.lnd4.gbr.da.uu.net [62.188.142.83]) by blaster.systems.pipex.net (Postfix) with SMTP id 11CF6E00024E; Fri, 14 Sep 2007 18:50:59 +0100 (BST) Message-ID: <008101c7f6ee$8b768c40$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , References: <00c701c7db25$8e0f78c0$0601a8c0@pc6> <20070912065648.GA18470@elstar.local> <011301c7f63b$fce6dc80$6702a8c0@china.huawei.com> Subject: Re: [Isms] Working Group Last Call tmsm-09 Date: Fri, 14 Sep 2007 18:40:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "David Harrington" To: ; "'tom.petch'" Cc: "'ISMS WG'" Sent: Thursday, September 13, 2007 9:26 PM Subject: RE: [Isms] Working Group Last Call tmsm-09 > > Here are my responses, inline. > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Wednesday, September 12, 2007 2:57 AM > > To: tom.petch > > Cc: ISMS WG > > Subject: Re: [Isms] Working Group Last Call tmsm-09 > > > > On Fri, Aug 10, 2007 at 09:36:34AM +0200, tom.petch wrote: > > > > > > a) (in a separate e-mail) > > > > > c) 3.2.1.2 I think that the transport model MUST be aware > > of the mapping between > > > securityName and transportspecificName else how can it > > select the right > > > transport? > > > > I think an SNMP application passed the transportDomain and > > transportAddress to the dispatcher in the sendPdu() ASI and hence the > > dispatcher knows the transport to be used. Or was your point that you > > want the text > > > > If a message is secured using a secure transport layer, then the > > Transport Model should provide the translation from the > > authenticated > > identity (e.g., an SSH user name) to the securityName in step 3. > > > > to be changed such that it reads > > > > If a message is secured using a secure transport layer, then the > > Transport Model provides the translation from the authenticated > > identity (e.g., an SSH user name) to the securityName in step 2. > > > > should is more accurate because it is possible that a future transport > model might not provide this translation for a valid technical reason. > Removing the should makes this an implicit MUST, which I believe is an > unnecessary CLR. > See separate e-mail > > > > > f) 3.3.2 would seem to preclude the renegotiation of keys, > > a recommended > > > practice during a long running session. Suggest a > > rewording of the two > > > sentences starting 'Cryptographic keys ...' to > > > > > > "Fresh session keys should be established at the beginning > > of each session in > > > order to provide authentication, integrity and > > confidentiality, whichever of > > > these services are required." > > > > As technical contributor, I am actually uneasy with both the existing > > text and the suggested improvement since there are cases where you > > really like to use session resumption due to the very short lifetime > > of the underlying connections and the computational costs associated > > with creating session keys. Perhaps we should just state that the > > transport model should have a feature to establish and renegotiate > > session keys instead of requiring this to happen at the beginning of > > each session. > > I changed the text slightly: > "Cryptographic keys associated with the transport session SHOULD be > used to provide authentication, integrity checking, and encryption > services, as needed, for data that is communicated during the session. > The cryptographic protocols used to establish keys for a Transport > Model session SHOULD ensure that fresh new session keys are generated > for each session." > > I changed the first sentence to reflect that the keys were associated > with the session, without saying when they were generated, and added > the "as needed" clause to reflect that not all servcies are > necessarily required for all transport models. I did not change the > second sentence; the SHOULD permits the valid technical exception of > support for session resumption, while still including the > recommendation for the start of each session. (and session resumtpion > presumably is resuming the same session.) > OK > > > > > > > h) 5.2 'The tmStateReference captured > > > during processing of an incoming message SHOULD include > > a transport- > > > specific session identifier.' > > > > > > I think that the nature of this identifier MUST be specified, either in the > > > security or transport model. Getting it wrong invalidates the security and it > > > is not obvious what it should; the right answers for TLS and SSH are quite > > > different. > > > > I do not see why this needs to be specified - this identifier never > > leaves the agent and is thus purely internal to the implementation > and > > the precise format of this identifier actually to some extend also > > depends on the libraries that you use. Sure, the TSM and the *TMs > need > > to agree on the format of these identifiers so that they do not mix > up > > identifiers but I as a technical contributor consider this > > implementation detail. (We use magic numbers at the beginning of a > > struct to deal with this but I believe this is implementation > detail.) > > We could define a MIB, which is a virutal interface to an > implementation-specific detail, and the implementation can totally > choose to ignore our standardized interface, and it would make no > difference on-the-wire. So I agree that we do not need to specify > this. > > If you have an example of how this could be a security problem, I have > no problem with you creating an implementer's note advising > implementers to be sure the implementation in the security models and > the implementation in the transport models agree on the format, but I > would certainly like to have that note explain why this is necessary > for security reasons. By the way, note the plurals, in case there are > multiple SMs that can work with the same TM, or multiple TMs that can > work with the same SM. And, of course, we would need consensus on the > content of the note. > My issue here was/is that an identifier may or may not identify the session in a secure manner and I want it to be in a secure manner. For example, the SSH session ID is a cryptographic binding of all relevant SSHv2 connection parameters so you can trust, cryptographically, that it identifies the right session. By contrast, for TLS, the session ID is not sufficient as it is server-assigned and so could be assigned by an MITM to match a server's. And I wanted this identifier to be secure so that when passed securely to an upper layer, then that could be used for channel binding, something which I believe can solve a number of security problems and so would not want precluded at a subsystem level (eg the initial SSH or TLS transport uses weak authentication which could allow a MITM but then a further authentication by security model or application, perhaps accesssing a third party, verifies that there is no MITM). If the session identifier does not identify the session in a secure manner, then (apart from removing the option of channel binding) I think that an application may be fooled into sending data over the wrong session. SSHTM says that if a session is closed, then session state information should be discarded - I am not sure if this is enough to guard against this. Tom Petch > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 14 13:51:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFJn-0002Ba-58; Fri, 14 Sep 2007 13:51:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFJl-0002BO-De for isms@ietf.org; Fri, 14 Sep 2007 13:51:01 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWFJk-0006Ju-LT for isms@ietf.org; Fri, 14 Sep 2007 13:51:01 -0400 Received: from pc6 (1Cust83.tnt13.lnd4.gbr.da.uu.net [62.188.142.83]) by blaster.systems.pipex.net (Postfix) with SMTP id 3BD84E0001C7; Fri, 14 Sep 2007 18:50:56 +0100 (BST) Message-ID: <008001c7f6ee$8a60d680$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , References: <00c701c7db25$8e0f78c0$0601a8c0@pc6> <20070912065648.GA18470@elstar.local> <011301c7f63b$fce6dc80$6702a8c0@china.huawei.com> Subject: Re: [Isms] Working Group Last Call tmsm-09c Date: Fri, 14 Sep 2007 18:38:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Separate reply for issue c) Tom Petch ----- Original Message ----- From: "David Harrington" To: ; "'tom.petch'" Cc: "'ISMS WG'" Sent: Thursday, September 13, 2007 9:26 PM Subject: RE: [Isms] Working Group Last Call tmsm-09 > > Here are my responses, inline. > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Wednesday, September 12, 2007 2:57 AM > > To: tom.petch > > Cc: ISMS WG > > Subject: Re: [Isms] Working Group Last Call tmsm-09 > > > > On Fri, Aug 10, 2007 at 09:36:34AM +0200, tom.petch wrote: > > > Eeee, reading this does not get any easier > > > > > > > > c) 3.2.1.2 I think that the transport model MUST be aware > > of the mapping between > > > securityName and transportspecificName else how can it > > select the right > > > transport? > > > > I think an SNMP application passed the transportDomain and > > transportAddress to the dispatcher in the sendPdu() ASI and hence the > > dispatcher knows the transport to be used. Or was your point that you > > want the text > > > > If a message is secured using a secure transport layer, then the > > Transport Model should provide the translation from the > > authenticated > > identity (e.g., an SSH user name) to the securityName in step 3. > > > > to be changed such that it reads > > > > If a message is secured using a secure transport layer, then the > > Transport Model provides the translation from the authenticated > > identity (e.g., an SSH user name) to the securityName in step 2. > > > > should is more accurate because it is possible that a future transport > model might not provide this translation for a valid technical reason. > Removing the should makes this an implicit MUST, which I believe is an > unnecessary CLR. > I was hoping for an implicit (or even explicit) MUST. This is for me the one unresolved issue, and one which has been discussed further, by others, since my initial e-mail. Taking a step back from the details of cache, elements of procedure and ASI, what I would like (future) models to be able to do is a) map the name used in setting up the session into a different one, in the TM; mapping can be an identity mapping b) map the original name or the different one into the securityName used for access control and in the sendPdu/processPdu, in the SM; mapping can be an identity mapping c) responses can be forced to go back over the same session as requests came in on d) application can select the session, pre-existing or new (using transportDomain, transportAddress, securityModel, securityName, securityLevel) (eg so a NO can use a pre-exisiting CG/CR session) e) a secure transport may offer a greater level of security than an application requested but the application need not be aware of this all of which I think has been agreed over the life of this group. So I work through the subsystems as amended by tmsm to see if this is possible, if the right parameters are passed in the right places, by cache and ASI; and I look for MUSTs to ensure it is, that a TM will do what it needs to to enable a SM to play its part to achieve this. Mostly, my suggestions have been accepted, albeit with an improvement in the wording, but it is around security name and security level that I still see difficulties. And, as the recent discussion of USM over SSH showed (USM uses name from securityParameters and has no knowledge of what the TM is using), I think it not obvious from tmsm what is and is not possible. Tom Petch /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 14 13:58:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFQY-00068u-37; Fri, 14 Sep 2007 13:58:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFQX-00068m-3S for isms@ietf.org; Fri, 14 Sep 2007 13:58:01 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWFQV-0004yc-Qn for isms@ietf.org; Fri, 14 Sep 2007 13:58:01 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc11) with SMTP id <20070914175758m11003mi60e>; Fri, 14 Sep 2007 17:57:58 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'Juergen Schoenwaelder'" References: <20070914121508.GC23252@elstar.local> Subject: RE: [Isms] Working Group Last Call - securityName Date: Fri, 14 Sep 2007 13:57:44 -0400 Message-ID: <016c01c7f6f8$c1333770$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf26FYOAg5QPt7aSJSiP55sAASAZgAEEKHw In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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 How does this look? 7.1. Coexistence, Security Parameters, and Access Control In the RFC3411 architecture, the Message Processing Model makes the decision about which Security Model to use. The architectural change described by this document does not alter that. The architecture change described by this document does howvwer, allow SNMP to support two different approaches to security - message- driven security and transport-driven security. With message-driven security, SNMP provides its own security, and passes security parameters within the SNMP message; with transport-driven security, SNMP depends on an external entity to provide security during transport by "wrapping" the SNMP message. Security models defined before the Transport Security Model (i.e., SNMPv1, SNMPv2c, and USM) do not support transport-based security, and only have access to the security parameters contained within the SNMP message. They do not know about the security parameters associated with a secure transport. As a result, the Access Control Subsystem bases its decisions on the security parameters extracted from the SNMP message, not on transport-based security parameters. Implications of coexistence of older security models with secure transport models are known: An SNMPv1 message will always be paired with an SNMPv1 Security Model (per RFC3584), regardless of the transport mappng or transport model used, and access controls will be based on the community name. An SNMPv2c message will always be paired with an SNMPv2c Security Model (per RFC3584), regardless of the transport mappng or transport model used, and access controls will be based on the community name.. An SNMPv3 message will always be paired with the securityModel specified in the msgSecurityParameters field of the message (per RFC3412), regardless of the transport mappng or transport model used. If the SNMPv3 message specifies the User-based Security Model (USM), access controls will be based on the USM user.If the SNMPv3 message specifies the Transport Security Model (TSM), access controls will be based on the prinipal authenticated by the transport. > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Friday, September 14, 2007 12:00 PM > To: Juergen Schoenwaelder > Cc: David Harrington; 'tom.petch'; 'ISMS WG' > Subject: Re: [Isms] Working Group Last Call - securityName > > On Fri, 14 Sep 2007, Juergen Schoenwaelder wrote: > > > I think this can compromise security to some extend if you > have USM in > > authNoPriv mode since the response comes back in cleartext and may > > contain data the attacker (who of course has to be able to > > authenticate him as Bob) is not allowed to see. > > No. If the attacker can authenticate as Bob, the attacker > _is_ Bob, for > all intents and purposes. He is allowed to see anything that Bob is > allowed to see, and so security is not compromised by giving him > information that Bob is allowed to have. > > > Put another way, what the scenario I described means is that > if a single > entity possesses SSH credentials for Alice and Bob, and USM > credentials > for Bob, then he can (with some effort) arrange to send a > request over an > SSH connection authenticated as Alice and get the response over a > different SSH connection authenticated as Bob. This is a > little odd, and > I can't think of any useful reason to do it, but it doesn't > mean there is > a security problem. > > > > But this seems a general USM "security property" if you want. With > > USM over UDP, after an authNoPriv request has been sent, an attacker > > can get the response by replacing the UDP endpoint used by > the command > > generator's SNMP engine with its own endpoint. > > Yes. Of course, with SSH involved, a real attacker need not > even replace > the UDP endpoint in this case -- all he has to do is watch > all the traffic > sent by the CP or received by the CG. > > > > I believe it is important to realize that with USM over SSH you get > > the security of USM and nothing more - and USM does not protect > > responses unless you use authPriv mode. > > That's not entirely true -- if you verify the SSH server's > identity, you > get to run USM over an encrypted tunnel. You can even do so securely. > The only problem is that if we try to match outgoing messages to SSH > sessions by transport address and security name instead of by "use the > connection the request came in on", then you won't get the > responses _at > all_ unless your SSH and USM credentials agree. > > > Can we get away with documenting this properly in the security > > considerations section(s)? > > I don't see a security consideration here. > > -- Jeff > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 14 17:56:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJ98-0002Bf-Ix; Fri, 14 Sep 2007 17:56:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJ97-0002Ba-4C for isms@ietf.org; Fri, 14 Sep 2007 17:56:17 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWJ95-0004Sa-TQ for isms@ietf.org; Fri, 14 Sep 2007 17:56:17 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l8ELu6fo008762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Sep 2007 17:56:07 -0400 (EDT) Date: Fri, 14 Sep 2007 17:56:06 -0400 From: Jeffrey Hutzelman To: "tom.petch" , David Harrington , j.schoenwaelder@jacobs-university.de Subject: Re: [Isms] Working Group Last Call tmsm-09 Message-ID: <1F19AA0B104D290A7B99E001@sirius.fac.cs.cmu.edu> In-Reply-To: <008101c7f6ee$8b768c40$0601a8c0@pc6> References: <00c701c7db25$8e0f78c0$0601a8c0@pc6> <20070912065648.GA18470@elstar.local> <011301c7f63b$fce6dc80$6702a8c0@china.huawei.com> <008101c7f6ee$8b768c40$0601a8c0@pc6> Originator-Info: login-token=Mulberry:01yWLnUzPKXMcVrV/U/OAXwmDUHn5QlmA21xW4/+I=; 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: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'ISMS WG' , Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Friday, September 14, 2007 06:40:36 PM +0200 "tom.petch" wrote: > My issue here was/is that an identifier may or may not identify the > session in a secure manner and I want it to be in a secure manner. For > example, the SSH session ID is a cryptographic binding of all relevant > SSHv2 connection parameters so you can trust, cryptographically, that it > identifies the right session. By contrast, for TLS, the session ID is > not sufficient as it is server-assigned and so could be assigned by an > MITM to match a server's. And I wanted this identifier to be secure so > that when passed securely to an upper layer, then that could be used for > channel binding, something which I believe can solve a number of security > problems and so would not want precluded at a subsystem level (eg the > initial SSH or TLS transport uses weak authentication which could allow a > MITM but then a further authentication by security model or application, > perhaps accesssing a third party, verifies that there is no MITM). > > If the session identifier does not identify the session in a secure > manner, then (apart from removing the option of channel binding) I think > that an application may be fooled into sending data over the wrong > session. We're really not talking about an externally-provided identifier that is used to find a session from among a random selection of potentially existing sessions. We're talking about a mechanism for making sure a response goes out over the same session the request came in on. This isn't some complex standardized data structure with cryptographic binding; it's a pointer. You don't need to say "the session with this exchange hash" (which you don't know anyway, because that's below the abstraction boundary). It's sufficient to say "the session attached to file descriptor 12". If you _really_ think you want to be able to have SNMP applications do channel binding to a secure transport, then you need to figure out a way to pass channel bindings up through the SNMP architecture from the secure transport to the application. Specifying what the channel bindings are isn't up to the SNMP framework; in most cases, it isn't even really up to the particular transport mapping, but instead will be specified for the underlying transport. Personally, I don't see SNMP as a layer above which channel bindings need to be specified. We are binding SNMP authentication into the secure transport below (in a transport-specific fashion) precisely so that SNMP applications don't need to worry about any such thing. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 14 18:00:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJDc-0007Yg-A6; Fri, 14 Sep 2007 18:00:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJDa-0007YW-Si for isms@ietf.org; Fri, 14 Sep 2007 18:00:54 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWJDZ-0004fM-MF for isms@ietf.org; Fri, 14 Sep 2007 18:00:54 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l8EM0nHb008765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Sep 2007 18:00:49 -0400 (EDT) Date: Fri, 14 Sep 2007 18:00:49 -0400 From: Jeffrey Hutzelman To: David Harrington , "'Juergen Schoenwaelder'" Subject: RE: [Isms] Working Group Last Call - securityName Message-ID: In-Reply-To: <016c01c7f6f8$c1333770$6702a8c0@china.huawei.com> References: <20070914121508.GC23252@elstar.local> <016c01c7f6f8$c1333770$6702a8c0@china.huawei.com> Originator-Info: login-token=Mulberry:01EBOQdXp7BelcXgj2Q5HA5KeFx6CXRwl9iL7aRpM=; 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: 7bac9cb154eb5790ae3b2913587a40de Cc: 'ISMS WG' , Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Friday, September 14, 2007 01:57:44 PM -0400 David Harrington wrote: > How does this look? > > 7.1. Coexistence, Security Parameters, and Access Control This looks good. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Sep 15 02:51:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWRUY-0004oc-Nw; Sat, 15 Sep 2007 02:50:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWRUX-0004oW-2u for isms@ietf.org; Sat, 15 Sep 2007 02:50:57 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWRUV-0005EE-4Y for isms@ietf.org; Sat, 15 Sep 2007 02:50:56 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E40586415; Sat, 15 Sep 2007 08:50:54 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 07869-09; Sat, 15 Sep 2007 08:50:49 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 19C96863ED; Sat, 15 Sep 2007 08:50:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4EDB633C7BD; Sat, 15 Sep 2007 08:50:48 +0200 (CEST) Date: Sat, 15 Sep 2007 08:50:48 +0200 From: Juergen Schoenwaelder To: "tom.petch" Subject: Re: [Isms] Working Group Last Call tmsm-09c Message-ID: <20070915065048.GA18718@elstar.local> Mail-Followup-To: "tom.petch" , David Harrington , 'ISMS WG' References: <20070912065648.GA18470@elstar.local> <011301c7f63b$fce6dc80$6702a8c0@china.huawei.com> <008001c7f6ee$8a60d680$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008001c7f6ee$8a60d680$0601a8c0@pc6> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Fri, Sep 14, 2007 at 06:38:55PM +0200, tom.petch wrote: > This is for me the one unresolved issue, and one which has been discussed > further, by others, since my initial e-mail. Taking a step back from the > details of cache, elements of procedure and ASI, what I would like (future) > models to be able to do is > > a) map the name used in setting up the session into a different one, in the TM; > mapping can be an identity mapping > > b) map the original name or the different one into the securityName used for > access control and in the sendPdu/processPdu, in the SM; mapping can be an > identity mapping > > c) responses can be forced to go back over the same session as requests came in > on > > d) application can select the session, pre-existing or new (using > transportDomain, transportAddress, securityModel, securityName, securityLevel) > (eg so a NO can use a pre-exisiting CG/CR session) > > e) a secure transport may offer a greater level of security than an application > requested but the application need not be aware of this > > all of which I think has been agreed over the life of this group. > > So I work through the subsystems as amended by tmsm to see if this is possible, > if the right parameters are passed in the right places, by cache and ASI; and I > look for MUSTs to ensure it is, that a TM will do what it needs to to enable a > SM to play its part to achieve this. Mostly, my suggestions have been accepted, > albeit with an improvement in the wording, but it is around security name and > security level that I still see difficulties. Please be concrete and point to the specific text which you think is problematic and supply and explanation with suggested replacement text. The idea of "I see difficulties around something" do not help us to get issues worked out and resolved. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Sep 15 02:59:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWRcQ-0003lH-1a; Sat, 15 Sep 2007 02:59:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWRcO-0003lB-GO for isms@ietf.org; Sat, 15 Sep 2007 02:59:04 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWRcN-00016f-L4 for isms@ietf.org; Sat, 15 Sep 2007 02:59:04 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7BE3863F1; Sat, 15 Sep 2007 08:59:01 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08480-07; Sat, 15 Sep 2007 08:58:56 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8DDC5863EF; Sat, 15 Sep 2007 08:58:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B7FF133C807; Sat, 15 Sep 2007 08:58:55 +0200 (CEST) Date: Sat, 15 Sep 2007 08:58:55 +0200 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Subject: Re: [Isms] Working Group Last Call - securityName Message-ID: <20070915065855.GB18718@elstar.local> Mail-Followup-To: Jeffrey Hutzelman , David Harrington , "'tom.petch'" , 'ISMS WG' References: <20070914121508.GC23252@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Fri, Sep 14, 2007 at 11:59:37AM -0400, Jeffrey Hutzelman wrote: > > I think this can compromise security to some extend if you have USM in > > authNoPriv mode since the response comes back in cleartext and may > > contain data the attacker (who of course has to be able to > > authenticate him as Bob) is not allowed to see. > > No. If the attacker can authenticate as Bob, the attacker _is_ Bob, for > all intents and purposes. He is allowed to see anything that Bob is > allowed to see, and so security is not compromised by giving him > information that Bob is allowed to have. I am talking about the response. The response in USM goes where the "agent" believes Bob to be and that endpoint might not be Bob anymore. > Put another way, what the scenario I described means is that if a single > entity possesses SSH credentials for Alice and Bob, and USM credentials > for Bob, then he can (with some effort) arrange to send a request over an > SSH connection authenticated as Alice and get the response over a > different SSH connection authenticated as Bob. This is a little odd, and > I can't think of any useful reason to do it, but it doesn't mean there is > a security problem. > > > But this seems a general USM "security property" if you want. With > > USM over UDP, after an authNoPriv request has been sent, an attacker > > can get the response by replacing the UDP endpoint used by the command > > generator's SNMP engine with its own endpoint. > > Yes. Of course, with SSH involved, a real attacker need not even replace > the UDP endpoint in this case -- all he has to do is watch all the traffic > sent by the CP or received by the CG. > > > I believe it is important to realize that with USM over SSH you get > > the security of USM and nothing more - and USM does not protect > > responses unless you use authPriv mode. > > That's not entirely true -- if you verify the SSH server's identity, you > get to run USM over an encrypted tunnel. You can even do so securely. > The only problem is that if we try to match outgoing messages to SSH > sessions by transport address and security name instead of by "use the > connection the request came in on", then you won't get the responses _at > all_ unless your SSH and USM credentials agree. An existing USM implementation following the architecture does not know about the tmStateReference and hence the SSHTM lacks information. Im real code, I believe all this is a non-issue since the binding of the various pieces is typically much stronger compared to the architectural model. > > Can we get away with documenting this properly in the security > > considerations section(s)? > > I don't see a security consideration here. So you are suggesting to do nothing? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Sep 15 03:01:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWReT-00059r-Lj; Sat, 15 Sep 2007 03:01:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWReS-00059l-He for isms@ietf.org; Sat, 15 Sep 2007 03:01:12 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWReR-00019O-NZ for isms@ietf.org; Sat, 15 Sep 2007 03:01:12 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3F596863F1; Sat, 15 Sep 2007 09:01:11 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08924-02; Sat, 15 Sep 2007 09:01:05 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ACE63863EF; Sat, 15 Sep 2007 09:01:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 041F433C877; Sat, 15 Sep 2007 09:01:04 +0200 (CEST) Date: Sat, 15 Sep 2007 09:01:04 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] Working Group Last Call - securityName Message-ID: <20070915070104.GC18718@elstar.local> Mail-Followup-To: David Harrington , 'Jeffrey Hutzelman' , "'tom.petch'" , 'ISMS WG' References: <20070914121508.GC23252@elstar.local> <016c01c7f6f8$c1333770$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <016c01c7f6f8$c1333770$6702a8c0@china.huawei.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: 'ISMS WG' , 'Jeffrey Hutzelman' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Fri, Sep 14, 2007 at 01:57:44PM -0400, David Harrington wrote: > How does this look? > > 7.1. Coexistence, Security Parameters, and Access Control > > In the RFC3411 architecture, the Message Processing Model makes the > decision about which Security Model to use. The architectural > change > described by this document does not alter that. > > The architecture change described by this document does howvwer, > allow SNMP to support two different approaches to security - > message- > driven security and transport-driven security. With message-driven > security, SNMP provides its own security, and passes security > parameters within the SNMP message; with transport-driven security, > SNMP depends on an external entity to provide security during > transport by "wrapping" the SNMP message. > > Security models defined before the Transport Security Model (i.e., > SNMPv1, SNMPv2c, and USM) do not support transport-based security, > and only have access to the security parameters contained within > the > SNMP message. They do not know about the security parameters > associated with a secure transport. As a result, the Access > Control > Subsystem bases its decisions on the security parameters extracted > from the SNMP message, not on transport-based security parameters. > > Implications of coexistence of older security models with secure > transport models are known: > An SNMPv1 message will always be paired with an SNMPv1 Security > Model (per RFC3584), regardless of the transport mappng or > transport model used, and access controls will be based on the > community name. > An SNMPv2c message will always be paired with an SNMPv2c > Security > Model (per RFC3584), regardless of the transport mappng or > transport model used, and access controls will be based on the > community name.. > An SNMPv3 message will always be paired with the securityModel > specified in the msgSecurityParameters field of the message (per > RFC3412), regardless of the transport mappng or transport model > used. If the SNMPv3 message specifies the User-based Security > Model (USM), access controls will be based on the USM user.If > the > SNMPv3 message specifies the Transport Security Model (TSM), > access controls will be based on the prinipal authenticated by > the > transport. Fine with me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Sep 15 05:08:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWTdi-0008A9-CQ; Sat, 15 Sep 2007 05:08:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWTdh-00086b-8m for isms@ietf.org; Sat, 15 Sep 2007 05:08:33 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWTdg-0004wO-J4 for isms@ietf.org; Sat, 15 Sep 2007 05:08:32 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l8F97f9X022225; Sat, 15 Sep 2007 04:07:41 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Sep 2007 04:07:41 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Sep 2007 11:07:39 +0200 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 - securityName Date: Sat, 15 Sep 2007 11:07:34 +0200 Message-ID: In-Reply-To: <016c01c7f6f8$c1333770$6702a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Working Group Last Call - securityName Thread-Index: Acf26FYOAg5QPt7aSJSiP55sAASAZgAEEKHwAB++GHA= References: <20070914121508.GC23252@elstar.local> <016c01c7f6f8$c1333770$6702a8c0@china.huawei.com> From: "Wijnen, Bert \(Bert\)" To: "David Harrington" , "Jeffrey Hutzelman" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 15 Sep 2007 09:07:39.0303 (UTC) FILETIME=[DD857B70:01C7F777] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ISMS WG X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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 Fine by me. Too bad we can't do SNMPv1/v2c over SSH unless we do more work. But good we describe it. a few typos are pointed out below Bert Wijnen =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Friday, September 14, 2007 7:58 PM > To: 'Jeffrey Hutzelman'; 'Juergen Schoenwaelder' > Cc: 'ISMS WG' > Subject: RE: [Isms] Working Group Last Call - securityName >=20 > How does this look? >=20 > 7.1. Coexistence, Security Parameters, and Access Control >=20 > In the RFC3411 architecture, the Message Processing Model makes the > decision about which Security Model to use. The=20 > architectural change > described by this document does not alter that. >=20 > The architecture change described by this document does howvwer, > allow SNMP to support two different approaches to security - > message- > driven security and transport-driven security. With message-driven > security, SNMP provides its own security, and passes security > parameters within the SNMP message; with transport-driven security, > SNMP depends on an external entity to provide security during > transport by "wrapping" the SNMP message. >=20 > Security models defined before the Transport Security Model (i.e., > SNMPv1, SNMPv2c, and USM) do not support transport-based security, > and only have access to the security parameters contained=20 > within the > SNMP message. They do not know about the security parameters > associated with a secure transport. As a result, the=20 > Access Control > Subsystem bases its decisions on the security parameters extracted > from the SNMP message, not on transport-based security parameters. >=20 > Implications of coexistence of older security models with secure > transport models are known: > An SNMPv1 message will always be paired with an SNMPv1 Security > Model (per RFC3584), regardless of the transport mappng or s/mappng/mapping/ > transport model used, and access controls will be based on the > community name. > An SNMPv2c message will always be paired with an=20 > SNMPv2c Security > Model (per RFC3584), regardless of the transport mappng or s/mappng/mapping/ > transport model used, and access controls will be based on the > community name.. > An SNMPv3 message will always be paired with the securityModel > specified in the msgSecurityParameters field of the message (per > RFC3412), regardless of the transport mappng or transport model > used. If the SNMPv3 message specifies the User-based Security > Model (USM), access controls will be based on the USM=20 > user.If the > SNMPv3 message specifies the Transport Security Model (TSM), > access controls will be based on the prinipal=20 s/prinipal/principal/ > authenticated by the > transport. >=20 > =20 Bert >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Sep 15 08:55:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWXBf-0000pg-4j; Sat, 15 Sep 2007 08:55:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWXBe-0000pY-Dn for isms@ietf.org; Sat, 15 Sep 2007 08:55:50 -0400 Received: from rwcrmhc15.comcast.net ([216.148.227.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWXBd-0007wV-6I for isms@ietf.org; Sat, 15 Sep 2007 08:55:50 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc15) with SMTP id <20070915125547m1500c62ece>; Sat, 15 Sep 2007 12:55:48 +0000 From: "David Harrington" To: , "'tom.petch'" References: <20070912065648.GA18470@elstar.local> <011301c7f63b$fce6dc80$6702a8c0@china.huawei.com> <008001c7f6ee$8a60d680$0601a8c0@pc6> <20070915065048.GA18718@elstar.local> Subject: RE: [Isms] Working Group Last Call tmsm-09c Date: Sat, 15 Sep 2007 08:55:29 -0400 Message-ID: <01f101c7f797$b4088c90$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf3ZMNgyc532zygSx6Qp+Kw8m3z0QAMt1bA In-Reply-To: <20070915065048.GA18718@elstar.local> X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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 Does the new text I added to the security considerations address this adeqautely? dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Saturday, September 15, 2007 2:51 AM > To: tom.petch > Cc: David Harrington; 'ISMS WG' > Subject: Re: [Isms] Working Group Last Call tmsm-09c > > On Fri, Sep 14, 2007 at 06:38:55PM +0200, tom.petch wrote: > > > This is for me the one unresolved issue, and one which has > been discussed > > further, by others, since my initial e-mail. Taking a step > back from the > > details of cache, elements of procedure and ASI, what I > would like (future) > > models to be able to do is > > > > a) map the name used in setting up the session into a > different one, in the TM; > > mapping can be an identity mapping > > > > b) map the original name or the different one into the > securityName used for > > access control and in the sendPdu/processPdu, in the SM; > mapping can be an > > identity mapping > > > > c) responses can be forced to go back over the same session > as requests came in > > on > > > > d) application can select the session, pre-existing or new (using > > transportDomain, transportAddress, securityModel, > securityName, securityLevel) > > (eg so a NO can use a pre-exisiting CG/CR session) > > > > e) a secure transport may offer a greater level of security > than an application > > requested but the application need not be aware of this > > > > all of which I think has been agreed over the life of this group. > > > > So I work through the subsystems as amended by tmsm to see > if this is possible, > > if the right parameters are passed in the right places, by > cache and ASI; and I > > look for MUSTs to ensure it is, that a TM will do what it > needs to to enable a > > SM to play its part to achieve this. Mostly, my > suggestions have been accepted, > > albeit with an improvement in the wording, but it is around > security name and > > security level that I still see difficulties. > > Please be concrete and point to the specific text which you think is > problematic and supply and explanation with suggested replacement > text. The idea of "I see difficulties around something" do not help us > to get issues worked out and resolved. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Sep 15 09:31:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWXkP-0003b0-J9; Sat, 15 Sep 2007 09:31:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWXkO-0003at-Av for isms@ietf.org; Sat, 15 Sep 2007 09:31:44 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWXkM-0000Qn-Pl for isms@ietf.org; Sat, 15 Sep 2007 09:31:44 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1A5986425; Sat, 15 Sep 2007 15:31:41 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 28686-06; Sat, 15 Sep 2007 15:31:36 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F93086403; Sat, 15 Sep 2007 15:31:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B7A8C33CA9A; Sat, 15 Sep 2007 15:31:35 +0200 (CEST) Date: Sat, 15 Sep 2007 15:31:35 +0200 From: Juergen Schoenwaelder To: "Wijnen, Bert (Bert)" Subject: Re: [Isms] Working Group Last Call - securityName Message-ID: <20070915133135.GC18859@elstar.local> Mail-Followup-To: "Wijnen, Bert (Bert)" , David Harrington , Jeffrey Hutzelman , ISMS WG References: <016c01c7f6f8$c1333770$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ISMS WG , Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Sat, Sep 15, 2007 at 11:07:34AM +0200, Wijnen, Bert (Bert) wrote: > Fine by me. Too bad we can't do SNMPv1/v2c over SSH unless we do more > work. But good we describe it. Bert, the transition path for many people depends on (a) how difficult is it to setup and deploy a new version (including the installation of users and keys) and (b) how much effort it takes to adapt existing scripts or programs (where scripts probably cover a pretty significant fraction of the installed space). In terms of CLI / scripting API changes, TSM has the potential to do really fine, e.g. you go from current NET-SNMP syntax: snmpwalk -v 2c -c public some.router.org ifInOctets to snmpwalk ssh:some.router.org ifInOctets where your local identity is used as the SSH name (and thus snmpSecurityName). If you want some other identity, you write snmpwalk ssh:fred@some.router.org ifInOctets All this I think looks reasonably simple and familiar for CLI folks and it does not at all matter whether under the hood you carry SNMPv2c or SNMPv3 message headers. In terms of agent configuration (again NET-SNMP), you get a few more directives where to find the host keys and that is it. /js PS: For SNMPv2c over SSH, you would probably get something like the following (note I am thinking loud here): snmpwalk -v 2c -c public ssh:some.router.org ifInOctets This might be made to work but is essentially not different from running SNMP over TCP through an SSH tunnel, which you can in principle already do now. My point here, however, is that running SNMPv3/TSM over SSH can actually be made to look simpler than SNMPv2c over SSH (and this might also apply to internal APIs but that surely needs some more work to get sorted out and depends on the particularities of the SNMP stack you use). -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Sep 15 12:17:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWaKu-0002mZ-V3; Sat, 15 Sep 2007 12:17:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWaKt-0002mU-Mn for isms@ietf.org; Sat, 15 Sep 2007 12:17:35 -0400 Received: from rwcrmhc15.comcast.net ([204.127.192.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWaKs-0005AG-G6 for isms@ietf.org; Sat, 15 Sep 2007 12:17:35 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc15) with SMTP id <20070915161733m1500c7pb0e>; Sat, 15 Sep 2007 16:17:33 +0000 From: "David Harrington" To: "'ISMS WG'" Date: Sat, 15 Sep 2007 12:17:18 -0400 Message-ID: <01ff01c7f7b3$e34bf0c0$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf3s+KuP3dEw6ShTnWCtvcTkwqpeg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Isms] tmsm rev 10 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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 have submitted rev 10 of tmsm to the internet-drafts editor. I expect to publish corresponding tsm and sshtm docs within days. David Harrington dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Sep 16 07:07:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWry6-00025l-LZ; Sun, 16 Sep 2007 07:07:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWry5-00022L-DK for isms@ietf.org; Sun, 16 Sep 2007 07:07:13 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWry4-0006MO-4j for isms@ietf.org; Sun, 16 Sep 2007 07:07:13 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l8GB76Ci025587; Sun, 16 Sep 2007 06:07:06 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Sep 2007 06:07:06 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Sep 2007 13:07:04 +0200 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 - securityName Date: Sun, 16 Sep 2007 13:04:55 +0200 Message-ID: In-Reply-To: <20070915133135.GC18859@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Working Group Last Call - securityName Thread-Index: Acf3nMPc10qcF7AcT8SuuCcrq79zewAtA+xQ References: <016c01c7f6f8$c1333770$6702a8c0@china.huawei.com> <20070915133135.GC18859@elstar.local> From: "Wijnen, Bert \(Bert\)" To: X-OriginalArrivalTime: 16 Sep 2007 11:07:04.0548 (UTC) FILETIME=[B6C0DA40:01C7F851] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ISMS WG , 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 Thanks Juergen. I understood it that way too. The issue is that in the SNMPv2c and SNMPv1 community-based security=20 models (in RFC3584) we have define that the securityLevel MUST always be set/assumed to be noAuthNoPriv. And so in the VACM tables, one would probably NEVER allow write access to any MIB object instances. So this SNMPv1/v2c over SSH does not help then, does it? I understand, that in order to fix it, we need to update RFC3584 I guess. Such is life. It would have been nice if this would have come sort of automatic. peace, Bert Wijnen =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Saturday, September 15, 2007 3:32 PM > To: Wijnen, Bert (Bert) > Cc: David Harrington; Jeffrey Hutzelman; ISMS WG > Subject: Re: [Isms] Working Group Last Call - securityName >=20 > On Sat, Sep 15, 2007 at 11:07:34AM +0200, Wijnen, Bert (Bert) wrote: >=20 > > Fine by me. Too bad we can't do SNMPv1/v2c over SSH unless=20 > we do more=20 > > work. But good we describe it. >=20 > Bert, >=20 > the transition path for many people depends on (a) how=20 > difficult is it to setup and deploy a new version (including=20 > the installation of users and keys) and (b) how much effort=20 > it takes to adapt existing scripts or programs (where scripts=20 > probably cover a pretty significant fraction of the installed space). >=20 > In terms of CLI / scripting API changes, TSM has the=20 > potential to do really fine, e.g. you go from current NET-SNMP syntax: >=20 > snmpwalk -v 2c -c public some.router.org ifInOctets >=20 > to=20 >=20 > snmpwalk ssh:some.router.org ifInOctets >=20 > where your local identity is used as the SSH name (and thus=20 > snmpSecurityName). If you want some other identity, you write >=20 > snmpwalk ssh:fred@some.router.org ifInOctets >=20 > All this I think looks reasonably simple and familiar for CLI=20 > folks and it does not at all matter whether under the hood=20 > you carry SNMPv2c or SNMPv3 message headers. In terms of=20 > agent configuration (again NET-SNMP), you get a few more=20 > directives where to find the host keys and that is it. >=20 > /js >=20 > PS: For SNMPv2c over SSH, you would probably get something like the > following (note I am thinking loud here): >=20 > snmpwalk -v 2c -c public ssh:some.router.org ifInOctets >=20 > This might be made to work but is essentially not different from > running SNMP over TCP through an SSH tunnel, which you can in > principle already do now. My point here, however, is that running > SNMPv3/TSM over SSH can actually be made to look simpler than > SNMPv2c over SSH (and this might also apply to internal APIs but > that surely needs some more work to get sorted out and depends on > the particularities of the SNMP stack you use). >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Sep 16 09:10:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWttD-0006Hu-F4; Sun, 16 Sep 2007 09:10:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWttC-0006FR-4Z for isms@ietf.org; Sun, 16 Sep 2007 09:10:18 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWttB-0000RE-MW for isms@ietf.org; Sun, 16 Sep 2007 09:10:17 -0400 Received: from [68.247.223.153] (000-254-839.area3.spcsdns.net [68.247.223.153]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l8GD9vB0000267 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Sun, 16 Sep 2007 09:10:03 -0400 (EDT) From: "Jeffrey Hutzelman" Subject: RE: [Isms] Working Group Last Call - securityName Date: 16 Sep 2007 09:10:00 -0400 To: X-Mailer: ChatterEmail+ for Treo 6xx/700p (3.0.8) Message-ID: <3272778610.2648763@smtp.srv.cs.cmu.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 >From: "Wijnen, Bert \(Bert\)" > >Thanks Juergen. I understood it that way too. > >The issue is that in the SNMPv2c and SNMPv1 community-based security >models (in RFC3584) we have define that the securityLevel MUST always >be set/assumed to be noAuthNoPriv. And so in the VACM tables, one would >probably NEVER allow write access to any MIB object instances. I don't know about that. People used those versions for years before SNMPv3 came along, and surely some of them must have permitted some write access. It is possible to have a deployment in which granting write access is safe even for noauthnopriv. For example, you could have a network in which all hosts are trusted. >So this SNMPv1/v2c over SSH does not help then, does it? Sure it does. You could configure an agent such that ssh is the only permitted transport. >I understand, that in order to fix it, we need to update RFC3584 >I guess. Such is life. It would have been nice if this would have >come sort of automatic. I think it does, to a limited extent. And of course, there's nothing to prevent implementers from doing something we haven't specified that breaks the abstraction. One option that comes to mind is to reject SNMPv2c messsages received over ssh unless the community string is the same as the ssh username, and for such messages which are not rejected, set the securityLevel higher. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Sep 16 13:14:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWxhe-0006L1-TU; Sun, 16 Sep 2007 13:14:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWxhd-0006Ku-DY for isms@ietf.org; Sun, 16 Sep 2007 13:14:37 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWxhc-00073D-QR for isms@ietf.org; Sun, 16 Sep 2007 13:14:37 -0400 Received: from pc6 (1Cust69.tnt29.lnd3.gbr.da.uu.net [62.188.120.69]) by ranger.systems.pipex.net (Postfix) with SMTP id 3093FE0002FF; Sun, 16 Sep 2007 18:14:32 +0100 (BST) Message-ID: <00e301c7f87b$c7820000$0601a8c0@pc6> From: "tom.petch" To: References: <20070912065648.GA18470@elstar.local> <011301c7f63b$fce6dc80$6702a8c0@china.huawei.com> <008001c7f6ee$8a60d680$0601a8c0@pc6> <20070915065048.GA18718@elstar.local> Subject: Re: [Isms] Working Group Last Call tmsm-09c Date: Sun, 16 Sep 2007 17:54:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "tom.petch" Cc: "David Harrington" ; "'ISMS WG'" Sent: Saturday, September 15, 2007 8:50 AM Subject: Re: [Isms] Working Group Last Call tmsm-09c > On Fri, Sep 14, 2007 at 06:38:55PM +0200, tom.petch wrote: > > > This is for me the one unresolved issue, and one which has been discussed > > further, by others, since my initial e-mail. Taking a step back from the > > details of cache, elements of procedure and ASI, what I would like (future) > > models to be able to do is > > > > a) map the name used in setting up the session into a different one, in the TM; > > mapping can be an identity mapping > > > > b) map the original name or the different one into the securityName used for > > access control and in the sendPdu/processPdu, in the SM; mapping can be an > > identity mapping > > > > c) responses can be forced to go back over the same session as requests came in > > on > > > > d) application can select the session, pre-existing or new (using > > transportDomain, transportAddress, securityModel, securityName, securityLevel) > > (eg so a NO can use a pre-exisiting CG/CR session) > > > > e) a secure transport may offer a greater level of security than an application > > requested but the application need not be aware of this > > > > all of which I think has been agreed over the life of this group. > > > > So I work through the subsystems as amended by tmsm to see if this is possible, > > if the right parameters are passed in the right places, by cache and ASI; and I > > look for MUSTs to ensure it is, that a TM will do what it needs to to enable a > > SM to play its part to achieve this. Mostly, my suggestions have been accepted, > > albeit with an improvement in the wording, but it is around security name and > > security level that I still see difficulties. > > Please be concrete and point to the specific text which you think is > problematic and supply and explanation with suggested replacement > text. The idea of "I see difficulties around something" do not help us > to get issues worked out and resolved. > Juergen The text in question is -09 3.2.1.2, where, in point c) of my original last call comments, I said that I thought that the transport model MUST be aware of the mapping between securityName and transportspecificName. Everything else in this e-mail is the explanation of why I think that not having a MUST could come back to bite us at a future date. I still think MUST would be the best choice. Tom Petch > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Sep 16 13:14:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWxhl-0006M7-16; Sun, 16 Sep 2007 13:14:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWxhj-0006LQ-3p for isms@ietf.org; Sun, 16 Sep 2007 13:14:43 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWxhi-00073O-Eq for isms@ietf.org; Sun, 16 Sep 2007 13:14:43 -0400 Received: from pc6 (1Cust69.tnt29.lnd3.gbr.da.uu.net [62.188.120.69]) by ranger.systems.pipex.net (Postfix) with SMTP id 3F162E000240; Sun, 16 Sep 2007 18:14:35 +0100 (BST) Message-ID: <00e401c7f87b$cb3d3340$0601a8c0@pc6> From: "tom.petch" To: "Jeffrey Hutzelman" References: <00c701c7db25$8e0f78c0$0601a8c0@pc6> <20070912065648.GA18470@elstar.local> <011301c7f63b$fce6dc80$6702a8c0@china.huawei.com> <008101c7f6ee$8b768c40$0601a8c0@pc6> <1F19AA0B104D290A7B99E001@sirius.fac.cs.cmu.edu> Subject: Re: [Isms] Working Group Last Call tmsm-09 Date: Sun, 16 Sep 2007 18:04:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Jeffrey Hutzelman" To: "tom.petch" ; "David Harrington" ; Cc: "'ISMS WG'" ; "Jeffrey Hutzelman" Sent: Friday, September 14, 2007 11:56 PM Subject: Re: [Isms] Working Group Last Call tmsm-09 > > > On Friday, September 14, 2007 06:40:36 PM +0200 "tom.petch" > wrote: > > > My issue here was/is that an identifier may or may not identify the > > session in a secure manner and I want it to be in a secure manner. For > > example, the SSH session ID is a cryptographic binding of all relevant > > SSHv2 connection parameters so you can trust, cryptographically, that it > > identifies the right session. By contrast, for TLS, the session ID is > > not sufficient as it is server-assigned and so could be assigned by an > > MITM to match a server's. And I wanted this identifier to be secure so > > that when passed securely to an upper layer, then that could be used for > > channel binding, something which I believe can solve a number of security > > problems and so would not want precluded at a subsystem level (eg the > > initial SSH or TLS transport uses weak authentication which could allow a > > MITM but then a further authentication by security model or application, > > perhaps accesssing a third party, verifies that there is no MITM). > > > > If the session identifier does not identify the session in a secure > > manner, then (apart from removing the option of channel binding) I think > > that an application may be fooled into sending data over the wrong > > session. > > We're really not talking about an externally-provided identifier that is > used to find a session from among a random selection of potentially > existing sessions. We're talking about a mechanism for making sure a > response goes out over the same session the request came in on. This isn't > some complex standardized data structure with cryptographic binding; it's a > pointer. You don't need to say "the session with this exchange hash" > (which you don't know anyway, because that's below the abstraction > boundary). It's sufficient to say "the session attached to file descriptor > 12". > > If you _really_ think you want to be able to have SNMP applications do > channel binding to a secure transport, then you need to figure out a way to > pass channel bindings up through the SNMP architecture from the secure > transport to the application. Specifying what the channel bindings are > isn't up to the SNMP framework; in most cases, it isn't even really up to > the particular transport mapping, but instead will be specified for the > underlying transport. > > Personally, I don't see SNMP as a layer above which channel bindings need > to be specified. We are binding SNMP authentication into the secure > transport below (in a transport-specific fashion) precisely so that SNMP > applications don't need to worry about any such thing. > Jeff I wasn't thinking primarily of SNMP applications doing channel binding but a future Security Model, that is that TLS/SSH/etc establish a session with weak authentication and then the Security Model, with more time and resouces, can perform a stronger authentication - provided it has a something - eg in the tmStateReferenced cache - which is cryptographically bound to the session. As you say, the channel bindings are up to the transport but I wanted the Transport Model - which is transport specific - to be required to identify what would, or would not, be suitable. Tom Petch > -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Sep 17 09:25:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXGb1-0000WP-K4; Mon, 17 Sep 2007 09:25:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXGb0-0000T3-4z for isms@ietf.org; Mon, 17 Sep 2007 09:25:02 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXGaz-0006FL-4d for isms@ietf.org; Mon, 17 Sep 2007 09:25:01 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9ABF386562; Mon, 17 Sep 2007 15:24:59 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 02740-02-39; Mon, 17 Sep 2007 15:24:54 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 67F2271E0F; Mon, 17 Sep 2007 15:22:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AE79D33D945; Mon, 17 Sep 2007 15:22:44 +0200 (CEST) Date: Mon, 17 Sep 2007 15:22:44 +0200 From: Juergen Schoenwaelder To: "tom.petch" Subject: Re: [Isms] Working Group Last Call tmsm-09c Message-ID: <20070917132244.GA20347@elstar.local> Mail-Followup-To: "tom.petch" , David Harrington , 'ISMS WG' References: <20070912065648.GA18470@elstar.local> <011301c7f63b$fce6dc80$6702a8c0@china.huawei.com> <008001c7f6ee$8a60d680$0601a8c0@pc6> <20070915065048.GA18718@elstar.local> <00e301c7f87b$c7820000$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00e301c7f87b$c7820000$0601a8c0@pc6> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Sun, Sep 16, 2007 at 05:54:23PM +0200, tom.petch wrote: > Juergen > > The text in question is -09 3.2.1.2, where, in point c) of my > original last call comments, I said that I thought that the > transport model MUST be aware of the mapping between securityName > and transportspecificName. Everything else in this e-mail is the > explanation of why I think that not having a MUST could come back to > bite us at a future date. I still think MUST would be the best > choice. So your request is to make the following change: OLD: If a message is secured using a secure transport layer, then the Transport Model should provide the translation from the authenticated identity (e.g., an SSH user name) to the securityName in step 3. NEW: If a message is secured using a secure transport layer, then the Transport Model MUST provide the translation from the authenticated identity (e.g., an SSH user name) to the securityName in step 3. Actually, the translation is not directional (as some might read into this piece of text) and we perhaps should talk about principals rather than identities for consistency with the SNMPv3 terminology. That said, any arguments out there to not make this change? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Sep 17 10:03:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXHCc-00082k-1R; Mon, 17 Sep 2007 10:03:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXHCa-00082Y-V6 for isms@ietf.org; Mon, 17 Sep 2007 10:03:52 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXHCY-0004gm-Oo for isms@ietf.org; Mon, 17 Sep 2007 10:03:52 -0400 Received: from pc6 (1Cust26.tnt10.lnd4.gbr.da.uu.net [62.188.139.26]) by ranger.systems.pipex.net (Postfix) with SMTP id 3B972E00030B; Mon, 17 Sep 2007 15:03:46 +0100 (BST) Message-ID: <030a01c7f92a$4b4b09a0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , References: <00c701c7db25$8e0f78c0$0601a8c0@pc6> <20070912065648.GA18470@elstar.local> <00c501c7f610$116d16a0$6702a8c0@china.huawei.com> Subject: Re: [Isms] Working Group Last Call tmsm-09 Date: Mon, 17 Sep 2007 12:15:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -102.6 (---------------------------------------------------) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org ----- Original Message ----- From: "David Harrington" To: ; "'tom.petch'" Cc: "'ISMS WG'" Sent: Thursday, September 13, 2007 4:12 PM Subject: RE: [Isms] Working Group Last Call tmsm-09 > Hi, > > I disagree with the follwoing proposed text: > > > > I suggest the following instead > > > "The current RFC3411 architecture does not encompass > > transport (although RFC3417 > > > does define transport mappings). This document adds a > > transport subsystem, > > > based on the third approach, to the architecture, and this > > enables the use of > > > existing security mechanisms such as TLS [RFC4346] or SSH > > [RFC4251] within the > > > enhanced RFC3411 architecture. > > > > > First, I disagree with "The current RFC3411 architecture" - as > compared to what? the future RFC3411 architecture? The RFC3411 > architecture is cast in stone. It will never change. We are updating > the architecure, and when this is published (if we ever get past all > the i's and t's and get it submitted to the IESG), it will be the > RFCXXXX architecture. > > "The current RFC3411 architecture does not encompass transport" > Then what is the box labeled "Transport Mappings" in the diagram in > RFc3411 section 2? > Why does RFC3411 have a subsection entitiled "Transport Mappings"? > What is the "Transport Mappings" in the diagram in section 3.1.3.1 and > 3.1.3.2? > Why is transport mentioned in every ASI? > Of course it encompasses transport. It just doesn't use a formal > subsystem to do so. > > The abstract of TMSM explains that we are adding a transport > subsystem: "This document defines a Transport Subsystem, extending the > Simple Network Management Protocol (SNMP) architecture defined in RFC > 3411. This document defines a subsystem to contain Transport Models, > comparable to other subsystems in the RFC3411 architecture. As work is > being done to expand the transport to include secure transport such as > SSH and TLS, using a subsystem will enable consistent design and > modularity of such Transport Models. This document identifies and > describes some key aspects that need to be considered for any > Transport Model for SNMP." > > I do not quite agree that "this > > enables the use of existing security mechanisms such as TLS > [RFC4346] or SSH > > [RFC4251]...." > > We could have simply used transport mappings for SSH and TLS. We did > not need a subsystem to enable this. We chose to add a subsystem (and > models) to make the transport terminology consistent with other > portions of the architecure, and to enable consistent design and > modularity of transport models. > > Transport mappings and transport models are effectively the same > thing; newer "models" might pass transport-specific security > parameters to other subsystems in the architecture. See the text in > section 2.1: > "The transport mappings defined in RFC3417 do not provide lower-layer > security functionality, and thus do not provide transport-specific > security parameters. This document updates RFC3411 and RFC3417 by > defining an architectural extension and ASIs that transport mappings > (models) can use to pass transport-specific security parameters to > other subsystems, including transport-specific security parameters > translated into the transport-independent securityName and > securityLevel." > > I think thatis pretty clear and unambiguous, myself. > David, My wording could be improved but I still believe that the existing text in s.2 of tmsm should be clearer, thinking of those who have not lived through isms. Preamble over, this is the point in the I-D when you say why the document exists, and for someone who knows that SNMP over SSH has been specified, looks for an RFC, finds three (none of which do so), I think it important that these paragraphs be really simple and clear lest the reader gets lost. I think too that you are being over simplistic to say model and mapping are the same - given RFC3411's great stress on the nature of a model - and that some reference to that change is needed. The text I am looking at is " This document defines a Transport Subsystem extension to the RFC3411 architecture based on the third approach. 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. This extension allows security to be provided by an external protocol connected to the SNMP engine through an SNMP Transport Model [RFC3417]. Such a Transport Model would then enable the use of existing security mechanisms such as (TLS) [RFC4346] or SSH [RFC4251] within the RFC3411 architecture." which I suggest replacing by "The RFC3411 architecture includes transport mappings [RFC 3417] but not a Transport Subsystem or Transport Models. This document, using the third approach, extends the architecture to include a Transport Subsystem which can then contain Transport Models and, by doing so, enables the consistent design and modularity of such Transport Models. A Transport Model in turn enables the use of existing security mechanisms such as TLS [RFC4346] or SSH [RFC4251] within the architecture. A companion document [I-D.draft-ietf-isms-secshell-08] defines a transport model which is based on SSH while [I-D.ietf-isms-transport-security-model] defines a security model which uses this approach" I note you do not comment on my second paragraph - I trust that that indicates assent. As you may gather, I see these paragraphs as key to the understanding of what isms has done, ie much more than dotting t's and crossing i's. Tom Petch > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Sep 17 10:03:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXHCf-00085d-95; Mon, 17 Sep 2007 10:03:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXHCc-00082j-0H for isms@ietf.org; Mon, 17 Sep 2007 10:03:54 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXHCb-0007DE-CZ for isms@ietf.org; Mon, 17 Sep 2007 10:03:53 -0400 Received: from pc6 (1Cust26.tnt10.lnd4.gbr.da.uu.net [62.188.139.26]) by ranger.systems.pipex.net (Postfix) with SMTP id B3437E00094C; Mon, 17 Sep 2007 15:03:51 +0100 (BST) Message-ID: <030c01c7f92a$4d5afde0$0601a8c0@pc6> From: "tom.petch" To: , "David Harrington" References: <015401c7e57d$7fed4f80$6702a8c0@china.huawei.com> <20070914141918.GE23435@elstar.local> Subject: Re: [Isms] More questions on Security name Date: Mon, 17 Sep 2007 12:44:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -98.6 (---------------------------------------------------) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "David Harrington" Cc: Sent: Friday, September 14, 2007 4:19 PM Subject: Re: [Isms] More questions on Security name > On Thu, Aug 23, 2007 at 08:02:37AM -0400, David Harrington wrote: > > > As I recall, no solution was found to this issue. I think we reached > > consensus that > > 1) if a client had already established a connection, so we have a > > relevant securityname, then that connection could be reused for > > notiications. > > This, of course, requires that appropriate entries exist in the > snmpTargetTable and friends that point to this notification > destination. In other words, this assumes a subscription mechanism > where you establish the SSH transport and then create entries that > direct notifications to the SSH session. > > The only issue left with this approach (as I recall) is how to garbage > collect those dynamic entries in the snmpTargetTable and friends, > which likely needs a sparse augmentation of the snmpTargetTable. > > > 2) if a notification needs to be sent, and no SSH connection exists, > > then the transport model will try to create a connection. How the > > credentials are supplied, and how the connectionis created is > > implementation-specific. The slides from IETF67 present three > > options for doing this, which may or may not work. > > The straight forward approach is to have an SSH user name plus > whatever credentials needed for authentication on the "device" and to > use the authenticated host identity as the security name (and thus as > input for the access control decision). > > We investigated turning SSH roles around and finally concluded that > this is not going to work due to security issues; at least not without > a surgery of SSH (which is not our business). > Agreed, but I believe that this is an architecture/subsystem discussion and the fact that SSH cannot do it should not rule it out of the subsystem; a future transport may have just what we need. In a sense, this is an SSH problem because SSHTM says that the securityName is the SSH user name (if the SSH host name were the securityName for notifications, I do not see a problem - well, not this one:-). Tom Petch > > 3) if a notification needs to be sent, and no SSH connection exists, > > then the agent can use USM to send the notification. This is > > implementation-specific. > > Implementation-specific magic to fallback to USM does not seem to be a > solution to pursue on a standards-track. > > So I think we essentially have 2) and an incomplete 1). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Sep 17 10:03:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXHCc-00082v-4s; Mon, 17 Sep 2007 10:03:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXHCb-00082d-48 for isms@ietf.org; Mon, 17 Sep 2007 10:03:53 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXHCa-0007D9-H4 for isms@ietf.org; Mon, 17 Sep 2007 10:03:53 -0400 Received: from pc6 (1Cust26.tnt10.lnd4.gbr.da.uu.net [62.188.139.26]) by ranger.systems.pipex.net (Postfix) with SMTP id 47FEFE000937; Mon, 17 Sep 2007 15:03:50 +0100 (BST) Message-ID: <030b01c7f92a$4c7001a0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , "'ISMS WG'" References: <037c01c7db3c$9725b520$0601a8c0@pc6><016a01c7db4d$bd2fa710$6702a8c0@china.huawei.com><01af01c7dd84$15202c00$0601a8c0@pc6><000901c7ddd0$79189a20$6702a8c0@china.huawei.com><021701c7de7e$7ebcdaa0$0601a8c0@pc6><59165B4D35F9378674A70368@sirius.fac.cs.cmu.edu><00e501c7e63c$92ed4d00$0601a8c0@pc6> <020201c7e653$37290e20$6702a8c0@china.huawei.com> <012201c7f659$92495470$6702a8c0@china.huawei.com> Subject: Re: [Isms] Working Group Last Call - securityName Date: Mon, 17 Sep 2007 12:17:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -98.6 (---------------------------------------------------) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org ----- Original Message ----- From: "David Harrington" To: "'David Harrington'" ; "'tom.petch'" ; "'Jeffrey Hutzelman'" ; "'ISMS WG'" Sent: Friday, September 14, 2007 12:58 AM Subject: RE: [Isms] Working Group Last Call - securityName > Hi, > > I have wordsmithed multiple places to help clarify this. > > As I recall, the WG decided initailly to define the contents of > tmStateReference (around the time of the interim meeting), but later > decided not to define the specifics of the tmStateReference because > this is transport-specific. > > One way I can clarify the multiple securityname ambiguity is to define > tmStateReference fields called tmSecurityName and tmSecurityLevel and > then the Security Model can work with those fields. Does the WG want > to go this way? > Works for me, especially as I see this in isms-secshell Tom Petch > dbh > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Friday, August 24, 2007 9:32 AM > > To: 'tom.petch'; 'Jeffrey Hutzelman'; 'ISMS WG' > > Subject: RE: [Isms] Working Group Last Call - securityName > > > > inline > > > > > > > > > > > tmsm 3.2.1.2. Transport Subsystem and the RFC3411 > Architecture > > > > > > > > > > seems clear enough > > > > > > > > > > 1) authenticate the principal, check integrity and > > > timeliness of the > > > > > message, and decrypt the message. [Transport Model] > > > > > 2) translate parameters to model-independent > > > parameters (Transport > > > > > Model) > > > > > > > [...] > > > You are quite right; the words are clear and exact; it was my > > > understanding that > > > got vaguer at this point because those words seem to > > > contradict what is said in > > > 3.2.1.2. I read, and read, 3.2.1.2 as saying that the Transport > > Model > > > translates between a transport level identifier and the (one and > > only) > > > securityName. I now understand that the securityModel can > > > use a different > > > value for securityName, based on the information it has. For > > > me, 3.2.1.2 does > > > not say that so I think the wording in 3.2.1.2 should be > > > changed to be clearer. > > > > 3.2.1.1 says: > > (Note that these lists are simplified for illustrative purposes, > > and > > do not represent all details of processing. Transport Models > must > > provide the detailed elements of procedure.) > > > > But, I will wordsmsith this to try to make it less ambiguous. > > > > David Harrington > > 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 Mon Sep 17 10:04:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXHCm-00088S-38; Mon, 17 Sep 2007 10:04:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXHCj-00088I-Hj for isms@ietf.org; Mon, 17 Sep 2007 10:04:01 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXHCj-0007DT-4E for isms@ietf.org; Mon, 17 Sep 2007 10:04:01 -0400 Received: from pc6 (1Cust26.tnt10.lnd4.gbr.da.uu.net [62.188.139.26]) by ranger.systems.pipex.net (Postfix) with SMTP id 63023E00090F; Mon, 17 Sep 2007 15:03:53 +0100 (BST) Message-ID: <030d01c7f92a$4e5e6420$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , References: <20070912065648.GA18470@elstar.local> <011301c7f63b$fce6dc80$6702a8c0@china.huawei.com> <008001c7f6ee$8a60d680$0601a8c0@pc6> <20070915065048.GA18718@elstar.local> <01f101c7f797$b4088c90$6702a8c0@china.huawei.com> Subject: Re: [Isms] Working Group Last Call tmsm-09c Date: Mon, 17 Sep 2007 14:42:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org ----- Original Message ----- From: "David Harrington" To: ; "'tom.petch'" Cc: "'ISMS WG'" Sent: Saturday, September 15, 2007 2:55 PM Subject: RE: [Isms] Working Group Last Call tmsm-09c > Does the new text I added to the security considerations address this > adeqautely? > > dbh I am not clear that it does. The text is good and certainly should be included but I think that 3.2.1 - which is where my concerns are - will need revising to match. I was and am concerned about the last sentence of 3.2.1.2 wanting the 'should' to be a 'MUST' although as Jeff pointed out, there are two cases here, of STM with TSM (when I think MUST is needed) and STM with USM (where I would still like a MUST even if, as has been now discussed, the actions of TSM will be ignored because USM ignores tmStateReference) Re-read 3.2.1 considering each of STM with TSM, STM with USM, UDP (as an instance of insecure TM) with TSM, UDP with USM; I think that at least the titles of 3.2.1.1.1 and 3.2.1.2 need amending Tom Petch > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Saturday, September 15, 2007 2:51 AM > > To: tom.petch > > Cc: David Harrington; 'ISMS WG' _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Sep 17 10:18:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXHQi-0005bl-Hy; Mon, 17 Sep 2007 10:18:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXHQg-0005be-So for isms@ietf.org; Mon, 17 Sep 2007 10:18:26 -0400 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXHQg-0007fj-D4 for isms@ietf.org; Mon, 17 Sep 2007 10:18:26 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc12) with SMTP id <20070917141824m1200fcfvke>; Mon, 17 Sep 2007 14:18:25 +0000 From: "David Harrington" To: , "'tom.petch'" References: <20070912065648.GA18470@elstar.local> <011301c7f63b$fce6dc80$6702a8c0@china.huawei.com> <008001c7f6ee$8a60d680$0601a8c0@pc6> <20070915065048.GA18718@elstar.local> <00e301c7f87b$c7820000$0601a8c0@pc6> <20070917132244.GA20347@elstar.local> Subject: RE: [Isms] Working Group Last Call tmsm-09c Date: Mon, 17 Sep 2007 10:18:06 -0400 Message-ID: <026d01c7f935$91d77d30$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf5LiZQP9H1lEOqQRuQp3naJvBowAABlnXg In-Reply-To: <20070917132244.GA20347@elstar.local> X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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, The wording in rev10 reads, If a message is secured using a secure transport layer, then the Transport Model should provide the translation from the authenticated identity (e.g., an SSH user name) to a model-independent securityName in step 2. We are having difficulties designing an ISMS solution because, based on the needs of the security model then under design (USM), a bunch of MUSTs were specified by the SNMPv3 WG. It turns out that, when trying to leverage other technologies, those MUSTs are inappropriate. I think it is better to say should, to permit those protocol designers who wish to add to this architecture in the future to make the appropriate decisions, based on their better understanding of future needs, rather than tying their hands with MUSTs based on our imperfect knowledge of the future or based on the solution currently under design. I prefer the wording of rev10. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, September 17, 2007 9:23 AM > To: tom.petch > Cc: David Harrington; 'ISMS WG' > Subject: Re: [Isms] Working Group Last Call tmsm-09c > > On Sun, Sep 16, 2007 at 05:54:23PM +0200, tom.petch wrote: > > > Juergen > > > > The text in question is -09 3.2.1.2, where, in point c) of my > > original last call comments, I said that I thought that the > > transport model MUST be aware of the mapping between securityName > > and transportspecificName. Everything else in this e-mail is the > > explanation of why I think that not having a MUST could come back to > > bite us at a future date. I still think MUST would be the best > > choice. > > So your request is to make the following change: > > OLD: > > If a message is secured using a secure transport layer, then the > Transport Model should provide the translation from the > authenticated > identity (e.g., an SSH user name) to the securityName in step 3. > > NEW: > > If a message is secured using a secure transport layer, then the > Transport Model MUST provide the translation from the authenticated > identity (e.g., an SSH user name) to the securityName in step 3. > > Actually, the translation is not directional (as some might read into > this piece of text) and we perhaps should talk about principals rather > than identities for consistency with the SNMPv3 terminology. > > That said, any arguments out there to not make this change? > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Sep 17 10:38:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXHk9-0002aQ-NL; Mon, 17 Sep 2007 10:38:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXHk8-0002aK-T2 for isms@ietf.org; Mon, 17 Sep 2007 10:38:32 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXHk8-00085A-G3 for isms@ietf.org; Mon, 17 Sep 2007 10:38:32 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id F093639E69; Mon, 17 Sep 2007 16:38:31 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 11818-03-19; Mon, 17 Sep 2007 16:38:26 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B48B865F4; Mon, 17 Sep 2007 16:36:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8F47C33DC2C; Mon, 17 Sep 2007 16:36:21 +0200 (CEST) Date: Mon, 17 Sep 2007 16:36:21 +0200 From: Juergen Schoenwaelder To: "tom.petch" Subject: Re: [Isms] Working Group Last Call - transport-security-model Message-ID: <20070917143621.GA20459@elstar.local> Mail-Followup-To: "tom.petch" , Juergen Quittek , ISMS WG References: <037e01c7db3c$994f9a00$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <037e01c7db3c$994f9a00$0601a8c0@pc6> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ISMS WG , Juergen Quittek X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Fri, Aug 10, 2007 at 12:49:10PM +0200, tom.petch wrote: > a) 2.2 says > 'the Transport Security Model will make no assumptions > about there being a session of any kind' > yet later it is required to passs a tmSameSession parameter. Lest this seem > contradictory, I would add a comment to 2.2 such as > "but the Model will pass a tmSameSession parameter when appropriate for the use > by session-based transports" > > b) 2.3 suggest adding a note to the RFC-Editor to replace YY; not strictly > necessary but keeps it simple; it is the only reference in the body of the > document to YY > > c) 4.3 Where it says > 'and tmStateReference from the cache' > I suggest "from the cachedSecurity Data" I misread this as the > tmStateReferenced cache which makes it a nonsense. All three look editorial to me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Sep 17 10:51:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXHwm-0006kU-Qt; Mon, 17 Sep 2007 10:51:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXHwl-0006kP-Lq for isms@ietf.org; Mon, 17 Sep 2007 10:51:35 -0400 Received: from rwcrmhc14.comcast.net ([216.148.227.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXHwj-0005ki-LD for isms@ietf.org; Mon, 17 Sep 2007 10:51:35 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc14) with SMTP id <20070917145131m1400jenkoe>; Mon, 17 Sep 2007 14:51:32 +0000 From: "David Harrington" To: "'ISMS WG'" Date: Mon, 17 Sep 2007 10:51:15 -0400 Message-ID: <026f01c7f93a$32be9a40$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0270_01C7F918.ABACFA40" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf5OjH2rbhwL/6YTrOmtePRUbHfvQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2fdd3070842b494e9d050b5e03577a84 Cc: Subject: [Isms] tmsm rev 10 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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 This is a multi-part message in MIME format. ------=_NextPart_000_0270_01C7F918.ABACFA40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Rather than continuing to debate rev 09 text, while we wait for the new rev to become publicly available, please use this copy to see if your concerns are addressed. As I stated in earlier email, I expect to have updates for TSM and SSHTM later this week. In the meantime, you should expect there will be consistency problems between older revs of TSM and SSHTM and the new rev of TMSM, and wait to see if those are addressed when the complete new set of available. David Harrington dbharrington@comcast.net ietfdbh@comcast.net ------=_NextPart_000_0270_01C7F918.ABACFA40 Content-Type: text/plain; name="draft-ietf-isms-tmsm-10.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-isms-tmsm-10.txt" Network Working Group D. Harrington Internet-Draft Huawei Technologies (USA) Updates: 3411,3412,3414,3417 J. Schoenwaelder (if approved) Jacobs University Bremen Intended status: Standards Track September 15, 2007 Expires: March 18, 2008 Transport Subsystem for the Simple Network Management Protocol (SNMP) draft-ietf-isms-tmsm-10 Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models, comparable to other subsystems in the RFC3411 architecture. As work is being done to expand the transport to include secure transport such as SSH and TLS, using a subsystem will enable consistent design Harrington & Schoenwaelder Expires March 18, 2008 [Page 1] =0C Internet-Draft SNMP Transport Subsystem September 2007 and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Internet-Standard Management Framework . . . . . . . . 3 1.2. Where this Extension Fits . . . . . . . . . . . . . . . . 3 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements of a Transport Model . . . . . . . . . . . . . . 7 3.1. Message Security Requirements . . . . . . . . . . . . . . 7 3.1.1. Security Protocol Requirements . . . . . . . . . . . . 7 3.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Architectural Modularity Requirements . . . . . . . . 8 3.2.2. Access Control Requirements . . . . . . . . . . . . . 12 3.2.3. Security Parameter Passing Requirements . . . . . . . 13 3.2.4. Separation of Authentication and Authorization . . . . 14 3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 15 3.3.1. Session Establishment Requirements . . . . . . . . . . 15 3.3.2. Session Maintenance Requirements . . . . . . . . . . . 16 3.3.3. Message security versus session security . . . . . . . 17 4. Scenario Diagrams and the Transport Subsystem . . . . . . . . 18 5. Cached Information and References . . . . . . . . . . . . . . 18 5.1. securityStateReference . . . . . . . . . . . . . . . . . . 19 5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 19 6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 20 6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 20 6.2. Other Outgoing ASIs . . . . . . . . . . . . . . . . . . . 21 6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 23 6.4. Other Incoming ASIs . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7.1. Coexistence, Security Parameters, and Access Control . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 Appendix A. Why tmStateReference? . . . . . . . . . . . . . . . . 29 A.1. Define an Abstract Service Interface . . . . . . . . . . . 29 A.2. Using an Encapsulating Header . . . . . . . . . . . . . . 29 A.3. Modifying Existing Fields in an SNMP Message . . . . . . . 30 A.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 30 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 30 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 31 Harrington & Schoenwaelder Expires March 18, 2008 [Page 2] =0C Internet-Draft SNMP Transport Subsystem September 2007 1. Introduction This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in [RFC3411]. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. 1.1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. 1.2. Where this Extension Fits It is expected that readers of this document will have read RFC3410 and RFC3411, and have a general understanding of the functionality defined in RFCs 3412-3418. The "Transport Subsystem" is an additional component for the SNMP Engine depicted in RFC3411, section 3.1. Harrington & Schoenwaelder Expires March 18, 2008 [Page 3] =0C Internet-Draft SNMP Transport Subsystem September 2007 The following diagram depicts its place in the RFC3411 architecture.: +-------------------------------------------------------------------+ | SNMP entity | | | | +-------------------------------------------------------------+ | | | SNMP engine (identified by snmpEngineID) | | | | | | | | +------------+ | | | | | Transport | | | | | | Subsystem | | | | | +------------+ | | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | Dispatcher | | Message | | Security | | Access | | | | | | | | Processing | | Subsystem | | Control | | | | | | | | Subsystem | | | | Subsystem | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | +-------------------------------------------------------------+ | | | | +-------------------------------------------------------------+ | | | Application(s) | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Proxy | | | | | | Generator | | Receiver | | Forwarder | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Other | | | | | | Responder | | Originator | | | | | | | +-------------+ +--------------+ +--------------+ | | | +-------------------------------------------------------------+ | | | +-------------------------------------------------------------------+ The transport mappings defined in RFC3417 do not provide lower-layer security functionality, and thus do not provide transport-specific security parameters. This document updates RFC3411 and RFC3417 by defining an architectural extension and ASIs that transport mappings (models) can use to pass transport-specific security parameters to other subsystems, including transport-specific security parameters translated into transport-independent securityName and securityLevel parameters The Secure Shell Transport Model [I-D.ietf-isms-secshell] and the Transport Security Model [I-D.ietf-isms-transport-security-model] Harrington & Schoenwaelder Expires March 18, 2008 [Page 4] =0C Internet-Draft SNMP Transport Subsystem September 2007 utilize the Transport Subsystem. 1.3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Non uppercased versions of the keywords should be read as in normal English. They will usually, but not always, be used in a context relating to compatibility with the RFC3411 architecture or the subsystem defined here, but which might have no impact on on-the-wire compatibility. These terms are used as guidance for designers of proposed IETF models to make the designs compatible with RFC3411 subsystems and Abstract Service Interfaces (see section 3.2). Implementers are free to implement differently. Some usages of these lowercase terms are simply normal English usage. For consistency with SNMP-related specifications, this document favors terminology as defined in STD62 rather than favoring terminology that is consistent with non-SNMP specifications that use different variations of the same terminology. This is consistent with the IESG decision to not require the SNMPv3 terminology be modified to match the usage of other non-SNMP specifications when SNMPv3 was advanced to Full Standard. 2. Motivation Just as there are multiple ways to secure one's home or business, in a continuum of alternatives, there are multiple ways to secure a network management protocol. Let's consider three general approaches. In the first approach, an individual could sit on his front porch waiting for intruders. In the second approach, he could hire an employee , schedule the employee, position the employee to guard what he wants protected, hire a second guard to cover if the first gets sick, and so on. In the third approach, he could hire a security company, tell them what he wants protected, and they could hire employees, train them, position the guards, schedule the guards, send a replacement when a guard cannot make it, etc., thus providing the desired security, with no significant effort on his part other than identifying requirements and verifying the quality of the service being provided. The User-based Security Model (USM) as defined in [RFC3414] largely uses the first approach - it provides its own security. It utilizes existing mechanisms (e.g., SHA), but provides all the coordination. Harrington & Schoenwaelder Expires March 18, 2008 [Page 5] =0C Internet-Draft SNMP Transport Subsystem September 2007 USM provides for the authentication of a principal, message encryption, data integrity checking, timeliness checking, etc. USM was designed to be independent of other existing security infrastructures. USM therefore requires a separate principal and key management infrastructure. Operators have reported that deploying another principal and key management infrastructure in order to use SNMPv3 is a deterrent to deploying SNMPv3. It is possible to use external mechanisms to handle the distribution of keys for use by USM. The more important issue is that operators wanted to leverage a single user base that wasn't specific to SNMP. A solution based on the second approach might use a USM-compliant architecture, but combine the authentication mechanism with an external mechanism, such as RADIUS [RFC2865], to provide the authentication service. It might be possible to utilize an external protocol to encrypt a message, to check timeliness, to check data integrity, etc. It is difficult to cobble together a number of subcontracted services and coordinate them however, because it is difficult to build solid security bindings between the various services, and potential for gaps in the security is significant. A solution based on the third approach might utilize one or more lower-layer security mechanisms to provide the message-oriented security services required. These would include authentication of the sender, encryption, timeliness checking, and data integrity checking. There are a number of IETF standards available or in development to address these problems through security layers at the transport layer or application layer, among them TLS [RFC4346], SASL [RFC4422], and SSH [RFC4251]. 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 [RFC4741]. This document defines a Transport Subsystem extension to the RFC3411 architecture based on the third approach. 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. This extension allows security to be provided by an external protocol connected to the SNMP engine through an SNMP Transport Model [RFC3417]. Such a Transport Model would then enable the use of existing security mechanisms such as (TLS) [RFC4346] or SSH [RFC4251] Harrington & Schoenwaelder Expires March 18, 2008 [Page 6] =0C Internet-Draft SNMP Transport Subsystem September 2007 within the RFC3411 architecture. There are a number of Internet security protocols and mechanisms that are in wide spread use. Many of them try to provide a generic infrastructure to be used by many different application layer protocols. The motivation behind the Transport Subsystem is to leverage these protocols where it seems useful. There are a number of challenges to be addressed to map the security provided by a secure transport into the SNMP architecture so that SNMP continues to provide interoperability with existing implementations. These challenges are described in detail in this document. For some key issues, design choices are described that might be made to provide a workable solution that meets operational requirements and fits into the SNMP architecture defined in [RFC3411]. 3. Requirements of a Transport Model 3.1. Message Security Requirements Transport security protocols SHOULD provide protection against the following message-oriented threats [RFC3411]: 1. modification of information 2. masquerade 3. message stream modification 4. disclosure These threats are described in section 1.4 of [RFC3411]. It is not required to protect against denial of service or traffic analysis, but it should not make those threats significantly worse. 3.1.1. Security Protocol Requirements There are a number of standard protocols that could be proposed as possible solutions within the Transport Subsystem. Some factors SHOULD be considered when selecting a protocol. Using a protocol in a manner for which it was not designed has numerous problems. The advertised security characteristics of a protocol might depend on it being used as designed; when used in other ways, it might not deliver the expected security characteristics. It is recommended that any proposed model include a description of the applicability of the Transport Model. A Transport Model SHOULD require no modifications to the underlying protocol. Modifying the protocol might change its security Harrington & Schoenwaelder Expires March 18, 2008 [Page 7] =0C Internet-Draft SNMP Transport Subsystem September 2007 characteristics in ways that would impact other existing usages. If a change is necessary, the change SHOULD be an extension that has no impact on the existing usages. Any Transport Model SHOULD include a description of potential impact on other usages of the protocol. Transport Models MUST be able to coexist with each other. 3.2. SNMP Requirements 3.2.1. Architectural Modularity Requirements SNMP version 3 (SNMPv3) is based on a modular architecture (defined in [RFC3411] section 3) to allow the evolution of the SNMP protocol standards over time, and to minimize side effects between subsystems when changes are made. The RFC3411 architecture includes a Security Subsystem for enabling different methods of providing security services, a Message Processing Subsystem permitting different message versions to be handled by a single engine, Applications(s) to support different types of application processors, and an Access Control Subsystem for allowing multiple approaches to access control. The RFC3411 architecture does not include a subsystem for Transport Models, despite the fact there are multiple transport mappings already defined for SNMP. This document addresses the need for a Transport Subsystem compatible with 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. The design of this Transport Subsystem accepts the goals of the RFC3411 architecture defined in section 1.5 of [RFC3411]. This Transport Subsystem uses a modular design that will permit Transport Models to be advanced through the standards process independently of other Transport Models, and independent of other modular SNMP components as much as possible. Parameters have been added to the ASIs to pass model-independent transport address information. IETF standards typically require one mandatory to implement solution, with the capability of adding new mechanisms in the future. Part of the motivation 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, such as certificates, to ensure a basic level of interoperability, but should also be able to support additional existing and new mechanisms. Harrington & Schoenwaelder Expires March 18, 2008 [Page 8] =0C Internet-Draft SNMP Transport Subsystem September 2007 The Transport Subsystem permits multiple transport protocols to be "plugged into" the RFC3411 architecture, supported by corresponding Transport Models, including models that are security-aware. The RFC3411 architecture and the Security Subsystem assume that a Security Model is called by a Message Processing Model and will perform multiple security functions within the Security Subsystem. A Transport Model that supports a secure transport protocol might perform similar security functions within the Transport Subsystem. A Transport Model might perform the translation of transport security parameters to/from security-model-independent parameters. To accommodate this, an implementation-specific cache of transport- specific information will be described (not shown), and the data flows between the Transport Subsystem and the Transport Dispatch, between the Message Dispatch and the Message Processing Subsystem, and between the Message Processing Subsystem and the Security Subsystem will be extended to pass security-model-independent values. New Security Models may also be defined that understand how to work with the modified ASIs and the cache. One such Security Model, the Transport Security Model, is defined in [I-D.ietf-isms-transport-security-model] The following diagram depicts the SNMPv3 architecture including the new Transport Subsystem defined in this document, and a new Transport Security Model defined in [I-D.ietf-isms-transport-security-model]. Harrington & Schoenwaelder Expires March 18, 2008 [Page 9] =0C Internet-Draft SNMP Transport Subsystem September 2007 +------------------------------+ | Network | +------------------------------+ ^ ^ ^ | | | v v v +-------------------------------------------------------------------+ | +--------------------------------------------------+ | | | Transport Subsystem | | | | +-----+ +-----+ +-----+ +-----+ +-------+ | | | | | UDP | | TCP | | SSH | | TLS | . . . | other | | | | | +-----+ +-----+ +-----+ +-----+ +-------+ | | | +--------------------------------------------------+ | | ^ | | | | | Dispatcher v | | +-------------------+ +---------------------+ +----------------+ | | | Transport | | Message Processing | | Security | | | | Dispatch | | Subsystem | | Subsystem | | | | | | +------------+ | | +------------+ | | | | | | +->| v1MP |<--->| | USM | | | | | | | | +------------+ | | +------------+ | | | | | | | +------------+ | | +------------+ | | | | | | +->| v2cMP |<--->| | Transport | | | | | Message | | | +------------+ | | | Security | | | | | Dispatch <--------->| +------------+ | | | Model | | | | | | | +->| v3MP |<--->| +------------+ | | | | | | | +------------+ | | +------------+ | | | | PDU Dispatch | | | +------------+ | | | Other | | | | +-------------------+ | +->| otherMP |<--->| | Model(s) | | | | ^ | +------------+ | | +------------+ | | | | +---------------------+ +----------------+ | | v | | +-------+-------------------------+---------------+ | | ^ ^ ^ | | | | | | | v v v | | +-------------+ +---------+ +--------------+ +-------------+ | | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | | | application | | | | applications | | application | | | +-------------+ +---------+ +--------------+ +-------------+ | | ^ ^ | | | | | | v v | | +----------------------------------------------+ | | | MIB instrumentation | SNMP entity | +-------------------------------------------------------------------+ Harrington & Schoenwaelder Expires March 18, 2008 [Page 10] =0C Internet-Draft SNMP Transport Subsystem September 2007 3.2.1.1. Processing Differences between USM and Secure Transport USM and secure transports differ in the processing order and responsibilities within the RFC3411 architecture. While the steps are the same, they occur in a different order, and may be done by different subsystems. The following lists illustrate the difference in the flow and the responsibility for different processing steps for incoming messages when using USM and when using a secure transport. (Note that these lists are simplified for illustrative purposes, and do not represent all details of processing. Transport Models must provide the detailed elements of procedure.) With USM and other Security Models, security processing starts when the Message Processing Model decodes portions of the ASN.1 message to extract an opaque block of security parameters and header parameters that identify which Security Model should process the message to perform authentication, decryption, timeliness checking, integrity checking, and translation of parameters to model-independent parameters. A secure transport performs those security functions on the message, before the ASN.1 is decoded. Step 6 cannot occur until after decryption occurs. Step 6 and beyond are the same for USM and a secure transport. 3.2.1.1.1. USM and the RFC3411 Architecture 1) decode the ASN.1 header (Message Processing Model) 2) determine the SNMP Security Model and parameters (Message Processing Model) 3) verify securityLevel. [Security Model] 4) translate parameters to model-independent parameters (Security Model) 5) authenticate the principal, check message integrity and timeliness, and decrypt the message. [Security Model] 6) determine the pduType in the decrypted portions (Message Processing Model), and 7) pass on the decrypted portions with model-independent parameters. 3.2.1.2. Transport Subsystem and the RFC3411 Architecture 1) authenticate the principal, check integrity and timeliness of the message, and decrypt the message. [Transport Model] 2) translate parameters to model-independent parameters (Transport Model) Harrington & Schoenwaelder Expires March 18, 2008 [Page 11] =0C Internet-Draft SNMP Transport Subsystem September 2007 3) decode the ASN.1 header (Message Processing Model) 4) determine the SNMP Security Model and parameters (Message Processing Model) 5) verify securityLevel [Security Model] 6) determine the pduType in the decrypted portions (Message Processing Model), and 7) pass on the decrypted portions with model-independent security parameters If a message is secured using a secure transport layer, then the Transport Model should provide the translation from the authenticated identity (e.g., an SSH user name) to a model-independent securityName in step 2. 3.2.1.3. Passing Information between Engines A secure Transport Model will establish an authenticated and/or encrypted tunnel between the Transport Models of two SNMP engines. 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. Transport Models MAY support sending multiple SNMP messages through the same tunnel. 3.2.2. Access Control Requirements RFC3411 made some design decisions related to the support of an Access Control Subsystem. These include establishing and passing in a model-independent manner the securityModel, securityName and securityLevel parameters, and separating message authentication from data access authorization. 3.2.2.1. securityName and securityLevel Mapping SNMP data access controls are expected to work on the basis of who can perform what operations on which subsets of data, and based on the security services that will be provided to secure the data in transit. The securityModel and securityLevel parameters establish the protections for transit - whether authentication and privacy services will be or have been applied to the message. The securityName is a model-independent identifier of the security "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 security-model-specific principal for an incoming message to a security-model independent securityName which can be used for subsequent processing, such as for access control. The securityName is mapped from a mechanism-specific Harrington & Schoenwaelder Expires March 18, 2008 [Page 12] =0C Internet-Draft SNMP Transport Subsystem September 2007 identity, and this mapping must be done for incoming messages by the Security Model before it passes securityName to the Message Processing Model via the processIncoming ASI. A Security Model is also responsible to specify, via the securityLevel parameter, whether incoming messages have been authenticated and/or encrypted, and to ensure that outgoing messages are authenticated and/or encrypted based on the value of securityLevel. A translation from a mechanism-specific identity to a securityName might be done by a Transport Model, and the proposed securityName and a proposed securityLevel might then be made available to a Security Model via the tmStateReference. A Security Model may have multiple sources for determining the principal and desired security services, and a particular Security Model may or may not utilize the securityName mapping and securityLevel made available by the Transport Model when deciding the value of the securityName and securityLevel to be passed to the Message Processing Model. 3.2.3. Security Parameter Passing Requirements RFC3411 section 4 describes abstract data flows between the subsystems, models and applications within the architecture. Abstract Service Interfaces describe the flow of data, passing model- independent information between subsystems within an engine. The RFC3411 architecture has no ASI parameters for passing security information between the Transport Subsystem and the dispatcher, or between the dispatcher and the Message Processing Model. This document defines or modifies ASIs for this purpose. A Message Processing Model might unpack SNMP-specific security parameters from an incoming message before calling a specific Security Model to authenticate and decrypt an incoming message, perform integrity checking, and translate security-model-specific parameters into model-independent parameters. When using a secure Transport Model, some security parameters might be provided through means other than carrying them in the SNMP message; some of the parameters for incoming messages might be extracted from the transport layer by the Transport Model before the message is passed to the Message Processing Subsystem. This document describes a cache mechanism (see Section 5), into which the Transport Model puts information about the transport and security parameters applied to a transport connection or an incoming message, and a Security Model may extract that information from the cache. A tmStateReference is passed as an extra parameter in the ASIs of the Transport Subsystem and the Message Processing and Security Harrington & Schoenwaelder Expires March 18, 2008 [Page 13] =0C Internet-Draft SNMP Transport Subsystem September 2007 Subsystems, to identify the relevant cache. This approach of passing a model-independent reference is consistent with the securityStateReference cache already being passed around in the RFC3411 ASIs. For outgoing messages, even when a secure Transport Model will provide the security services, a Message Processing Model might have a Security Model actually create the message from its component parts. Whether there are any security services provided by the Security Model for an outgoing message is security-model-dependent. For incoming messages, even when a secure Transport Model provides security services, a Security Model might provide some security functionality that can only be provided after the message version or other parameters are extracted from the message. 3.2.4. Separation of Authentication and Authorization The RFC3411 architecture defines a separation of authentication and the authorization to access and/or modify MIB data. A set of model- independent parameters (securityModel, securityName, and securityLevel) are passed between the Security Subsystem, the applications, and the Access Control Subsystem. This separation was a deliberate decision of the SNMPv3 WG, to allow support for authentication protocols which did not provide data access authorization capabilities, and to support data access authorization schemes, such as VACM, that do not perform their own authentication. This decision also permits different types of data access policies, such as one built on UNIX groups or Windows domains. The VACM approach is based on administrator-defined groups of users. A Message Processing Model determines which Security Model is used, either based on the message version, e.g., SNMPv1 and SNMPv2c, and possibly by a value specified in the message, e.g., SNMPv3. The Security Model makes the decision which securityName and securityLevel values are passed as model-independent parameters to an application, which then passes them via the isAccessAllowed ASI to the Access Control Subsystem. An Access Control Model performs the mapping from the model- independent security parameters to a policy within the Access Control Model that is access-control-model-dependent. A Transport Model does not know which securityModel will be used for an incoming message, so a Transport Model cannot know how the securityName and securityLevel parameters are determined. A Transport Model can provide a mapping from a transport-specific Harrington & Schoenwaelder Expires March 18, 2008 [Page 14] =0C Internet-Draft SNMP Transport Subsystem September 2007 identity and provide candidate values for the securityName and securityLevel, but there is no guarantee the transport-provided values will be used by the Security Model. For example, the SNMPv1 Message Processing Model described in RFC3584 always selects the SNMPv1 Security Model. This is true even if the SNMPv1 message was protected in transit using a secure Transport Model, such as one based on SSH or TLS. The SNMPv1 Security Model does not know the tmStateReference exists. 3.3. Session Requirements Some secure transports might have a notion of sessions, while other secure transports might provide channels or other session-like mechanism. Throughout this document, the term session is used in a broad sense to cover sessions, channels, and session-like mechanisms. Session refers to an association between two SNMP engines that permits the transmission of one or more SNMP messages within the lifetime of the session. How the session is actually established, opened, closed, or maintained is specific to a particular Transport Model. Sessions are not part of the SNMP architecture defined in [RFC3411], but are considered desirable because the cost of authentication can be amortized over potentially many transactions. The architecture defined 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 has no mechanism to select a session using the ASIs except by passing a unique combination of transportDomain, transportAddress, securityName, and securityLevel. Implementers, of course, might provide non-standard mechanisms to select sessions. The transportDomain and transportAddress identify the transport connection to a remote network node; the securityName identifies which security principal to communicate with at that address (e.g., different NMS applications), and the securityLevel might permit selection of different sets of security properties for different purposes (e.g., encrypted SETs vs. non-encrypted GETs). To reduce redundancy, this document describes aspects that are expected to be common to all Transport Model sessions. 3.3.1. Session Establishment Requirements SNMP has no mechanism to specify a transport session using the ASIs except by passing a unique combination transportDomain, transportAddress, securityName, and securityLevel to be used to Harrington & Schoenwaelder Expires March 18, 2008 [Page 15] =0C Internet-Draft SNMP Transport Subsystem September 2007 identify a session in a transport-independent manner. SNMP applications provide the transportDomain, transportAddress, securityName, and securityLevel to be used to create a session. For an outgoing message, securityLevel is the requested security for the message, passed in the ASIs. If the Transport Model cannot provide at least the requested level of security, the Transport Model SHOULD discard the message and notify the dispatcher that establishing a session and sending the message failed. A Transport Model determines whether an appropriate session exists (transportDomain, transportAddress, securityName, and securityLevel) for an outgoing message. If an appropriate session does not yet exist, the Transport Model attempts to establish a session for delivery . If a session cannot be established then the message is discarded and the dispatcher should be notified that sending the message failed. Transport session establishment might require provisioning authentication credentials at an engine, either statically or dynamically. How this is done is dependent on the transport model and the implementation. The Transport Subsystem has no knowledge of pduType, so cannot distinguish between a session created to carry different pduTypes. To differentiate a session established for different purposes, such as a notification session versus a request-response session, an application can use different securityNames or transport addresses. For example, in SNMPv1, UDP ports 161 and 162 were used to differentiate types of traffic. New transport models may define a single well-known port for all traffic types. Administrators might choose to define one port for SNMP request-response traffic, but configure notifications to be sent to a different port. 3.3.2. Session Maintenance Requirements A Transport Model can tear down sessions as needed. It might be necessary for some implementations to tear down sessions as the result of resource constraints, for example. The decision to tear down a session is implementation-dependent. While it is possible for an implementation to automatically tear down each session once an operation has completed, this is not recommended for anticipated performance reasons. How an implementation determines that an operation has completed, including all potential error paths, is implementation-dependent. The elements of procedure describe when cached information can be Harrington & Schoenwaelder Expires March 18, 2008 [Page 16] =0C Internet-Draft SNMP Transport Subsystem September 2007 discarded, in some circumstances, and the timing of cache cleanup might have security implications, but cache memory management is an implementation issue. If a Transport Model defines MIB module objects to maintain session state information, then the Transport Model MUST define what SHOULD happen to the objects when a related session is torn down, since this will impact interoperability of the MIB module. 3.3.3. Message security versus session security A Transport Model session is associated with state information that is maintained for its lifetime. This state information allows for the application of various security services to multiple messages. Cryptographic keys associated with the transport session SHOULD be used to provide authentication, integrity checking, and encryption services, as needed, for data that is communicated during the session. The cryptographic protocols used to establish keys for a Transport Model session SHOULD ensure that fresh new session keys are generated for each session. In addition sequence information might be maintained in the session which can be used to prevent the replay and reordering of messages within a session. 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 will also protect against replay attacks _within_ a session; that is, an attacker cannot successfully replay a message observed earlier in the same session. A Transport Model session will have a single transportDomain, transportAddress, securityName and securityLevel associated with it. If an exchange between communicating engines requires a different securityLevel or is on behalf of a different securityName, then another session would be needed. An immediate consequence of this is that implementations SHOULD be able to maintain some reasonable number of concurrent sessions. For Transport Models, securityName should be specified during session setup, and associated with the session identifier. SNMPv3 was designed to support multiple levels of security, selectable on a per-message basis by an SNMP application, because, for example, there is not much value in using encryption for a Commander Generator to poll for potentially non-sensitive performance data on thousands of interfaces every ten minutes; the encryption might add significant overhead to processing of the messages. Some Transport Models might support only specific authentication and Harrington & Schoenwaelder Expires March 18, 2008 [Page 17] =0C Internet-Draft SNMP Transport Subsystem September 2007 encryption services, such as requiring all messages to be carried using both authentication and encryption, regardless of the security level requested by an SNMP application. A Transport Model may upgrade the requested security level, i.e. noAuthNoPriv and authNoPriv MAY be sent over an authenticated and encrypted session. 4. Scenario Diagrams and the Transport Subsystem RFC3411 section 4.6.1 and 4.6.2 provide scenario diagrams to illustrate how an outgoing message is created, and how an incoming message is processed. RFC3411 does not define ASIs for "Send SNMP Request Message to Network" or "Receive SNMP Response Message from Network", and does not define ASIs for "Receive SNMP Message from Network" or "Send SNMP message to Network". This document defines a sendMessage ASI to send SNMP messages to the network, regardless of pduType, and a receiveMessage ASI to receive SNMP messages from the network, regardless of pduType. 5. Cached Information and References The RFC3411 architecture uses caches to store dynamic model-specific information, and uses references in the ASIs to indicate in a model- independent manner which cached information flows between subsystems. There are two levels of state that might need to be maintained: the security state in a request-response pair, and potentially long-term state relating to transport and security. This state is maintained in caches. To simplify the elements of procedure, the release of state information is not always explicitly specified. As a general rule, if state information is available when a message being processed gets discarded, the state related to that message should also be discarded, and if state information is available when a relationship between engines is severed, such as the closing of a transport session, the state information for that relationship might also be discarded. This document differentiates the tmStateReference from the securityStateReference. This document does not specify an implementation strategy, only an abstract description of the data that flows between subsystems. An implementation might use one cache and one reference to serve both functions, but an implementer must be aware of the cache-release issues to prevent the cache from being released before a security or Transport Model has had an opportunity to extract the information it needs. Harrington & Schoenwaelder Expires March 18, 2008 [Page 18] =0C Internet-Draft SNMP Transport Subsystem September 2007 5.1. securityStateReference The securityStateReference parameter is defined in RFC3411. securityStateReference is not accessible to models of the Transport Subsystem. 5.2. tmStateReference For each transport session, information about the message security is stored in a cache to pass model- and mechanism-specific parameters. The state referenced by tmStateReference may be saved across multiple messages, in a Local Configuration Datastore (LCD), as compared to securityStateReference which is usually only saved for the life of a request-response pair of messages. For security reasons, if a secure transport session is closed between the time a request message is received and the corresponding response message is sent, then the response message SHOULD be discarded, even if a new session has been established. The SNMPv3 WG decided that this should be a SHOULD architecturally, and it is a security-model- specific decision whether to REQUIRE this. Since a transport model does not know whether a message contains a response, and transport session information is transport-model- specific, the tmStateReference contains two pieces of information for performing the request-response transport session pairing. Each transport model that supports sessions and supports the tmStateReference cache SHOULD include a transport-specific session identifier in the cache for an incoming message, so that if a security model requests the same session, the transport model can determine whether the current existing session is the same as the session used for the incoming request. Each Security Model that supports the tmStateReference cache SHOULD pass a tmSameSession parameter in the tmStateReference cache for outgoing messages to indicate whether the same session MUST be used for the outgoing message as was used for the corresponding incoming message. If the same session requirement is indicated by the security model, but the session identified in the tmStateReference does not match the current established transport session, i.e., it is not the same session, then the message MUST be discarded, and the dispatcher should be notified the sending of the message failed. Since the contents of a cache are meaningful only within an implementation, and not on-the-wire, the format of the cache and the Harrington & Schoenwaelder Expires March 18, 2008 [Page 19] =0C Internet-Draft SNMP Transport Subsystem September 2007 LCD are implementation-specific. 6. Abstract Service Interfaces Abstract service interfaces have been defined by RFC 3411 to describe the conceptual data flows between the various subsystems within an SNMP entity, and to help keep the subsystems independent of each other except for the common parameters. This document follows the example of RFC3411 regarding the release of state information, and regarding error indications. 1) The release of state information is not always explicitly specified in a transport model. As a general rule, if state information is available when a message gets discarded, the message- state information should also be released, and if state information is available when a session is closed, the session state information should also be released. Note that keeping sensitive security information longer than necessary might introduce potential vulnerabilities to an implementation. 2) An error indication in statusInformation may include 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. 6.1. sendMessage ASI The sendMessage ASI is used to pass a message from the Dispatcher to the appropriate Transport Model for sending. In the diagram in section 4.6.1 of RFC 3411, the sendMessage ASI replaces the text "Send SNMP Request Message to Network". In section 4.6.2, the sendMessage ASI replaces the text "Send SNMP Message to Network" If present and valid, the tmStateReference refers to a cache containing transport-model-specific parameters for the transport and transport security. How the information in the cache is used is transport-model-dependent and implementation-dependent. How a tmStateReference is determined to be present and valid is implementation-dependent. This may sound underspecified, but a transport model might be something like SNMP over UDP over IPv6, where no security is provided, so it might have no mechanisms for utilizing a securityName and securityLevel. Harrington & Schoenwaelder Expires March 18, 2008 [Page 20] =0C Internet-Draft SNMP Transport Subsystem September 2007 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 ) 6.2. Other Outgoing ASIs A tmStateReference parameter has been added to the prepareOutgoingMessage, prepareResponseMessage, generateRequestMsg, and generateResponseMsg ASIs as an OUT parameter. The transportDomain and transportAddress parameters have been added to the generateRequestMsg, and generateResponseMsg ASIs as IN parameters (not shown). statusInformation =3D -- success or errorIndication prepareOutgoingMessage( IN transportDomain -- transport domain to be used IN transportAddress -- transport address to be used IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model to use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN contextEngineID -- data from/at this entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN expectResponse -- TRUE or FALSE IN sendPduHandle -- the handle for matching incoming responses OUT destTransportDomain -- destination transport domain OUT destTransportAddress -- destination transport address OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- its length OUT tmStateReference -- (NEW) reference to transport state ) Harrington & Schoenwaelder Expires March 18, 2008 [Page 21] =0C Internet-Draft SNMP Transport Subsystem September 2007 statusInformation =3D -- success or errorIndication prepareResponseMessage( IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model to use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN contextEngineID -- data from/at this entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN maxSizeResponseScopedPDU -- maximum size able to accept IN stateReference -- reference to state information -- as presented with the request IN statusInformation -- success or errorIndication -- error counter OID/value if error OUT destTransportDomain -- destination transport domain OUT destTransportAddress -- destination transport address OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- its length OUT tmStateReference -- (NEW) reference to transport state ) The tmStateReference parameter of generateRequestMsg or generateResponseMsg is passed in the OUT parameters of the Security Subsystem to the Message Processing Subsystem. If a cache exists for a session identifiable from transportDomain, transportAddress, securityModel, securityName, and securityLevel, then an appropriate Security Model might create a tmStateReference to the cache and pass that as an OUT parameter. If one does not exist, the Security Model might create a cache referenced by tmStateReference. This information might include transportDomain, transportAddress, the securityLevel, and the securityName, plus any model or mechanism-specific details. The contents of the cache may be incomplete until the Transport Model has established a session. What information is passed, and how this information is determined, is implementation and security-model- specific. The prepareOutgoingMessage ASI passes tmStateReference from the Message Processing Subsystem to the dispatcher. How or if the Message Processing Subsystem modifies or utilizes the contents of the cache is message-processing-model-specific. This may sound underspecified, but a message processing model might have access to all the information from the cache and from the message, and an application might specify a Security Model such as USM to authenticate and secure the SNMP message, but also specify a Harrington & Schoenwaelder Expires March 18, 2008 [Page 22] =0C Internet-Draft SNMP Transport Subsystem September 2007 secure transport such as that provided by the SSH Transport Model to send the message to its destination. 6.3. The receiveMessage ASI If one does not exist, the Transport Model might create a cache referenced by tmStateReference. If present, this information might include transportDomain, transportAddress, securityLevel, and securityName, plus model or mechanism-specific details. How this information is determined is implementation and transport-model- specific. In the diagram in section 4.6.1 of RFC 3411, the receiveMessage ASI replaces the text "Receive SNMP Response Message from Network". In section 4.6.2, the receiveMessage ASI replaces the text "Receive SNMP Message from Network" This may sound underspecified, but a transport model might be something like SNMP over UDP over IPv6, where no security is provided, so it might have no mechanisms for determining a securityName and securityLevel. The Transport Model does not know the securityModel for an incoming message; this will be determined by the Message Processing Model in a message-processing-model-dependent manner. The receiveMessage ASI is used to pass a message from the Transport Subsystem to the Dispatcher. statusInformation =3D receiveMessage( IN transportDomain -- origin transport domain IN transportAddress -- origin transport address IN incomingMessage -- the message received IN incomingMessageLength -- its length IN tmStateReference -- reference to transport state ) 6.4. Other Incoming ASIs To support the Transport Subsystem, the tmStateReference is added to the prepareDataElements ASI (from the Dispatcher to the Message Processing Subsystem), and to the processIncomingMsg ASI (from the Message Processing Subsystem to the Security Model Subsystem). How or if a Message Processing Model or Security Model uses tmStateReference is message-processing-model-dependent and security- model-dependent. Harrington & Schoenwaelder Expires March 18, 2008 [Page 23] =0C Internet-Draft SNMP Transport Subsystem September 2007 result =3D -- SUCCESS or errorIndication prepareDataElements( IN transportDomain -- origin transport domain IN transportAddress -- origin transport address IN wholeMsg -- as received from the network IN wholeMsgLength -- as received from the network IN tmStateReference -- (NEW) from the Transport Model OUT messageProcessingModel -- typically, SNMP version OUT securityModel -- Security Model to use OUT securityName -- on behalf of this principal OUT securityLevel -- Level of Security requested OUT contextEngineID -- data from/at this entity OUT contextName -- data from/in this context OUT pduVersion -- the version of the PDU OUT PDU -- SNMP Protocol Data Unit OUT pduType -- SNMP PDU type OUT sendPduHandle -- handle for matched request OUT maxSizeResponseScopedPDU -- maximum size sender can accept OUT statusInformation -- success or errorIndication -- error counter OID/value if error OUT stateReference -- reference to state information -- to be used for possible Response ) statusInformation =3D -- errorIndication or success -- error counter OID/value if error processIncomingMsg( IN messageProcessingModel -- typically, SNMP version IN maxMessageSize -- of the sending SNMP entity IN securityParameters -- for the received message IN securityModel -- for the received message IN securityLevel -- Level of Security IN wholeMsg -- as received on the wire IN wholeMsgLength -- length as received on the wire IN tmStateReference -- (NEW) from the Transport Model OUT securityEngineID -- authoritative SNMP entity OUT securityName -- identification of the principal OUT scopedPDU, -- message (plaintext) payload OUT maxSizeResponseScopedPDU -- maximum size sender can handle OUT securityStateReference -- reference to security state ) -- information, needed for response The tmStateReference parameter of prepareDataElements is passed from the dispatcher to the Message Processing Subsystem. How or if the Message Processing Subsystem modifies or utilizes the contents of the cache is message-processing-model-specific. Harrington & Schoenwaelder Expires March 18, 2008 [Page 24] =0C Internet-Draft SNMP Transport Subsystem September 2007 The processIncomingMessage ASI passes tmStateReference from the Message Processing Subsystem to the Security Subsystem. If tmStateReference is present and valid, an appropriate Security Model might utilize the information in the cache. How or if the Security Subsystem utilizes the information in the cache is security- model-specific. This may sound underspecified, but a message processing model might have access to all the information from the cache and from the message. The Message Processing Model might determine that the USM Security Model is specified in an SNMPv3 message header; the USM Security Model has no need of values in the tmStateReference cache to authenticate and secure the SNMP message, but an application might have specified to use a secure transport such as that provided by the SSH Transport Model to send the message to its destination. 7. Security Considerations This document defines an architectural approach that permits SNMP to utilize transport layer security services. Each proposed Transport Model should discuss the security considerations of the Transport Model. It is considered desirable by some industry segments that SNMP Transport Models should utilize transport layer security that addresses perfect forward secrecy at least for encryption keys. Perfect forward secrecy guarantees that compromise of long term secret keys does not result in disclosure of past session keys. Each proposed Transport Model should include a discussion in its security considerations of whether perfect forward security is appropriate for the Transport Model. Since the cache and LCD will contain security-related parameters, implementers should store this information (in memory or in persistent storage) in a manner to protect it from unauthorized disclosure and/or modification. 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. Otherwise an engine that has multiple transports open might be "tricked" into sending a message through the wrong transport. A Security Model may have multiple sources from which to define the securityName and securityLevel. The use of a secure Transport Model does not imply that the securityName and securityLevel chosen by the Security Model represent the transport-authenticated identity or the Harrington & Schoenwaelder Expires March 18, 2008 [Page 25] =0C Internet-Draft SNMP Transport Subsystem September 2007 transport-provided security services. The securityModel, securityName, and securityLevel parameters are a related set, and an administrator should understand how the specified securityModel selects the corresponding securityName and securityLevel. 7.1. Coexistence, Security Parameters, and Access Control In the RFC3411 architecture, the Message Processing Model makes the decision about which Security Model to use. The architectural change described by this document does not alter that. The architecture change described by this document does however, allow SNMP to support two different approaches to security - message- driven security and transport-driven security. With message-driven security, SNMP provides its own security, and passes security parameters within the SNMP message; with transport-driven security, SNMP depends on an external entity to provide security during transport by "wrapping" the SNMP message. Security models defined before the Transport Security Model (i.e., SNMPv1, SNMPv2c, and USM) do not support transport-based security, and only have access to the security parameters contained within the SNMP message. They do not know about the security parameters associated with a secure transport. As a result, the Access Control Subsystem bases its decisions on the security parameters extracted from the SNMP message, not on transport-based security parameters. Implications of coexistence of older security models with secure transport models are known: o An SNMPv1 message will always be paired with an SNMPv1 Security Model (per RFC3584), regardless of the transport mapping or transport model used, and access controls will be based on the community name. o An SNMPv2c message will always be paired with an SNMPv2c Security Model (per RFC3584), regardless of the transport mapping or transport model used, and access controls will be based on the community name.. o An SNMPv3 message will always be paired with the securityModel specified in the msgSecurityParameters field of the message (per RFC3412), regardless of the transport mappng or transport model used. If the SNMPv3 message specifies the User-based Security Model (USM), access controls will be based on the USM user.If the SNMPv3 message specifies the Transport Security Model (TSM), access controls will be based on the principal authenticated by the transport. Harrington & Schoenwaelder Expires March 18, 2008 [Page 26] =0C Internet-Draft SNMP Transport Subsystem September 2007 8. IANA Considerations This document requires no action by IANA. 9. Acknowledgments The Integrated Security for SNMP WG would like to thank the following people for their contributions to the process: The authors of submitted Security Model proposals: Chris Elliot, Wes Hardaker, David Harrington, Keith McCloghrie, Kaushik Narayan, David Perkins, Joseph Salowey, and Juergen Schoenwaelder. The members of the Protocol Evaluation Team: Uri Blumenthal, Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla. WG members who performed detailed reviews: Jeffrey Hutzelman, Bert Wijnen, Tom Petch. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for Harrington & Schoenwaelder Expires March 18, 2008 [Page 27] =0C Internet-Draft SNMP Transport Subsystem September 2007 version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. 10.2. Informative References [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. Harrington & Schoenwaelder Expires March 18, 2008 [Page 28] =0C Internet-Draft SNMP Transport Subsystem September 2007 [I-D.ietf-isms-transport-security-model] Harrington, D., "Transport Security Model for SNMP", d raft-ietf-isms-transport- security-model-05 (work in progress), July 2007. [I-D.ietf-isms-secshell] Salowey, J. and D. Harrington, "Secure Shell Transport Model for SNMP", draft-ietf-isms-secshell-08 (work in progress), July 2007. Appendix A. Why tmStateReference? This appendix considers why a cache-based approach was selected for passing parameters. There are four approaches that could be used for passing information between the Transport Model and a Security Model. 1. one could define an ASI to supplement the existing ASIs, or 2. one could add a header to encapsulate the SNMP message, 3. one could utilize fields already defined in the existing SNMPv3 message, or 4. one could pass the information in an implementation-specific cache or via a MIB module. A.1. Define an Abstract Service Interface Abstract Service Interfaces (ASIs) are defined by a set of primitives that specify the services provided and the abstract data elements that are to be passed when the services are invoked. Defining additional ASIs to pass the security and transport information from the Transport Subsystem to Security Subsystem has the advantage of being consistent with existing RFC3411/3412 practice, and helps to ensure that any Transport Model proposals pass the necessary data, and do not cause side effects by creating model-specific dependencies between itself and other models or other subsystems other than those that are clearly defined by an ASI. A.2. Using an Encapsulating Header A header could encapsulate the SNMP message to pass necessary information from the Transport Model to the dispatcher and then to a Message Processing Model. The message header would be included in the wholeMessage ASI parameter, and would be removed by a corresponding Message Processing Model. This would imply the (one Harrington & Schoenwaelder Expires March 18, 2008 [Page 29] =0C Internet-Draft SNMP Transport Subsystem September 2007 and only) messaging dispatcher would need to be modified to determine which SNMP message version was involved, and a new Message Processing Model would need to be developed that knew how to extract the header from the message and pass it to the Security Model. A.3. Modifying Existing Fields in an SNMP Message [RFC3412] defines the SNMPv3 message, which contains fields to pass security related parameters. The Transport Subsystem could use these fields in an SNMPv3 message, or comparable fields in other message formats to pass information between Transport Models in different SNMP engines, and to pass information between a Transport Model and a corresponding Message Processing Model. If the fields in an incoming SNMPv3 message are changed by the Transport Model before passing it to the Security Model, then the Transport Model will need to decode the ASN.1 message, modify the fields, and re-encode the message in ASN.1 before passing the message on to the message dispatcher or to the transport layer. This would require an intimate knowledge of the message format and message versions so the Transport Model knew which fields could be modified. This would seriously violate the modularity of the architecture. A.4. Using a Cache This document describes a cache, into which the Transport Model puts information about the security applied to an incoming message, and a Security Model can extract that information from the cache. Given that there might be multiple TM-security caches, a tmStateReference is passed as an extra parameter in the ASIs between the Transport Subsystem and the Security Subsystem, so the Security Model knows which cache of information to consult. This approach does create dependencies between a specific Transport Model and a corresponding specific Security Model. However, the approach of passing a model-independent reference to a model- dependent cache is consistent with the securityStateReference already being passed around in the RFC3411 ASIs. Appendix B. Open Issues NOTE to RFC editor: If this section is empty, then please remove this open issues section before publishing this document as an RFC. (If it is not empty, please send it back to the editor to resolve. o Harrington & Schoenwaelder Expires March 18, 2008 [Page 30] =0C Internet-Draft SNMP Transport Subsystem September 2007 Appendix C. Change Log NOTE to RFC editor: Please remove this change log before publishing this document as an RFC. Changes from -09- to -10- o Pointed to companion documents o Wordsmithed extensively o Modified the note about SNMPv3-consistent terminology o Modified the note about RFC2119 terminology. o Modified discussion of cryptographic key generation. o Added security considerations about coexistence with older security models o Expanded discussion of same session functionality o Described how sendMessage and receiveMessage fit into RFC3411 diagrams o Modified prepareResponseMessage ASI o Changes from -08- to -09- o A question was raised that notifications would not work properly, but we could never find the circumstances where this was true. o removed appendix with parameter matrix o Added a note about terminology, for consistency with SNMPv3 rather than with RFC2828. Changes from -07- to -08- o Identified new parameters in ASIs. o Added discussion about well-known ports. Changes from -06- to -07- o Removed discussion of double authentication o Removed all direct and indirect references to pduType by Transport Subsystem o Added warning regarding keeping sensitive security information available longer than needed. o Removed knowledge of securityStateReference from Transport Subsystem. o Changed transport session identifier to not include securityModel, since this is not known for incoming messages until the message processing model. Changes from revision -05- to -06- Harrington & Schoenwaelder Expires March 18, 2008 [Page 31] =0C Internet-Draft SNMP Transport Subsystem September 2007 mostly editorial changes removed some paragraphs considered unnecessary added Updates to header modified some text to get the security details right modified text re: ASIs so they are not API-like cleaned up some diagrams cleaned up RFC2119 language added section numbers to citations to RFC3411 removed gun for political correctness Changes from revision -04- to -05- removed all objects from the MIB module. changed document status to "Standard" rather than the xml2rfc default of informational. changed mention of MD5 to SHA moved addressing style to TDomain and TAddress modified the diagrams as requested removed the "layered stack" diagrams that compared USM and a Transport Model processing removed discussion of speculative features that might exist in future Transport Models removed openSession and closeSession ASIs, since those are model- dependent removed the MIB module removed the MIB boilerplate intro (this memo defines a SMIv2 MIB ...) removed IANA considerations related to the now-gone MIB module removed security considerations related to the MIB module removed references needed for the MIB module changed receiveMessage ASI to use origin transport domain/address updated Parameter CSV appendix Changes from revision -03- to -04- changed title from Transport Mapping Security Model Architectural Extension to Transport Subsystem modified the abstract and introduction changed TMSM to TMS changed MPSP to simply Security Model changed SMSP to simply Security Model changed TMSP to Transport Model removed MPSP and TMSP and SMSP from Acronyms section modified diagrams removed most references to dispatcher functionality worked to remove dependencies between transport and security models. Harrington & Schoenwaelder Expires March 18, 2008 [Page 32] =0C Internet-Draft SNMP Transport Subsystem September 2007 defined snmpTransportModel enumeration similar to snmpSecurityModel, etc. eliminated all reference to SNMPv3 msgXXXX fields changed tmSessionReference back to tmStateReference Changes from revision -02- to -03- o removed session table from MIB module o removed sessionID from ASIs o reorganized to put ASI discussions in EOP section, as was done in SSHSM o changed user auth to client auth o changed tmStateReference to tmSessionReference o modified document to meet consensus positions published by JS * authoritative is model-specific * msgSecurityParameters usage is model-specific * msgFlags vs. securityLevel is model/implementation-specific * notifications must be able to cause creation of a session * security considerations must be model-specific * TDomain and TAddress are model-specific * MPSP changed to SMSP (Security Model security processing) Changes from revision -01- to -02- o wrote text for session establishment requirements section. o wrote text for session maintenance requirements section. o removed section on relation to SNMPv2-MIB o updated MIB module to pass smilint o Added Structure of the MIB module, and other expected MIB-related sections. o updated author address o corrected spelling o removed msgFlags appendix o Removed section on implementation considerations. o started modifying the security boilerplate to address TMS and MIB security issues o reorganized slightly to better separate requirements from proposed solution. This probably needs additional work. o removed section with sample protocols and sample tmSessionReference. o Added section for acronyms o moved section comparing parameter passing techniques to appendix. o Removed section on notification requirements. Changes from revision -00- o changed SSH references from I-Ds to RFCs Harrington & Schoenwaelder Expires March 18, 2008 [Page 33] =0C Internet-Draft SNMP Transport Subsystem September 2007 o removed parameters from tmSessionReference for DTLS that revealed lower layer info. o Added TMS-MIB module o Added Internet-Standard Management Framework boilerplate o Added Structure of the MIB Module o Added MIB security considerations boilerplate (to be completed) o Added IANA Considerations o Added ASI Parameter table o Added discussion of Sessions o Added Open issues and Change Log o Rearranged sections Authors' Addresses David Harrington Huawei Technologies (USA) 1700 Alma Dr. Suite 100 Plano, TX 75075 USA Phone: +1 603 436 8634 EMail: dharrington@huawei.com Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany Phone: +49 421 200-3587 EMail: j.schoenwaelder@iu-bremen.de Harrington & Schoenwaelder Expires March 18, 2008 [Page 34] =0C Internet-Draft SNMP Transport Subsystem September 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Harrington & Schoenwaelder Expires March 18, 2008 [Page 35] =0C ------=_NextPart_000_0270_01C7F918.ABACFA40 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_000_0270_01C7F918.ABACFA40-- From isms-bounces@lists.ietf.org Mon Sep 17 16:32:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXNGI-0006nq-O5; Mon, 17 Sep 2007 16:32:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXNGI-0006nk-6k for isms@ietf.org; Mon, 17 Sep 2007 16:32:06 -0400 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXNGC-0000ai-08 for isms@ietf.org; Mon, 17 Sep 2007 16:32:06 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc13) with SMTP id <20070917203149m13000ogoae>; Mon, 17 Sep 2007 20:31:50 +0000 From: "David Harrington" To: , "'Romascanu, Dan \(Dan\)'" References: <20070911080452.GF16313@elstar.local> Subject: RE: [Isms] WGLC comments -draft-ietf-isms-transport-security-model-05.txt Date: Mon, 17 Sep 2007 16:31:31 -0400 Message-ID: <02ae01c7f969$bc4f1490$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf0SrOFHcOz3RNNRZqk2Hfpm+z13gFHmpyA In-Reply-To: <20070911080452.GF16313@elstar.local> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, September 11, 2007 4:05 AM > To: Romascanu, Dan (Dan) > Cc: isms@ietf.org > Subject: Re: [Isms] WGLC comments > -draft-ietf-isms-transport-security-model-05.txt > > > 3. Bert already mentioned the issue of > > > > ::= { snmpModules xxxx } > > > > Actually I believe there is a justification of consistency with the > > snmpUsmMIB which was defined prior to RFC 4181 if the > authors believe > > that this is important, but I agree that snmpTsmMIB is a > better MIB. > > > > If you do take this path, I believe that you should clarify > in the IANA > > considerations section that the policy of further assignments of new > > values under snmpModules is Standards Action. > > So I suggest we stick to snmpModules, change the OID descriptiors for > the module identity to have an snmp prefix, and document for IANA that > registrations under snmpModules requires a Standards Action. > I checked with Dan, who said one of the goals of 4181 was to become the reference for such controversies. The USM naming was done prior to the development of guideliens. But we are now post-guidelines, So I will make naming and assignments consistent with RFC4181. dbh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 18 02:56:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXWzo-0004Da-KZ; Tue, 18 Sep 2007 02:55:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXWzo-0004DA-2R for isms@ietf.org; Tue, 18 Sep 2007 02:55:44 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXWzm-0006k2-Kf for isms@ietf.org; Tue, 18 Sep 2007 02:55:44 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF16E55C7C; Tue, 18 Sep 2007 08:55:26 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 16450-04-24; Tue, 18 Sep 2007 08:55:19 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C8B286426; Tue, 18 Sep 2007 08:55:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DD26933E671; Tue, 18 Sep 2007 08:55:09 +0200 (CEST) Date: Tue, 18 Sep 2007 08:55:09 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] WGLC comments -draft-ietf-isms-transport-security-model-05.txt Message-ID: <20070918065509.GA21634@elstar.local> Mail-Followup-To: David Harrington , "'Romascanu, Dan (Dan)'" , isms@ietf.org References: <20070911080452.GF16313@elstar.local> <02ae01c7f969$bc4f1490$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02ae01c7f969$bc4f1490$6702a8c0@china.huawei.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Mon, Sep 17, 2007 at 04:31:31PM -0400, David Harrington wrote: > I checked with Dan, who said one of the goals of 4181 was to become > the reference for such controversies. > > The USM naming was done prior to the development of guideliens. But we > are now post-guidelines, So I will make naming and assignments > consistent with RFC4181. Fine with me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 18 05:09:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXZ4K-0003Sm-0e; Tue, 18 Sep 2007 05:08:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXZ4J-0003Sg-Jp for isms@ietf.org; Tue, 18 Sep 2007 05:08:31 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXZ4E-0001DR-5D for isms@ietf.org; Tue, 18 Sep 2007 05:08:31 -0400 Received: from pc6 (1Cust249.tnt1.lnd4.gbr.da.uu.net [62.188.130.249]) by ranger.systems.pipex.net (Postfix) with SMTP id E113BE000675; Tue, 18 Sep 2007 10:08:06 +0100 (BST) Message-ID: <00ed01c7f9ca$269111e0$0601a8c0@pc6> From: "tom.petch" To: "Jeffrey Hutzelman" , References: <015401c7e57d$7fed4f80$6702a8c0@china.huawei.com><015c01c7e593$98d5f360$6702a8c0@china.huawei.com> <7BE8AE0B34C905DEB7E8EE51@sirius.fac.cs.cmu.edu> Subject: Re: [Isms] More questions on Security name Date: Tue, 18 Sep 2007 10:00:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -104.0 (---------------------------------------------------) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org ----- Original Message ----- From: "Jeffrey Hutzelman" To: "David Harrington" ; "'Wijnen, Bert (Bert)'" ; "'Joseph Salowey (jsalowey)'" ; Cc: "Jeffrey Hutzelman" Sent: Tuesday, August 28, 2007 12:32 AM Subject: RE: [Isms] More questions on Security name > > When we get to talking about notifications, it still works to fold (1) and > (2) into the transport address, because that is still the address of the > agent we want to contact. However, we run into trouble with (3) because > SSH needs to know the username of the notification originator, while the > architecture seems to assume here that securityName is the name of the > notification receiver. In USM that doesn't matter, because the > securityName actually names the pair. But for SSH it does; my name is > _not_ the same as your name. > > Obviously it is possible for an implementation to work around this by > providing an implementation-specific way to specify the username to be > used, or by ignoring the architecture and declaring that for a > notification, the username actually describes the NO and not the NR. I > imagine there are other possibilities as well. > > This problem is not unique to SSH; rather, the lack of it is unique (or > nearly so) to USM. IMHO that means there is a problem either with the > architecture or with our understanding of it, and that problem needs to be > solved before a clean solution to authenticating outgoing notifications is > possible. Jeff I have been mulling this problem over, albeit without any profound insight. SNMP requires the recipient of data (NR, CG) to be authenticated/authorised be it for a simplex transaction (NO->NR) or a half-duplex one (CG<->CR). SSH requires the initiator of the transaction (NO, CG) to become the user; SSHTM makes the user's name the principal with the consequences described. USM 'gets round' this by having a identity/security credentials for the transaction rather than for each party to the transaction. With a secure transport, the equivalent could be Pre-Shared Key or perhaps Secure Remote Password. The identity doesn't matter - could be SSHusername@server.hostname as Joe suggested - but, as ever, distributing security credentials remains the problem; somewhat defeats the purpose of ISMS. (Or we could take the syslog approach that it is the Notification Originator that should be authenticated:-) Tom Petch > > -- Jeff > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 18 12:31:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXfym-0008So-Vu; Tue, 18 Sep 2007 12:31:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXfyl-0008SD-IB for isms@ietf.org; Tue, 18 Sep 2007 12:31:15 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXfyl-0008MW-4c for isms@ietf.org; Tue, 18 Sep 2007 12:31:15 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 064AA8670D for ; Tue, 18 Sep 2007 18:31:14 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 29761-02-30; Tue, 18 Sep 2007 18:31:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6EB3986728; Tue, 18 Sep 2007 18:05:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D703233F2A2; Tue, 18 Sep 2007 18:05:05 +0200 (CEST) Date: Tue, 18 Sep 2007 18:05:05 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20070918160505.GB22768@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Isms] properly closing an ssh session X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, I have a question for SSH experts (hope there are some on this list). I am wondering what the proper way of closing the SSH session is in our case. Note that we run a single SSH channel over the SSH transport and there are several options now. a) Be brutal and simply close the underlying TCP connection. b) Be a bit less brutal and send an SSH_DISCONNECT with say a reason code of SSH_DISCONNECT_BY_APPLICATION and be done. c) Be friendly and play the game of doing an SSH_CHANNEL_CLOSE exchange followed by SSH_DISCONNECT. d) Be overly friendly by exchanging SSH_CHANNEL_EOF before exchanging SSH_CHANNEL_CLOSE and doing an SSH_DISCONNECT. My reading of the RFCs indicates that d) is not really required and of course a) will always work. There might be reasons to do b) although it is not clear which benefit one would get (since my understanding is that SSH_DISCONNECT does not impact who is closing the TCP connection and who has to go into wait state). Any suggestions what should be done to play the SSH game nicely? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 18 15:15:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXiXp-0007pg-Or; Tue, 18 Sep 2007 15:15:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXiXk-0007nw-RN; Tue, 18 Sep 2007 15:15:32 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXiXk-00049G-E6; Tue, 18 Sep 2007 15:15:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 51E852AC49; Tue, 18 Sep 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IXiXG-0002mP-1q; Tue, 18 Sep 2007 15:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 18 Sep 2007 15:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-tmsm-10.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Subsystem for the Simple Network Management Protocol (SNMP) Author(s) : D. Harrington, J. Schoenwaelder Filename : draft-ietf-isms-tmsm-10.txt Pages : 35 Date : 2007-9-18 This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models, comparable to other subsystems in the RFC3411 architecture. As work is being done to expand the transport to include secure transport such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isms-tmsm-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isms-tmsm-10.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-9-18144811.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-tmsm-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-tmsm-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-18144811.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@lists.ietf.org Tue Sep 18 17:35:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXkip-0005Cy-0n; Tue, 18 Sep 2007 17:35:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXkio-00056g-2z for isms@ietf.org; Tue, 18 Sep 2007 17:35:06 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXkic-0004V7-BW for isms@ietf.org; Tue, 18 Sep 2007 17:35:01 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc11) with SMTP id <20070918213437m11003omm9e>; Tue, 18 Sep 2007 21:34:38 +0000 From: "David Harrington" To: Date: Tue, 18 Sep 2007 17:34:22 -0400 Message-ID: <03b201c7fa3b$ae07f500$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_03B3_01C7FA1A.26F65500" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf6O61qO+ZVEIZFQuOcsxDNDSKJWA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8c35716c93d6fe8951733162060375ae Cc: Subject: [Isms] TSM -06 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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 This is a multi-part message in MIME format. ------=_NextPart_000_03B3_01C7FA1A.26F65500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Here is an update to the transport security model. I submitted this to the internet-drafts editor. David Harrington dbharrington@comcast.net ietfdbh@comcast.net ------=_NextPart_000_03B3_01C7FA1A.26F65500 Content-Type: text/plain; name="draft-ietf-isms-transport-security-model-06.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-isms-transport-security-model-06.txt" Network Working Group D. Harrington Internet-Draft Huawei Technologies (USA) Intended status: Standards Track September 18, 2007 Expires: March 21, 2008 Transport Security Model for SNMP draft-ietf-isms-transport-security-model-06 Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo describes a Transport Security Model for the Simple Network Management Protocol. This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for monitoring and managing the Transport Security Model for SNMP. Harrington Expires March 21, 2008 [Page 1] =0C Internet-Draft Transport Security Model for SNMP September 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Internet-Standard Management Framework . . . . . . . . 3 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5 2. How the Transport Security Model Fits in the Architecture . . 5 2.1. Security Capabilities of this Model . . . . . . . . . . . 6 2.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Security Levels . . . . . . . . . . . . . . . . . . . 7 2.2. No Sessions . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Coexistence . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Security Parameter Passing . . . . . . . . . . . . . . . . 8 2.5. Notifications and Proxy . . . . . . . . . . . . . . . . . 9 3. Cached Information and References . . . . . . . . . . . . . . 9 3.1. tmStateReference . . . . . . . . . . . . . . . . . . . . . 10 3.2. securityStateReference . . . . . . . . . . . . . . . . . . 10 4. Processing an Outgoing Message . . . . . . . . . . . . . . . . 10 4.1. Security Processing for an Outgoing Message . . . . . . . 10 4.2. Elements of Procedure for Outgoing Messages . . . . . . . 12 5. Processing an Incoming SNMP Message . . . . . . . . . . . . . 12 5.1. Security Processing for an Incoming Message . . . . . . . 12 5.2. Elements of Procedure for Incoming Messages . . . . . . . 13 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 14 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 14 6.2. The tsmStats Subtree . . . . . . . . . . . . . . . . . . . 14 6.3. Relationship to Other MIB Modules . . . . . . . . . . . . 14 6.3.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . 14 6.3.2. Relationship to the SNMP-FRAMEWORK-MIB . . . . . . . . 15 6.3.3. MIB Modules Required for IMPORTS . . . . . . . . . . . 15 7. MIB module definition . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8.1. MIB module security . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 Appendix A. Notification Tables Configuration . . . . . . . . . . 21 A.1. Transport Security Model Processing . . . . . . . . . . . 22 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 23 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 23 Harrington Expires March 21, 2008 [Page 2] =0C Internet-Draft Transport Security Model for SNMP September 2007 1. Introduction This memo describes a Transport Security Model for the Simple Network Management Protocol, for use with secure Transport Models in the Transport Subsystem [I-D.ietf-isms-tmsm]. This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for monitoring and managing the Transport Security Model for SNMP. It is important to understand the SNMP architecture and the terminology of the architecture to understand where the Transport Security Model described in this memo fits into the architecture and interacts with other subsystems and models within the architecture. It is expected that reader will have also read and understood RFC3411 [RFC3411], RFC3412 [RFC3412], RFC3413 [RFC3413], and RFC3418 [RFC3418]. 1.1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 1.2. Conventions For consistency with SNMP-related specifications, this document favors terminology as defined in STD62 rather than favoring terminology that is consistent with non-SNMP specifications that use different variations of the same terminology. This is consistent with the IESG decision to not require the SNMPv3 terminology be modified to match the usage of other non-SNMP specifications when SNMPv3 was advanced to Full Standard. Authentication in this document typically refers to the English meaning of "serving to prove the authenticity of" the message, not data source authentication or peer identity authentication. Harrington Expires March 21, 2008 [Page 3] =0C Internet-Draft Transport Security Model for SNMP September 2007 The terms "manager" and "agent" are not used in this document, because in the RFC 3411 architecture, all SNMP entities have the capability of acting as either manager or agent or both depending on the SNMP applications included in the engine. Where distinction is required, the application names of Command Generator, Command Responder, Notification Originator, Notification Receiver, and Proxy Forwarder are used. See "SNMP Applications" [RFC3413] for further information. While security protocols frequently refer to a user, the terminology used in RFC3411 [RFC3411] and in this memo is "principal". A principal is the "who" on whose behalf services are provided or processing takes place. A principal can be, among other things, an individual acting in a particular role; a set of individuals, with each acting in a particular role; an application or a set of applications, or a combination of these within an administrative domain. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.3. Modularity The reader is expected to have read and understood the description of the SNMP architecture, as defined in [RFC3411], and the architecture extension specified in "Transport Subsystem for the Simple Network Management Protocol" [I-D.ietf-isms-tmsm], which enables the use of external "lower layer transport" protocols to provide message security, tied into the SNMP architecture through the Transport Subsystem. The Transport Security Model is designed to work with such lower-layer secure Transport Models. In keeping with the RFC 3411 design decisions to use self-contained documents, this memo includes the elements of procedure plus associated MIB objects which are needed for processing the Transport Security Model for SNMP. These MIB objects SHOULD not be referenced in other documents. This allows the Transport Security Model to be designed and documented as independent and self-contained, having no direct impact on other modules, and allowing this module to be upgraded and supplemented as the need arises, and to move along the standards track on different time-lines from other modules. This modularity of specification is not meant to be interpreted as imposing any specific requirements on implementation. Harrington Expires March 21, 2008 [Page 4] =0C Internet-Draft Transport Security Model for SNMP September 2007 1.4. Motivation This memo describes a Security Model to make use of Transport Models that use lower layer secure transports and existing and commonly deployed security infrastructures. This Security Model is designed to meet the security and operational needs of network administrators, maximize usability in operational environments to achieve high deployment success and at the same time minimize implementation and deployment costs to minimize the time until deployment is possible. 1.5. Constraints The design of this SNMP Security Model is also influenced by the following constraints: 1. In times of network stress, the security protocol and its underlying security mechanisms SHOULD NOT depend solely upon the ready availability of other network services (e.g., Network Time Protocol (NTP) or Authentication, Authorization, and Accounting (AAA) protocols). 2. When the network is not under stress, the Security Model and its underlying security mechanisms MAY depend upon the ready availability of other network services. 3. It may not be possible for the Security Model to determine when the network is under stress. 4. A Security Model should require no changes to the SNMP architecture. 5. A Security Model should require no changes to the underlying security protocol. 2. How the Transport Security Model Fits in the Architecture The Transport Security Model is designed to fit into the RFC3411 architecture as a Security Model in the Security Subsystem, and to utilize the services of a secure Transport Model. A cache, referenced by tmStateReference, is used to pass information between the Transport Security Model and a Transport Model, and vice versa. If the Transport Security Model is used with an insecure Transport Model, then the cache will not exist or be populated with security parameters, which will cause the Transport Security Model to return an error (see section 5.2) If another Security Model (eg Community-based Security Model) is used with a secure Transport Model, then the cache may be populated but the other Security Model may be unaware of the cache and ignore its contents (eg deriving the securityName from the Community name in the message instead of deriving it from the tmSecurityName in the tmStateReference cache). When a secure Transport Model creates a tmStateReference cache for an Harrington Expires March 21, 2008 [Page 5] =0C Internet-Draft Transport Security Model for SNMP September 2007 incoming message, it will include a tmTransport, tmAddress, tmSecurityName and a tmTransportSecurityLevel, and it MAY include transport-specific information. When the Transport Security Model sends a message, it will create a cache containing the specified transportDomain, transportAddress, securityName, and securityLevel parameters. The Transport Security Model will pass the tmStateReference to enable the transport model to extract corresponding transport-specific information from the tmStateReference cache, in an implementation-dependent manner. When the Transport Security Model determines that a cache does not yet exist corresponding to the specified transportDomain, transportAddress, secuirtyName, and securityLevel parameters, it creates one that contains a tmSecurityName and tmRequestedSecurityLevel and passes the tmStateReference cache to the specified Transport Model. The Transport Security Model will determine the security-model- independent securityName and securityLevel, and will verify for incoming messages that tmTransportSecurityLevel is at least as strong as the requested securityLevel. To maintain the RFC3411 modularity, the Transport Model does not know which securityModel will be used for an incoming message; the Message Processing Model will determine the securityModel to be used, in a Message Processing Model dependent manner. 2.1. Security Capabilities of this Model 2.1.1. Threats The Transport Security Model, when used with suitable secure Transport Models, provides protection against the threats identified by the RFC 3411 architecture [RFC3411]. Which threats are addressed depends on the Transport Model. The Transport Security Model does not address any threats itself, but delegates that responsibility to a secure Transport Model. The Transport Security Model is called a Security Model to be compatible with the RFC3411 architecture. However, this Security Model does not provide security mechanisms such as authentication and encryption itself, so it SHOULD always be used with a Transport Model that provides appropriate security. Harrington Expires March 21, 2008 [Page 6] =0C Internet-Draft Transport Security Model for SNMP September 2007 2.1.2. Security Levels The RFC 3411 architecture recognizes three levels of security: - without authentication and without privacy (noAuthNoPriv) - with authentication but without privacy (authNoPriv) - with authentication and with privacy (authPriv) The model-independent securityLevel parameter is used to request specific levels of security for outgoing messages, and to assert that specific levels of security were applied during the transport and processing of incoming messages. The transport layer algorithms used to provide security SHOULD NOT be exposed to the Transport Security Model, as the Transport Security Model has no mechanisms by which it can test whether an assertion made by a Transport Model is accurate. The Transport Security Model trusts that the underlying secure transport connection has been properly configured to support security characteristics at least as strong as reported in tmTransportSecurityLevel. 2.2. No Sessions The Transport Security Model will associate state regarding each message and each known remote engine with a combination of transportDomain, transportAddress, securityName, securityModel, and securityLevel. The Transport Security Model does not recognize sessions of any kind, although they may be supported by a transport model. 2.3. Coexistence There are two primary factors which determine whether Security Models can coexist. First, there must be a mechanism to select different Security Models at run-time. Second, the processing of one Security Model should not impact the processing of another Security Model. In the RFC3411 architecture, a Message Processing Model determines which Security Model should be called. As of this writing, IANA has registered four Message Processing Models (SNMPv1, SNMPv2c, SNMPv2u/ SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1, SNMPv2c, and the User-based Security Model). The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP 74) [RFC3584] always selects the SNMPv1(1) Security Model for an SNMPv1 message, or the SNMPv2c(2) Security Model for an SNMPv2c Harrington Expires March 21, 2008 [Page 7] =0C Internet-Draft Transport Security Model for SNMP September 2007 message. Since there is no field in the message format that permits specifying a Security Model, RFC3584 message processing does not permit the selection of Security Models other than SNMPv1 or SNMPv2. Therefore, SNMPv1 or SNMPv2c messages that go through the SNMPv1 or SNMPv2 Message Processing Models **as defined in RFC3584** cannot use the Transport Security Model. (This does not mean an SNMPv1 or SNMPv2 message cannot use a secure transport model, only that the RFC3584 Message Processing Model will not invoke this security model.) The SNMPv2u/SNMPv2* Message Processing Model is a historic artifact for which there is no existing IETF specification. The SNMPv3 message processing defined in RFC3412 [RFC3412], extracts the securityModel from the msgSecurityModel field of an incoming SNMPv3Message. When the extracted value of msgSecurityModel is transportSecurityModel(YY), security processing is directed to the Transport Security Model. For an outgoing message to be secured using the Transport Security Model, msgSecurityModel should be set to transportSecurityModel(YY). [-- NOTE to RFC editor: replace YY with actual IANA-assigned number, and remove this note. ] The Transport Security Model uses its own MIB module for processing to maintain independence from other Security Models. This allows the Transport Security Model to coexist with other Security Models, such as the User-based Security Model. Note that the Transport Security Model may work with multiple Transport Models, but the isAccessAllowed() application service interfaces (ASI) only accepts a value for the Security Model, not for Transport Models. As a result, it is not possible to have different access control rules for different Transport Models that use the Transport Security Model. 2.4. Security Parameter Passing For outgoing messages, Transport Security Model uses parameters provided by the SNMP application to determine if a corresponding tmStateReference cache exists, or to create a suitable tmStateReference cache. The wholeMsg and the tmStateReference are passed to the appropriate Transport Model through a series of ASIs, as described in "Transport Subsystem for the Simple Network Management Protocol" [I-D.ietf-isms-tmsm]. For incoming messages, the Transport Model accepts messages from the lower layer transport, and records the transport-related information Harrington Expires March 21, 2008 [Page 8] =0C Internet-Draft Transport Security Model for SNMP September 2007 and security-related information, including a tmSecurityName that represents the transport-authenticated identity, and a tmTransportSecurityLevel that represents the security features provided during transport, in a cache referenced by tmStateReference. The wholeMsg and the tmStateReference are passed to the appropriate Security Model through a series of ASIs, as described in "Transport Subsystem for the Simple Network Management Protocol" [I-D.ietf-isms-tmsm]. 2.5. Notifications and Proxy The SNMP-TARGET-MIB module [RFC3413] contains objects for defining management targets, including transportDomain, transportAddress, securityName, securityModel, and securityLevel parameters, for applications such as notifications and proxy. Transport type and address are configured in the snmpTargetAddrTable, and the securityModel, securityName, and securityLevel parameters are configured in the snmpTargetParamsTable. For the Transport Security Model, these will be translated as needed into tmSecurityName and tmRequestedSecurityLevel. The default approach is for an administrator to statically configure this information to identify the targets authorized to receive notifications or perform proxy. 3. Cached Information and References The RFC3411 architecture uses caches to store dynamic model-specific information, and uses references in the ASIs to indicate in a model- independent manner which cached information must flow between subsystems. There are two levels of state that may need to be maintained: the security state in a request-response pair, and potentially long-term state relating to transport and security. This document describes caches, and differentiates the tmStateReference from the securityStateReference, but how this is represented internally is an implementation decision. As a general rule, if state information is available when a message being processed gets discarded, the state related to that message should also be discarded, and if state information is available when a relationship between engines is severed, such as the closing of a transport connection, the state information for that relationship might also be discarded. Harrington Expires March 21, 2008 [Page 9] =0C Internet-Draft Transport Security Model for SNMP September 2007 3.1. tmStateReference For each transport model, information about the transport security may be stored in a cache to pass model- and mechanism-specific parameters. For security reasons, the Transport Security Model REQUIRES that the security parameters used for a response are the same as those used for the corresponding request, and passes a tmSameSecurity parameter in the tmStateReference cache for outgoing messages to indicate that the same security MUST be used for the outgoing response as was used for the corresponding incoming request. It is transport-model- dependent and implementation-dependent how this is ensured at the transport layer. Since the contents of a cache are meaningful only within an implementation, and not on-the-wire, the format of the cache is implementation-specific. 3.2. securityStateReference The securityStateReference parameter is defined in RFC3411. Its primary purpose is to provide a mapping between a request and the corresponding response. A sample model-specific cache can be found in RFC3414 [RFC3414]. Transport models do not have access to the securityStateReference. For the Transport Security Model, it is important to ensure that the security parameters used for a request match those used for the corresponding response. The Transport Security Model will conceptually add the tmStateReference to the securityStateReference cache, so the transport model can map transport-specific security parameters for a request to its corresponding response. How the tmStateReference is added to the securityStateReference is implementation-specific. 4. Processing an Outgoing Message 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. 4.1. Security Processing for an Outgoing Message This section describes the procedure followed by the Transport Security Model. Harrington Expires March 21, 2008 [Page 10] =0C Internet-Draft Transport Security Model for SNMP September 2007 The parameters needed for generating a message are supplied to the Security Model by the Message Processing Model via the generateRequestMsg() or the generateResponseMsg() ASI. The Transport Subsystem architectural extension has added the transportDomain, transportAddress, and tmStateReference parameters to the original RFC3411 ASIs. statusInformation =3D -- success or errorIndication generateRequestMsg( IN messageProcessingModel -- typically, SNMP version IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN transportDomain -- (NEW) specified by application IN transportAddress -- (NEW) specified by application IN securityModel -- for the outgoing message IN securityEngineID -- authoritative SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN scopedPDU -- message (plaintext) payload OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of generated message OUT tmStateReference -- (NEW) transport info ) statusInformation =3D -- success or errorIndication generateResponseMsg( IN messageProcessingModel -- typically, SNMP version IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN transportDomain -- (NEW) specified by application IN transportAddress -- (NEW) specified by application IN securityModel -- for the outgoing message IN securityEngineID -- authoritative SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN scopedPDU -- message (plaintext) payload IN securityStateReference -- reference to security state -- information from original -- request OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of generated message OUT tmStateReference -- (NEW) transport info ) Harrington Expires March 21, 2008 [Page 11] =0C Internet-Draft Transport Security Model for SNMP September 2007 4.2. Elements of Procedure for Outgoing Messages 1) If there is a securityStateReference, then this is a response message. Extract transportDomain, transportAddress, securityName, securityLevel, securityModel, and tmStateReference from the securityStateReference cache. Set the tmRequestedSecurityLevel to the value of the extracted securityLevel. The cachedSecurityData for this message can now be discarded. Set the tmSameSecurity parameter in the tmStateReference cache to true. 2) If there is no securityStateReference, create a tmStateReference cache with tmSecurityName set to the value of securityName, tmRequestedSecurityLevel set to the value of securityLevel, and tmSameSecurity set to false. 3) Fill in the securityParameters with a zero-length OCTET STRING ('0400'). 4) Combine the message parts into a wholeMsg and calculate wholeMsgLength. 5) The wholeMsg, wholeMsgLength, securityParameters and tmStateReference are returned to the calling Message Processing Model with the statusInformation set to success. 5. Processing an Incoming SNMP Message 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. 5.1. Security Processing for an Incoming Message This section describes the procedure followed by the Transport Security Model whenever it receives an incoming message from a Message Processing Model. The ASI from a Message Processing Model to the Security Subsystem for a received message is: Harrington Expires March 21, 2008 [Page 12] =0C Internet-Draft Transport Security Model for SNMP September 2007 statusInformation =3D -- errorIndication or success -- error counter OID/value if error processIncomingMsg( IN messageProcessingModel -- typically, SNMP version IN maxMessageSize -- from the received message IN securityParameters -- from the received message IN securityModel -- from the received message IN securityLevel -- from the received message IN wholeMsg -- as received on the wire IN wholeMsgLength -- length as received on the wire IN tmStateReference -- (NEW) from the Transport Model OUT securityEngineID -- authoritative SNMP entity OUT securityName -- identification of the principal OUT scopedPDU, -- message (plaintext) payload OUT maxSizeResponseScopedPDU -- maximum size sender can handle OUT securityStateReference -- reference to security state ) -- information, needed for response 5.2. Elements of Procedure for Incoming Messages 1) Set the securityEngineID to the local snmpEngineID. 2) If tmStateReference does not refer to a cache containing values for tmSecurityName and tmTransportSecurityLevel, then the snmpTsmInvalidCaches counter is incremented, an error indication is returned to the calling module, and Security Model processing stops for this message. 3) Set securityName to the value of tmSecurityName from the cache referenced by tmStateReference. 4) Compare the value of tmTransportSecurityLevel in the tmStateReference cache to the value of the securityLevel parameter passed in the processIncomingMsg ASI. If securityLevel specifies privacy (Priv), and tmTransportSecurityLevel specifies no privacy (noPriv), or securityLevel specifies authentication (auth) and tmTransportSecurityLevel specifies no authentication (noAuth) was provided by the Transport Model, then the snmpTsmInadequateSecurityLevels counter is incremented, and an error indication (unsupportedSecurityLevel) together with the OID and value of the incremented counter is returned to the calling module. Transport Security Model processing stops for this message. 5)The security data is cached as cachedSecurityData, so that a possible response to this message will use the same security parameters. Then securityStateReference is set for subsequent reference to this cached data. For Transport Security Model, the securityStateReference includes a reference to the tmStateReference Harrington Expires March 21, 2008 [Page 13] =0C Internet-Draft Transport Security Model for SNMP September 2007 cache. 6) The scopedPDU component is extracted from the wholeMsg. 7) The maxSizeResponseScopedPDU is calculated. This is the maximum size allowed for a scopedPDU for a possible Response message. 8) The statusInformation is set to success and a return is made to the calling module passing back the OUT parameters as specified in the processIncomingMsg ASI. 6. MIB Module Overview This MIB module provides management of the Transport Security Model. It defines some needed textual conventions, and some statistics. 6.1. Structure of the MIB Module Objects in this MIB module are arranged into subtrees. Each subtree is organized as a set of related objects. The overall structure and assignment of objects to their subtrees, and the intended purpose of each subtree, is shown below. 6.2. The tsmStats Subtree This subtree contains counters specific to the Transport Security Model, that provide information for identifying fault conditions. 6.3. Relationship to Other MIB Modules Some management objects defined in other MIB modules are applicable to an entity implementing the Transport Security Model In particular, it is assumed that an entity implementing the Transport Security Model will implement the SNMPv2-MIB [RFC3418] and the SNMP-FRAMEWORK- MIB [RFC3411]. 6.3.1. Relationship to the SNMPv2-MIB The 'system' group in the SNMPv2-MIB [RFC3418] is defined as being mandatory for all systems, and the objects apply to the entity as a whole. The 'system' group provides identification of the management entity and certain other system-wide data. The snmpInASNParseErrs counter is incremented during the elements of procedure. The SNMP- TRANSPORT-SM-MIB does not duplicate those objects. Harrington Expires March 21, 2008 [Page 14] =0C Internet-Draft Transport Security Model for SNMP September 2007 6.3.2. Relationship to the SNMP-FRAMEWORK-MIB The SNMP-FRAMEWORK-MIB provides definitions for the concepts of SnmpEngineID, enumeration of Message Processing Models, Security Models and Security Levels, and object definitions for snmpEngineID These are important for implementing the Transport Security Model, but are not needed to implement the SNMP-TRANSPORT-SM-MIB. 6.3.3. MIB Modules Required for IMPORTS The following MIB module imports items from [RFC2578] and [RFC2580]. 7. MIB module definition SNMP-TSM-MIB DEFINITIONS ::=3D BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Counter32 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ; snmpTsmMIB MODULE-IDENTITY LAST-UPDATED "200710140000Z" ORGANIZATION "ISMS Working Group" CONTACT-INFO "WG-EMail: isms@lists.ietf.org Subscribe: isms-request@lists.ietf.org Chairs: Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany +49 6221 90511-15 quittek@netlab.nec.de Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany +49 421 200-3587 j.schoenwaelder@iu-bremen.de Harrington Expires March 21, 2008 [Page 15] =0C Internet-Draft Transport Security Model for SNMP September 2007 Editor: David Harrington Huawei Technologies USA 1700 Alma Dr. Plano TX 75075 USA +1 603-436-8634 ietfdbh@comcast.net " DESCRIPTION "The Transport Security Model MIB In keeping with the RFC 3411 design decisions to use self-contained documents, the RFC which contains the definition of this MIB module also includes the elements of procedure which are needed for processing the Transport Security Model for SNMP. These MIB objects SHOULD NOT be modified via other documents. This allows the Transport Security Model for SNMP to be designed and documented as independent and self- contained, having no direct impact on other modules, and this allows this module to be upgraded and supplemented as the need arises, and to move along the standards track on different time-lines from other modules. Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices. -- NOTE to RFC editor: replace XXXX with actual RFC number -- for this document and remove this note " REVISION "200710140000Z" DESCRIPTION "The initial version, published in RFC XXXX. -- NOTE to RFC editor: replace XXXX with actual RFC number -- for this document and remove this note " ::=3D { mib-2 xxxx } -- RFC Ed.: replace xxxx with IANA-assigned number and -- remove this note -- ---------------------------------------------------------- -- -- subtrees in the SNMP-TRANSPORT-SM-MIB -- ---------------------------------------------------------- -- Harrington Expires March 21, 2008 [Page 16] =0C Internet-Draft Transport Security Model for SNMP September 2007 snmpTsmNotifications OBJECT IDENTIFIER ::=3D { snmpTsmMIB 0 } snmpTsmMIBObjects OBJECT IDENTIFIER ::=3D { snmpTsmMIB 1 } snmpTsmConformance OBJECT IDENTIFIER ::=3D { snmpTsmMIB 2 } -- ------------------------------------------------------------- -- Objects -- ------------------------------------------------------------- -- Statistics for the Transport Security Model snmpTsmStats OBJECT IDENTIFIER ::=3D { snmpTsmMIBObjects 1 } snmpTsmInvalidCaches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages dropped because the tmStateReference referred to an invalid cache. " ::=3D { snmpTsmStats 1 } snmpTsmInadequateSecurityLevels OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming messages dropped because the actual securityLevel provided was less than the requested securityLevel. " ::=3D { snmpTsmStats 2 } -- ------------------------------------------------------------- -- snmpTsmMIB - Conformance Information -- ------------------------------------------------------------- snmpTsmCompliances OBJECT IDENTIFIER ::=3D { snmpTsmConformance 1 } snmpTsmGroups OBJECT IDENTIFIER ::=3D { snmpTsmConformance 2 } -- ------------------------------------------------------------- -- Compliance statements -- ------------------------------------------------------------- snmpTsmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines that support Harrington Expires March 21, 2008 [Page 17] =0C Internet-Draft Transport Security Model for SNMP September 2007 the SNMP-TRANSPORT-SM-MIB" MODULE MANDATORY-GROUPS { snmpTsmGroup } ::=3D { snmpTsmCompliances 1 } -- ------------------------------------------------------------- -- Units of conformance -- ------------------------------------------------------------- snmpTsmGroup OBJECT-GROUP OBJECTS { snmpTsmInvalidCaches, snmpTsmInadequateSecurityLevels } STATUS current DESCRIPTION "A collection of objects for maintaining information of an SNMP engine which implements the SNMP Transport Security Model. " ::=3D { snmpTsmGroups 2 } END 8. Security Considerations This document describes a Security Model that permits SNMP to utilize security services provided through an SNMP Transport Model. The Transport Security Model relies on Transport Models for mutual authentication, binding of keys, confidentiality and integrity. The security threats and how those threats are mitigated should be covered in detail in the specification of the Transport Model and the underlying secure transport. Transport Security Model relies on a Transport Model to provide an authenticated principal for mapping to securityName, and an assertion of tmTransportSecurityLevel. The Transport Security Model is called a Security Model to be compatible with the RFC3411 architecture. However, this Security Model provides no security itself. It SHOULD always be used with a Transport Model that provides security, but this is a run-time decision of the operator or management application, or a configuration decision of an operator. Harrington Expires March 21, 2008 [Page 18] =0C Internet-Draft Transport Security Model for SNMP September 2007 8.1. MIB module security There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o snmpTsmInvalidCaches and snmpTsmInadequateSecurityLevels may make it easier for an attacker to detect vulnerabilities. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410] section 8), including full support for the USM and Transport Security Model cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. IANA Considerations IANA is requested to assign: 1. an SMI number under mib-2, for the MIB module in this document, 2. a value, preferably 4, to identify the Transport Security Model, in the Security Models registry at http://www.iana.org/assignments/snmp-number-spaces. This should result in the following table of values: Harrington Expires March 21, 2008 [Page 19] =0C Internet-Draft Transport Security Model for SNMP September 2007 Value Description References ----- ----------- ---------- 0 reserved for 'any' [RFC3411] 1 reserved for SNMPv1 [RFC3411] 2 reserved for SNMPv2c [RFC3411] 3 User-Based Security Model (USM) [RFC3411] YY Transport Security Model (TSM) [RFCXXXX] -- NOTE to RFC editor: replace XXXX with actual RFC number -- for this document and remove this note -- NOTE to RFC editor: replace YY with actual IANA-assigned number, throughout this document and remove this note. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. Harrington Expires March 21, 2008 [Page 20] =0C Internet-Draft Transport Security Model for SNMP September 2007 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", draft-ietf-isms-tmsm-10 (work in progress), September 2007. 10.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003. Appendix A. Notification Tables Configuration The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to configure notification originators with the destinations to which notifications should be sent. Most of the configuration is security-model-independent and transport-model-independent. The values we will use in the examples for the five model-independent security and transport parameters are: transportDomain =3D snmpSSHDomain transportAddress =3D 192.0.2.1:162 securityModel =3D Transport Security Model securityName =3D sampleUser securityLevel =3D authPriv The following example will configure the Notification Originator to send informs to a Notification Receiver at host 192.0.2.1 port 162 using the securityName "sampleUser". The columns marked with a "*" are the items that are Security Model or Transport Model specific. Harrington Expires March 21, 2008 [Page 21] =0C Internet-Draft Transport Security Model for SNMP September 2007 The configuration for the "sampleUser" settings in the SNMP-VIEW- BASED-ACM-MIB objects are not shown here for brevity. First we configure which type of notification should be sent for this taglist (toCRTag). In this example, we choose to send an Inform. snmpNotifyTable row: snmpNotifyName CRNotif snmpNotifyTag toCRTag snmpNotifyType inform snmpNotifyStorageType nonVolatile snmpNotifyColumnStatus createAndGo Then we configure a transport address to which notifications associated with this taglist should be sent, and we specify which snmpTargetParamsEntry should be used (toCR) when sending to this transport address. snmpTargetAddrTable row: snmpTargetAddrName toCRAddr * snmpTargetAddrTDomain snmpSSHDomain snmpTargetAddrTAddress 192.0.2.1:162 snmpTargetAddrTimeout 1500 snmpTargetAddrRetryCount 3 snmpTargetAddrTagList toCRTag snmpTargetAddrParams toCR (must match below) snmpTargetAddrStorageType nonVolatile snmpTargetAddrColumnStatus createAndGo Then we configure which principal at the host should receive the notifications associated with this taglist. Here we choose "sampleUser", who uses the Transport Security Model. snmpTargetParamsTable row: snmpTargetParamsName toCR snmpTargetParamsMPModel SNMPv3 * snmpTargetParamsSecurityModel TransportSecurityModel snmpTargetParamsSecurityName "sampleUser" snmpTargetParamsSecurityLevel authPriv snmpTargetParamsStorageType nonVolatile snmpTargetParamsRowStatus createAndGo A.1. Transport Security Model Processing The Transport Security Model is called using the generateRequestMsg() ASI, with the following parameters (* are from the above tables): Harrington Expires March 21, 2008 [Page 22] =0C Internet-Draft Transport Security Model for SNMP September 2007 statusInformation =3D -- success or errorIndication generateRequestMsg( IN messageProcessingModel -- *snmpTargetParamsMPModel IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN transportDomain -- *snmpTargetAddrTDomain IN transportAddress -- *snmpTargetAddrTAddress IN securityModel -- *snmpTargetParamsSecurityModel IN securityEngineID -- immaterial; TSM will ignore. IN securityName -- snmpTargetParamsSecurityName IN securityLevel -- *snmpTargetParamsSecurityLevel IN scopedPDU -- message (plaintext) payload OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of generated message OUT tmStateReference -- reference to transport info ) The Transport Security Model will determine the Transport Model based on the snmpTargetAddrTDomain. The selected Transport Model will select the appropriate transport connection using the snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and snmpTargetParamsSecurityLevel. Appendix B. Open Issues none. Appendix C. Change Log From -05- to -06- Fixed a bunch of editorial nits Fixed the note about terminology consistent with SNMPv3. Updated MIB assignment to by rfc4181 compatible Replaced tmSameSession with tmSameSecurity to eliminate session- matching from the security model. Eliminated all reference to the LCD from the Transport Security Model; the LCD is now TM-specific. Added tmTransportSecurityLevel and tmRequestedSecurityLevel to clarify incoming versus outgoing From -04- to -05- Removed check for empty securityParameters for incoming messages Added a note about terminology, for consistency with SNMPv3 rather than with RFC2828. Harrington Expires March 21, 2008 [Page 23] =0C Internet-Draft Transport Security Model for SNMP September 2007 From -03- to -04- Editorial changes requested by Tom Petch, to clarify behavior with SNMPv1/v2c Added early discussion of how TSM fits into the architecture to clarify behavior when RFC3584 security models are co-resident. Editorial changes requested by Bert Wijnen, to eliminate version- specific discussions. Removed sections on version-specific message formats. Removed discussion of SNMPv3 in Motivation section. Added discussion of request/response session matching. From -02- to -03- Editorial changes suggested by Juergen Schoenwaelder Capitalized Transport Models, Security Models, and Message Processing Models, to be consistent with RFC341x conventions. Eliminated some text that duplicated RFC3412, especially in Elements of Procedure. Changed the encoding of msgSecurityParameters Marked the (NEW) fields added to existing ASIs Modified text intro discussing relationships to other MIB modules. From -01- to -02- Changed transportSecurityModel(4) to transportSecurityModel(YY), waiting for assignment cleaned up elements of procedure [todo]s use the same errorIndication as USM for unsupportedSecurityLevel fixed syntax of tsmInadequateSecurity counter changed the "can and will use" the same security parameters to "can use", to allow responses that have different security parameters than the request. removed "Relationship to the SNMP-FRAMEWORK-MIB" cleaned up "MIB Modules Required for IMPORTS" From -00- to -01- made the Transport Model not know anything about the Security Model. modified the elements of procedure sections, given the implications of this change. simplified elements of procedure, removing most info specified in architecture/subsystem definitions. rethought the coexistence section noted the implications of the Transport Security Model on isAccessAllowed() Harrington Expires March 21, 2008 [Page 24] =0C Internet-Draft Transport Security Model for SNMP September 2007 modified all text related to the LCD. removed most of the MIB (now the TSM has no configuration parameters). added counters needed to support elements of procedure renamed MIB module, and registered under snmpModules updated IANA and Security Considerations updated references. modified the notification configurations. From SSHSM-04- to Transport-security-model-00 added tsmUserTable updated Appendix - Notification Tables Configuration remove open/closed issue appendices changed tmSessionReference to tmStateReference Author's Address David Harrington Huawei Technologies (USA) 1700 Alma Dr. Suite 100 Plano, TX 75075 USA Phone: +1 603 436 8634 EMail: dharrington@huawei.com Harrington Expires March 21, 2008 [Page 25] =0C Internet-Draft Transport Security Model for SNMP September 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Harrington Expires March 21, 2008 [Page 26] =0C ------=_NextPart_000_03B3_01C7FA1A.26F65500 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_000_03B3_01C7FA1A.26F65500-- From isms-bounces@lists.ietf.org Wed Sep 19 04:38:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXv3P-0007bs-Lj; Wed, 19 Sep 2007 04:37:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXv3O-0007al-ND for isms@ietf.org; Wed, 19 Sep 2007 04:37:02 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXv3O-0000ml-4V for isms@ietf.org; Wed, 19 Sep 2007 04:37:02 -0400 Received: from pc6 (1Cust58.tnt106.lnd4.gbr.da.uu.net [213.116.60.58]) by astro.systems.pipex.net (Postfix) with SMTP id A4C45E000177; Wed, 19 Sep 2007 09:36:58 +0100 (BST) Message-ID: <012701c7fa8e$f75b3c00$0601a8c0@pc6> From: "tom.petch" To: References: <016c01c7f6f8$c1333770$6702a8c0@china.huawei.com> <20070915133135.GC18859@elstar.local> Date: Wed, 19 Sep 2007 09:28:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ISMS WG Subject: [Isms] must and should in tmsm-10 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Juergen I looked at tmsm-10 for the issues that I had raised; three seem unresolved. In 3.2.1.2, it says " If a message is secured using a secure transport layer, then the Transport Model should provide the translation from the authenticated identity" where I would like a must (probably better than MUST). The arguments are well rehearsed. No matter how clever those are who come after, I cannot see a STM working with a TSM unless this translation is made available by the TM; any other approach - eg putting it in the ASI or having the TSM extract it for itself - would require a further change to the architecture. As I mentioned, I have dry-run the architecture ASI, EoP etc for a range of scenarios that might occur, got stuck on this 'should' and spent ages wondering what subtlety I was missing, finally concluding that I wasn't; but if I got stuck, others will too. Jeff pointed out that it was not needed for STM+USM - true, but the STM does not know architecturally what SM this message will go to, that is up to the MPP. And the context of 3.2.1.2 for me is STM+TSM (should the title be changed from 'Transport Subsystem and the RFC3411 Architecture'? - after all, 3.2.1.1.1 is 'USM and the RFC3411 Architecture'; probably too minor to be concerned with). And David does not like unnecessary MUSTs because they come back to inhibit future development. Anyhow, you know all this, so enough (too much:-) said. But this raises a delectable irony with my second point. In 5.2 it says " Each Security Model that supports the tmStateReference cache SHOULD pass a tmSameSession parameter in the tmStateReference cache for outgoing messages to indicate whether the same session MUST be used for the outgoing message as was used for the corresponding incoming message." A dbh e-mail 25apr07 said "The Transport Subsystem architecture document will reflect the SNMPv3 WG's decision that **architecturally** this is a SHOULD. The decision is security-model-dependent, and the Transport Security Model will make it a MUST." I am still seeing that MUST; and when I look at tsm, I think I see a SHOULD (although I am looking at the previous tsm I-D, not the revised tsm). And these MUSTs do have a habit of constricting those who come after us, who may come up with a cleverer idea than us:-) Finally, I was expecting to see a change around the two paragraphs in s2 starting " This document defines a Transport Subsystem extension to the RFC3411.." which, as I have said before, I see as key paragraphs to the understanding of the roles of the three I-Ds. Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Sep 19 14:26:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY4FM-0002T5-SY; Wed, 19 Sep 2007 14:26:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY4FL-0002Sx-Dg for isms@ietf.org; Wed, 19 Sep 2007 14:25:59 -0400 Received: from rwcrmhc15.comcast.net ([216.148.227.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY4FK-0001LQ-4T for isms@ietf.org; Wed, 19 Sep 2007 14:25:59 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc15) with SMTP id <20070919182542m1500c61s5e>; Wed, 19 Sep 2007 18:25:42 +0000 From: "David Harrington" To: "'tom.petch'" , References: <016c01c7f6f8$c1333770$6702a8c0@china.huawei.com><20070915133135.GC18859@elstar.local> <012701c7fa8e$f75b3c00$0601a8c0@pc6> Subject: RE: [Isms] must and should in tmsm-10 Date: Wed, 19 Sep 2007 14:25:23 -0400 Message-ID: <040601c7faea$7269dc20$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf6mHlGNQs5SmbJSdqucdwl8lAKugAMKMbw In-Reply-To: <012701c7fa8e$f75b3c00$0601a8c0@pc6> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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, comments inline. dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Wednesday, September 19, 2007 3:28 AM > To: j.schoenwaelder@jacobs-university.de > Cc: ISMS WG > Subject: [Isms] must and should in tmsm-10 > > Juergen > > I looked at tmsm-10 for the issues that I had raised; three > seem unresolved. > > In 3.2.1.2, it says > " If a message is secured using a secure transport layer, then the > Transport Model should provide the translation from the > authenticated > identity" > where I would like a must (probably better than MUST). The > arguments are well > rehearsed. No matter how clever those are who come after, I > cannot see a STM > working with a TSM unless this translation is made available > by the TM; any > other approach - eg putting it in the ASI or having the TSM > extract it for > itself - would require a further change to the architecture. > As I mentioned, I > have dry-run the architecture ASI, EoP etc for a range of > scenarios that might > occur, got stuck on this 'should' and spent ages wondering > what subtlety I was > missing, finally concluding that I wasn't; but if I got > stuck, others will too. > Jeff pointed out that it was not needed for STM+USM - true, > but the STM does not > know architecturally what SM this message will go to, that is > up to the MPP. > And the context of 3.2.1.2 for me is STM+TSM > And David does not like unnecessary MUSTs because they come > back to inhibit > future development. > (should the > title be changed from > 'Transport Subsystem and the RFC3411 Architecture'? - after > all, 3.2.1.1.1 is > 'USM and the RFC3411 Architecture'; probably too minor to be > concerned with). The text in the first two paragraphs of 3.2.1.1 provide the simplified overview that is really important. There have been multiple complaints about these lists and the comparisons. To make this simple, I will remove 3.2.1.1.1 and 3.2.1.2 and the last paragraph of 3.2.1.1, then we don't need to worry about whether the lists line up properly, or what we should title the lists. > > Anyhow, you know all this, so enough (too much:-) said. > > But this raises a delectable irony with my second point. In > 5.2 it says > " Each Security Model that supports the tmStateReference cache SHOULD > pass a tmSameSession parameter in the tmStateReference cache for > outgoing messages to indicate whether the same session MUST be used > for the outgoing message as was used for the corresponding incoming > message." > > A dbh e-mail 25apr07 said > "The Transport Subsystem architecture document will reflect the SNMPv3 > WG's decision that **architecturally** this is a SHOULD. > The decision is security-model-dependent, and the Transport Security > Model will make it a MUST." > > I am still seeing that MUST; and when I look at tsm, I think > I see a SHOULD > (although I am looking at the previous tsm I-D, not the > revised tsm). And these > MUSTs do have a habit of constricting those who come after > us, who may come up > with a cleverer idea than us:-) s5.2 has a number of SHOULDs and a number of MUSTs. I am not sure which MUST you object to. p2 says if the response doesn't match the request, it SHOULD be discarded, BUT the decision is security-model-dependent, not architectural. A security model can REQUIRE this. (or not, depending on the security model) p4 says each transport model SHOULD include a session ID so the TM can determine whether the session is the same. (but an alternative approach for identifying a session is acceptable as well) p5 says the tmSameSession field should be supported in the cache, so a security model can indicate whether it is REQUIRED or not. (I changed the name of this in TSM, so there is currently a consistency issue with the name; I'll fix that in the next rev. In addition, I think the presence of this parameter needs to be transport/security model-independent, so if there is consensus, I will make this a MUST in the next rev.) p6 says **if** the security model said it is REQUIRED, and the session is not the same, then the transport model MUST discard the message. I don't see the inconsistency in MUST usage that you apparently see. > > Finally, I was expecting to see a change around the two > paragraphs in s2 > starting > " This document defines a Transport Subsystem extension to > the RFC3411.." which, > as I have said before, I see as key paragraphs to the > understanding of the roles > of the three I-Ds. Section 1 is about the overall management framework, the SNMP architecure, and where this subsystem fits within the overall framework/architecture and where the ISMS documents "fit" within the whole set of SNMPv3-related documents. The description of the roles of the three isms IDs you proposed is in s1.2 "Where This Extension Fits", which is the section that discusses the roles of other documents that are needed to work with the subsystem. Section 2 is about motivation. The two paragraphs you refer to in section 2 discuss how the subsystem addresses the motivations - common security infrastructures, unified administrative security, use of existing security mechanisms. Section 2 is not about the roles of different documents and where they fit. If the WG really wants the discussion of how the docuemnnt fit together to be in the motivations section rather than in the section that talks about how the documents all fit together, I'll move it. Personally, I think the current organization makes more sense. > > Tom Petch > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 20 07:40:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYKMT-0001bx-02; Thu, 20 Sep 2007 07:38:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYKMS-0001Dd-6q for isms@ietf.org; Thu, 20 Sep 2007 07:38:24 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYKM4-0003sg-BB for isms@ietf.org; Thu, 20 Sep 2007 07:38:01 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94A95866AC; Thu, 20 Sep 2007 13:37:58 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 01864-03-9; Thu, 20 Sep 2007 13:37:52 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6DEAB865E8; Thu, 20 Sep 2007 13:18:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CC0D8341A36; Thu, 20 Sep 2007 13:18:11 +0200 (CEST) Date: Thu, 20 Sep 2007 13:18:11 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] must and should in tmsm-10 Message-ID: <20070920111811.GA27081@elstar.local> Mail-Followup-To: David Harrington , "'tom.petch'" , 'ISMS WG' References: <012701c7fa8e$f75b3c00$0601a8c0@pc6> <040601c7faea$7269dc20$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <040601c7faea$7269dc20$6702a8c0@china.huawei.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Wed, Sep 19, 2007 at 02:25:23PM -0400, David Harrington wrote: > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Wednesday, September 19, 2007 3:28 AM > > To: j.schoenwaelder@jacobs-university.de > > Cc: ISMS WG > > Subject: [Isms] must and should in tmsm-10 > > > > Juergen > > > > I looked at tmsm-10 for the issues that I had raised; three > > seem unresolved. > > > > In 3.2.1.2, it says > > " If a message is secured using a secure transport layer, then the > > Transport Model should provide the translation from the > > authenticated > > identity" > > where I would like a must (probably better than MUST). The > > arguments are well > > rehearsed. No matter how clever those are who come after, I > > cannot see a STM > > working with a TSM unless this translation is made available > > by the TM; any > > other approach - eg putting it in the ASI or having the TSM > > extract it for > > itself - would require a further change to the architecture. > > As I mentioned, I > > have dry-run the architecture ASI, EoP etc for a range of > > scenarios that might > > occur, got stuck on this 'should' and spent ages wondering > > what subtlety I was > > missing, finally concluding that I wasn't; but if I got > > stuck, others will too. > > Jeff pointed out that it was not needed for STM+USM - true, > > but the STM does not > > know architecturally what SM this message will go to, that is > > up to the MPP. > > And the context of 3.2.1.2 for me is STM+TSM > > And David does not like unnecessary MUSTs because they come > > back to inhibit > > future development. > > (should the > > title be changed from > > 'Transport Subsystem and the RFC3411 Architecture'? - after > > all, 3.2.1.1.1 is > > 'USM and the RFC3411 Architecture'; probably too minor to be > > concerned with). > > The text in the first two paragraphs of 3.2.1.1 provide the > simplified overview that is really important. > > There have been multiple complaints about these lists and the > comparisons. > To make this simple, I will remove 3.2.1.1.1 and 3.2.1.2 and the last > paragraph of 3.2.1.1, then we don't need to worry about whether the > lists line up properly, or what we should title the lists. Speaking as technical contributor, I think that the processing steps are actually useful to get an idea how things work. I am wondering, however, whether this text perhaps be moved into the TSM document and then the headlines would be "USM processing of incoming messages" and "TSM processing of incoming messages". Right now, the problem seems to be that the architectural extension is much more general and thus it is kind of difficult to be concrete. The TSM document, however, can easily be concret. So what about making this comparison an appendix of the TSM document instead of deleting it completely? > > Anyhow, you know all this, so enough (too much:-) said. > > > > But this raises a delectable irony with my second point. In > > 5.2 it says > > " Each Security Model that supports the tmStateReference cache > SHOULD > > pass a tmSameSession parameter in the tmStateReference cache for > > outgoing messages to indicate whether the same session MUST be > used > > for the outgoing message as was used for the corresponding > incoming > > message." > > > > A dbh e-mail 25apr07 said > > "The Transport Subsystem architecture document will reflect the > SNMPv3 > > WG's decision that **architecturally** this is a SHOULD. > > The decision is security-model-dependent, and the Transport Security > > Model will make it a MUST." > > > > I am still seeing that MUST; and when I look at tsm, I think > > I see a SHOULD > > (although I am looking at the previous tsm I-D, not the > > revised tsm). And these > > MUSTs do have a habit of constricting those who come after > > us, who may come up > > with a cleverer idea than us:-) > > s5.2 has a number of SHOULDs and a number of MUSTs. I am not sure > which MUST you object to. > > p2 says if the response doesn't match the request, it SHOULD be > discarded, BUT > the decision is security-model-dependent, not architectural. > A security model can REQUIRE this. (or not, depending on the security > model) > > p4 says each transport model SHOULD include a session ID so the TM can > determine whether the session is the same. (but an alternative > approach for identifying a session is acceptable as well) > > p5 says the tmSameSession field should be supported in the cache, so a > security model can indicate whether it is REQUIRED or not. (I changed > the name of this in TSM, so there is currently a consistency issue > with the name; I'll fix that in the next rev. In addition, I think the > presence of this parameter needs to be transport/security > model-independent, so if there is consensus, I will make this a MUST > in the next rev.) > > p6 says **if** the security model said it is REQUIRED, and the session > is not the same, then the transport model MUST discard the message. > > I don't see the inconsistency in MUST usage that you apparently see. My reading of the the text matches David's explanation and I am not really sure where the problem is or how to improve things. Tom, can you re-read the text and tell us precisely what you want to get changed? > > Finally, I was expecting to see a change around the two > > paragraphs in s2 > > starting > > " This document defines a Transport Subsystem extension to > > the RFC3411.." which, > > as I have said before, I see as key paragraphs to the > > understanding of the roles > > of the three I-Ds. > > Section 1 is about the overall management framework, the SNMP > architecure, and where this subsystem fits within the overall > framework/architecture and where the ISMS documents "fit" within the > whole set of SNMPv3-related documents. The description of the roles of > the three isms IDs you proposed is in s1.2 "Where This Extension > Fits", which is the section that discusses the roles of other > documents that are needed to work with the subsystem. > > Section 2 is about motivation. The two paragraphs you refer to in > section 2 discuss how the subsystem addresses the motivations - common > security infrastructures, unified administrative security, use of > existing security mechanisms. Section 2 is not about the roles of > different documents and where they fit. > > If the WG really wants the discussion of how the docuemnnt fit > together to be in the motivations section rather than in the section > that talks about how the documents all fit together, I'll move it. > Personally, I think the current organization makes more sense. Personally, I also think that section 1.2 is rather clear where the pieces fit. If I would anything to explain this better, I would do so directly before 1.3 by adding a sentence or extending that last sentence before 1.3. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 21 13:15:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYm5y-000874-Fe; Fri, 21 Sep 2007 13:15:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYm5n-0007nB-Ui; Fri, 21 Sep 2007 13:15:04 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYm5n-0002lP-CU; Fri, 21 Sep 2007 13:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id DD83D175C8; Fri, 21 Sep 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IYm5l-0006ph-WC; Fri, 21 Sep 2007 13:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Sep 2007 13:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-transport-security-model-06.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Security Model for SNMP Author(s) : D. Harrington Filename : draft-ietf-isms-transport-security-model-06.txt Pages : 26 Date : 2007-9-21 This memo describes a Transport Security Model for the Simple Network Management Protocol. This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for monitoring and managing the Transport Security Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-transport-security-model-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isms-transport-security-model-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isms-transport-security-model-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-21122627.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-transport-security-model-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-transport-security-model-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-21122627.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 Sep 26 16:14:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IadH0-00006C-9P; Wed, 26 Sep 2007 16:14:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IadGy-0008G0-Fb for isms@ietf.org; Wed, 26 Sep 2007 16:14:16 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IadGs-0007KQ-8i for isms@ietf.org; Wed, 26 Sep 2007 16:14:16 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96D3387DEB for ; Wed, 26 Sep 2007 22:13:58 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 03143-06; Wed, 26 Sep 2007 22:13:54 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A7F9F87E28; Wed, 26 Sep 2007 22:13:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4FD8E34B10D; Wed, 26 Sep 2007 22:13:54 +0200 (CEST) Date: Wed, 26 Sep 2007 22:13:54 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20070926201354.GA27245@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Isms] no wg meeting in vancouver X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, the scheduling of WG meetings for the Vancouver IETF has just started. My current thinking is that the ISMS working group does not need to meet in Vancouver. The core ISMS specifications have hopefully been delivered to the IESG well before the Vancouver meeting. Since the Radius document seems to be well on its way as well, I do not think that we need a face-to-face meeting in Vancouver. I believe we can very well resolve any remaining issues and the remaining charter items via the mailing list. If you believe we need an ISMS WG meeting in Vancouver, please let me know now so that we can discuss the topics do discuss face-to-face and arrange things well in advance. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 27 01:50:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IamGn-0006ep-8A; Thu, 27 Sep 2007 01:50:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IamGm-0006eS-Bt for isms@ietf.org; Thu, 27 Sep 2007 01:50:40 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IamGl-0003DS-Q4 for isms@ietf.org; Thu, 27 Sep 2007 01:50:40 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <2007092705503901200434jae>; Thu, 27 Sep 2007 05:50:39 +0000 From: "David Harrington" To: References: <015401c7e57d$7fed4f80$6702a8c0@china.huawei.com> <20070914141918.GE23435@elstar.local> Subject: RE: [Isms] More questions on Security name Date: Thu, 27 Sep 2007 01:50:32 -0400 Message-ID: <00ce01c800ca$51d33890$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20070914141918.GE23435@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf22kVX+v4Qdda2TsyOdaAsE5b0MQJ5UVxw X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, comments inline. > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, September 14, 2007 10:19 AM > To: David Harrington > Cc: 'Wijnen, Bert (Bert)'; 'Joseph Salowey (jsalowey)'; isms@ietf.org > Subject: Re: [Isms] More questions on Security name > > On Thu, Aug 23, 2007 at 08:02:37AM -0400, David Harrington wrote: > > > As I recall, no solution was found to this issue. I think we reached > > consensus that > > 1) if a client had already established a connection, so we have a > > relevant securityname, then that connection could be reused for > > notiications. > > This, of course, requires that appropriate entries exist in the > snmpTargetTable and friends that point to this notification > destination. In other words, this assumes a subscription mechanism > where you establish the SSH transport and then create entries that > direct notifications to the SSH session. I am not a system administrator, but my view of the world says that a sysadmin would want to control who gets notifications. So I envision the target table (subscriptions) being defined statically to include a small number of targets, not dynamically for all SNMP users that can establish an SSH transport. But I could be wrong; maybe the target table could be generated dynamically and let the access control system control who gets them. > > The only issue left with this approach (as I recall) is how to garbage > collect those dynamic entries in the snmpTargetTable and friends, > which likely needs a sparse augmentation of the snmpTargetTable. > > > 2) if a notification needs to be sent, and no SSH connection exists, > > then the transport model will try to create a connection. How the > > credentials are supplied, and how the connectionis created is > > implementation-specific. The slides from IETF67 present three > > options for doing this, which may or may not work. > > The straight forward approach is to have an SSH user name plus > whatever credentials needed for authentication on the "device" and to > use the authenticated host identity as the security name (and thus as > input for the access control decision). The transport model doesn't know whether a message is a notification. The userauth protocol allows for multiple authentication mechanisms, but if we use the authenticated host identity as securityName, then we not only need to specify different method names, we need to specify a whole different "level" of authentication. I don't know how that would be specified. I am particularly concerned about combining reuse of a userauth session for sending notifications, and having a totally different level of authentication for others, all handled through the same transport model/security model. If I have a VACM securityName for user "gandalf" and TSM, does that refer to a userauth (client-auth) gandalf, or a hostauth (server-auth) gandalf? If the channel was opened by the remote client, and the connection is reused, then it refers to client auth; if a notification needs to be sent before a request is received, it refers to server-only-auth. And those two auths might have different security properties related to access control. One way to resolve this might be to define different transport domains, one for userauth and another for server-auth-only. I'm not sure transportDomain shows up in the access control decision, but it does show up in the application decision of transport. In USM, we would treat these as different authn mechanisms leading to securitynames, but that used static configuration of the usmUserTable to get the mappings. > > We investigated turning SSH roles around and finally concluded that > this is not going to work due to security issues; at least not without > a surgery of SSH (which is not our business). > > > 3) if a notification needs to be sent, and no SSH connection exists, > > then the agent can use USM to send the notification. This is > > implementation-specific. > > Implementation-specific magic to fallback to USM does not seem to be a > solution to pursue on a standards-track. > > So I think we essentially have 2) and an incomplete 1). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 27 12:41:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IawPt-0004eJ-Ru; Thu, 27 Sep 2007 12:40:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IawPr-0004eA-UN for isms@ietf.org; Thu, 27 Sep 2007 12:40:43 -0400 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IawPo-0007OL-S5 for isms@ietf.org; Thu, 27 Sep 2007 12:40:41 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <200709271640400120042f4pe>; Thu, 27 Sep 2007 16:40:40 +0000 From: "David Harrington" To: Date: Thu, 27 Sep 2007 12:40:34 -0400 Message-ID: <010801c80125$20960720$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgBJSA06ywHF2r+SsW42B7xDaBgVw== X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Subject: [Isms] SnmpSSHAddress X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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, Bert and Jeff raised questions about the format for IPv4/IPv6 addresses and hostnames. Is the following acceptable? Is there an RFC that describes the textual representation of an IPv6 address? Bert pointed out that MIB addresses have been inconsistent - some use '/' to separate the port nunber and others use ':'. Jeff pointed out that using a colon makes it difficult to determine where an IPv6 address ends and the port starts. Maybe we should use the ':' separator for the hostname format, and the '/' separator for the IP address formats to eliminate the ambiguity. RFC4181 has no guidance on this point; are there other documents that provide guidance on the separator character for hostnames and/or IP adddresses? SnmpSSHAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1a" STATUS current DESCRIPTION "Represents either a hostname with a port number or an IP address with a port number. The hostname must be encoded in ASCII, as specified in RFC3490 (Internationalizing Domain Names in Applications) followed by a colon ':' (ASCII character 0x3A) and a decimal port number in ASCII. The name SHOULD be fully qualified whenever possible. An IPv4 address must be a dotted decimal format followed by a colon ':' (ASCII character 0x3A) and a decimal port number in ASCII. An IPv6 address must be a colon separated format, surrounded by brackets, followed by a colon ':' (ASCII character 0x3A) and a decimal port number in ASCII. Values of this textual convention may not be directly useable as transport-layer addressing information, and may require runtime resolution. As such, applications that write them must be prepared for handling errors if such values are not supported, or cannot be resolved (if resolution occurs at the time of the management operation). The DESCRIPTION clause of TransportAddress objects that may have snmpSSHAddress values must fully describe how (and when) such names are to be resolved to IP addresses and vice versa. This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair. When this textual convention is used as a syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the OBJECT-TYPE declaration MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers." SYNTAX OCTET STRING (SIZE (1..255)) David Harrington dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 27 12:49:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IawY0-0006sN-CV; Thu, 27 Sep 2007 12:49:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IawXz-0006hZ-B5 for isms@ietf.org; Thu, 27 Sep 2007 12:49:07 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IawXt-00048p-7Q for isms@ietf.org; Thu, 27 Sep 2007 12:49:07 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <2007092716484501400rj6hie>; Thu, 27 Sep 2007 16:48:45 +0000 From: "David Harrington" To: "'Wijnen, Bert \(Bert\)'" , References: Date: Thu, 27 Sep 2007 12:48:40 -0400 Message-ID: <010901c80126$41dd3420$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfabnRxPg9G64XgSUeMWJVP7VST/wmt5hBA X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: isms@ietf.org Subject: [Isms] RE: my review of: draft-ietf-isms-secshell-08.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > > Further I read: > > When this textual convention is used as a syntax of an > index object, there may be issues with the limit of 128 > sub-identifiers specified in SMIv2, STD 58. In this case, > the OBJECT-TYPE declaration MUST include a 'SIZE' clause > to limit the number of potential instance sub-identifiers." > > Mmm.. we do not normally enforce (i.e. MUST language) that a SIZE > clause must be used. We allo the DESCIRPTION clause to explain > that implementers must be aware and cater for OID limitations. > So do we really want that MUST language here? I changed this paragraph to say (copying from RFC4181): When this textual convention is used as a syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. It is RECOMMENDED that all MIB documents using this textual convention make explicit any limitations on index component lengths that management software must observe. This may be done either by including SIZE constraints on the index components or by specifying applicable constraints in the conceptual row DESCRIPTION clause or in the surrounding documentation. David Harrington dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 27 13:14:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IawwP-0000cq-Iy; Thu, 27 Sep 2007 13:14:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IawwM-0000HI-UW for isms@ietf.org; Thu, 27 Sep 2007 13:14:18 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iaww1-0008Hp-Gp for isms@ietf.org; Thu, 27 Sep 2007 13:13:57 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007092717135601300ha1pce>; Thu, 27 Sep 2007 17:13:56 +0000 From: "David Harrington" To: "'Wes Hardaker'" , References: Subject: RE: [Isms] barely a review: secshell-08 Date: Thu, 27 Sep 2007 13:13:51 -0400 Message-ID: <010a01c80129$c6ceaee0$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acfb1/sRkFHtGVqVSzubD6vcIRvZewlUUBGA X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Saturday, August 11, 2007 1:25 AM > To: isms@ietf.org > Subject: [Isms] barely a review: secshell-08 > > > These MIB objects SHOULD NOT be referenced in other documents > > That one kind of bothers me. Is this better: In keeping with the RFC 3411 design decision to use self-contained documents, this document defines the elements of procedure and associated MIB module objects needed for processing the Secure Shell Transport Model for SNMP. The MIB objects defined in this document SHOULD NOT be modified except by the elements of procedure defined in this document. This allows the Secure Shell Transport Model for SNMP to be designed and documented as independent and self-contained, having no direct impact on other modules, and this allows this module to be upgraded and supplemented as the need arises, and to move along the standards track on different time-lines from other modules. David Harrington dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 27 13:32:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaxE3-0002QU-7z; Thu, 27 Sep 2007 13:32:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaxE1-0000zm-9S for isms@ietf.org; Thu, 27 Sep 2007 13:32:33 -0400 Received: from sccrmhc15.comcast.net ([63.240.77.85]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaxDh-0000KA-MR for isms@ietf.org; Thu, 27 Sep 2007 13:32:13 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <200709271732130150062b3ue>; Thu, 27 Sep 2007 17:32:13 +0000 From: "David Harrington" To: , "'Wes Hardaker'" References: <20070911082459.GG16313@elstar.local> Subject: RE: [Isms] barely a review: secshell-08 Date: Thu, 27 Sep 2007 13:32:07 -0400 Message-ID: <010b01c8012c$542ad0a0$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20070911082459.GG16313@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf0TYJa8ursu3ZbTt+X2IOijlzu/wM3bNrw X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, September 11, 2007 4:25 AM > To: Wes Hardaker > Cc: isms@ietf.org > Subject: Re: [Isms] barely a review: secshell-08 > > On Fri, Aug 10, 2007 at 10:24:38PM -0700, Wes Hardaker wrote: > > > > 1.3: > > design decision*s* => design decision > > > > These MIB objects SHOULD NOT be referenced in other documents > > > > That one kind of bothers me. Generally in the IETF, > we encourage > > cross-reuse among MIB modules and here you're > specifically saying > > pretend this one doesn't exist if you're working on > something else. > > I'm not really fond of that notion. I do understand > the rational > > for wanting to do it, but I don't think you gain > anything in the > > end and you certainly loose the ability to do some > possible future > > reuse. > > I think this can be solved by simply deleting all text except the > first sentence: > > In keeping with the RFC 3411 design decisions to use self-contained > documents, this memo includes the elements of procedure plus > associated MIB objects which are needed for processing the Secure > Shell Transport Model for SNMP. > > The rest of the paragraph is trying to explain the motivation for the > RFC 3411 design decision but it may not really be needed to repeat > this in every SNMP document since section 1.5 of RFC 3411 explains > this well enough. > I agree the sentence in the "modularity" Introduction can be shortened. But the same paragraph in the MIB module itself tries to constrain future implementers from violating the modularity of this MIB module, and they may get the MIB module stripped of the surrounding text. I'm not quite satisfied with the wordings either. This particular MIB module has no writable objects, so at least we are not saying that a manager application should not change any values, but we are more or less constraining implementations, and I'm not sure we want to do that either. I guess the constraint is really for future protocol designs. So I guess we should simply remove the paragraph from the MIB module, and leave the first sentence only in the introduction. Does that sound reasonable? > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 27 17:08:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib0aR-0001HY-Ec; Thu, 27 Sep 2007 17:07:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib0aQ-0001DE-9H for isms@ietf.org; Thu, 27 Sep 2007 17:07:54 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ib0aC-0002PH-2X for isms@ietf.org; Thu, 27 Sep 2007 17:07:46 -0400 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 l8RL7Ppp026205; Thu, 27 Sep 2007 16:07:26 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 16:06:47 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 23:06:44 +0200 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: Thu, 27 Sep 2007 23:06:43 +0200 Message-ID: In-Reply-To: <010901c80126$41dd3420$6502a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: my review of: draft-ietf-isms-secshell-08.txt Thread-Index: AcfabnRxPg9G64XgSUeMWJVP7VST/wmt5hBAAAjRNNA= References: <010901c80126$41dd3420$6502a8c0@china.huawei.com> From: "Wijnen, Bert \(Bert\)" To: "David Harrington" , X-OriginalArrivalTime: 27 Sep 2007 21:06:44.0334 (UTC) FILETIME=[4EEBC0E0:01C8014A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: isms@ietf.org Subject: [Isms] RE: my review of: draft-ietf-isms-secshell-08.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Thanks. That addresses my concern Bert Wijnen =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Thursday, September 27, 2007 6:49 PM > To: Wijnen, Bert (Bert); jsalowey@cisco.com > Cc: isms@ietf.org > Subject: RE: my review of: draft-ietf-isms-secshell-08.txt >=20 > =20 >=20 > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > >=20 > > Further I read: > >=20 > > When this textual convention is used as a syntax of an > > index object, there may be issues with the limit of 128 > > sub-identifiers specified in SMIv2, STD 58. In this case, > > the OBJECT-TYPE declaration MUST include a 'SIZE' clause > > to limit the number of potential instance sub-identifiers." > >=20 > > Mmm.. we do not normally enforce (i.e. MUST language) that a SIZE > > clause must be used. We allo the DESCIRPTION clause to explain > > that implementers must be aware and cater for OID limitations. > > So do we really want that MUST language here? >=20 > I changed this paragraph to say (copying from RFC4181): >=20 > When this textual convention is used as a syntax of an > index object, there may be issues with the limit of 128 > sub-identifiers specified in SMIv2, STD 58. It is=20 > RECOMMENDED that all MIB documents using this textual=20 > convention make explicit any limitations on index > component lengths that management software must observe. =20 > This may be done either by including SIZE constraints on=20 > the index components or by specifying applicable=20 > constraints in the conceptual row DESCRIPTION clause or=20 > in the surrounding documentation. >=20 > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 28 04:46:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbBTc-0006AR-7K; Fri, 28 Sep 2007 04:45:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbBTa-000695-GI for isms@ietf.org; Fri, 28 Sep 2007 04:45:34 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbBTZ-0007hH-9s for isms@ietf.org; Fri, 28 Sep 2007 04:45:34 -0400 Received: from pc6 (1Cust90.tnt110.lnd4.gbr.da.uu.net [62.188.174.90]) by blaster.systems.pipex.net (Postfix) with SMTP id E0BCAE00028F; Fri, 28 Sep 2007 09:44:26 +0100 (BST) Message-ID: <003701c801a2$780851c0$0601a8c0@pc6> From: "tom.petch" To: , "David Harrington" References: <012701c7fa8e$f75b3c00$0601a8c0@pc6> <040601c7faea$7269dc20$6702a8c0@china.huawei.com> <20070920111811.GA27081@elstar.local> Subject: Re: [Isms] must and should in tmsm-10 Date: Fri, 28 Sep 2007 09:36:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: 'ISMS WG' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Apologies for the much delayed inline response Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "David Harrington" Cc: "'tom.petch'" ; "'ISMS WG'" Sent: Thursday, September 20, 2007 1:18 PM Subject: Re: [Isms] must and should in tmsm-10 > On Wed, Sep 19, 2007 at 02:25:23PM -0400, David Harrington wrote: > > > > -----Original Message----- > > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > > Sent: Wednesday, September 19, 2007 3:28 AM > > > To: j.schoenwaelder@jacobs-university.de > > > Cc: ISMS WG > > > Subject: [Isms] must and should in tmsm-10 > > > > > > Juergen > > > > > > I looked at tmsm-10 for the issues that I had raised; three > > > seem unresolved. > > > > > > In 3.2.1.2, it says > > > " If a message is secured using a secure transport layer, then the > > > Transport Model should provide the translation from the > > > authenticated > > > identity" > > > where I would like a must (probably better than MUST). The > > > arguments are well > > > rehearsed. No matter how clever those are who come after, I > > > cannot see a STM > > > working with a TSM unless this translation is made available > > > by the TM; any > > > other approach - eg putting it in the ASI or having the TSM > > > extract it for > > > itself - would require a further change to the architecture. > > > As I mentioned, I > > > have dry-run the architecture ASI, EoP etc for a range of > > > scenarios that might > > > occur, got stuck on this 'should' and spent ages wondering > > > what subtlety I was > > > missing, finally concluding that I wasn't; but if I got > > > stuck, others will too. > > > Jeff pointed out that it was not needed for STM+USM - true, > > > but the STM does not > > > know architecturally what SM this message will go to, that is > > > up to the MPP. > > > And the context of 3.2.1.2 for me is STM+TSM > > > And David does not like unnecessary MUSTs because they come > > > back to inhibit > > > future development. > > > (should the > > > title be changed from > > > 'Transport Subsystem and the RFC3411 Architecture'? - after > > > all, 3.2.1.1.1 is > > > 'USM and the RFC3411 Architecture'; probably too minor to be > > > concerned with). > > > > The text in the first two paragraphs of 3.2.1.1 provide the > > simplified overview that is really important. > > > > There have been multiple complaints about these lists and the > > comparisons. > > To make this simple, I will remove 3.2.1.1.1 and 3.2.1.2 and the last > > paragraph of 3.2.1.1, then we don't need to worry about whether the > > lists line up properly, or what we should title the lists. > > Speaking as technical contributor, I think that the processing steps > are actually useful to get an idea how things work. I am wondering, > however, whether this text perhaps be moved into the TSM document and > then the headlines would be "USM processing of incoming messages" and > "TSM processing of incoming messages". Right now, the problem seems to > be that the architectural extension is much more general and thus it > is kind of difficult to be concrete. The TSM document, however, can > easily be concret. So what about making this comparison an appendix of > the TSM document instead of deleting it completely? > Yes, I think that that would work very well; the information is worth having, in the right context. > > > Anyhow, you know all this, so enough (too much:-) said. > > > > > > But this raises a delectable irony with my second point. In > > > 5.2 it says > > > " Each Security Model that supports the tmStateReference cache > > SHOULD > > > pass a tmSameSession parameter in the tmStateReference cache for > > > outgoing messages to indicate whether the same session MUST be > > used > > > for the outgoing message as was used for the corresponding > > incoming > > > message." > > > > > > A dbh e-mail 25apr07 said > > > "The Transport Subsystem architecture document will reflect the > > SNMPv3 > > > WG's decision that **architecturally** this is a SHOULD. > > > The decision is security-model-dependent, and the Transport Security > > > Model will make it a MUST." > > > > > > I am still seeing that MUST; and when I look at tsm, I think > > > I see a SHOULD > > > (although I am looking at the previous tsm I-D, not the > > > revised tsm). And these > > > MUSTs do have a habit of constricting those who come after > > > us, who may come up > > > with a cleverer idea than us:-) > > > > s5.2 has a number of SHOULDs and a number of MUSTs. I am not sure > > which MUST you object to. > > > > p2 says if the response doesn't match the request, it SHOULD be > > discarded, BUT > > the decision is security-model-dependent, not architectural. > > A security model can REQUIRE this. (or not, depending on the security > > model) > > > > p4 says each transport model SHOULD include a session ID so the TM can > > determine whether the session is the same. (but an alternative > > approach for identifying a session is acceptable as well) > > > > p5 says the tmSameSession field should be supported in the cache, so a > > security model can indicate whether it is REQUIRED or not. (I changed > > the name of this in TSM, so there is currently a consistency issue > > with the name; I'll fix that in the next rev. In addition, I think the > > presence of this parameter needs to be transport/security > > model-independent, so if there is consensus, I will make this a MUST > > in the next rev.) > > > > p6 says **if** the security model said it is REQUIRED, and the session > > is not the same, then the transport model MUST discard the message. > > > > I don't see the inconsistency in MUST usage that you apparently see. > > My reading of the the text matches David's explanation and I am not > really sure where the problem is or how to improve things. Tom, can > you re-read the text and tell us precisely what you want to get > changed? > Ok, leave it as it is. The paragraph I was referring to is " Each Security Model that supports the tmStateReference cache SHOULD pass a tmSameSession parameter in the tmStateReference cache for outgoing messages to indicate whether the same session MUST be used for the outgoing message as was used for the corresponding incoming message." where as I said before, I understood an earlier e-mail of David to be saying that that MUST would become a SHOULD, but if you, Juergen, are happy, then leave it as is. > > > Finally, I was expecting to see a change around the two > > > paragraphs in s2 > > > starting > > > " This document defines a Transport Subsystem extension to > > > the RFC3411.." which, > > > as I have said before, I see as key paragraphs to the > > > understanding of the roles > > > of the three I-Ds. > > > > Section 1 is about the overall management framework, the SNMP > > architecure, and where this subsystem fits within the overall > > framework/architecture and where the ISMS documents "fit" within the > > whole set of SNMPv3-related documents. The description of the roles of > > the three isms IDs you proposed is in s1.2 "Where This Extension > > Fits", which is the section that discusses the roles of other > > documents that are needed to work with the subsystem. > > > > Section 2 is about motivation. The two paragraphs you refer to in > > section 2 discuss how the subsystem addresses the motivations - common > > security infrastructures, unified administrative security, use of > > existing security mechanisms. Section 2 is not about the roles of > > different documents and where they fit. > > > > If the WG really wants the discussion of how the docuemnnt fit > > together to be in the motivations section rather than in the section > > that talks about how the documents all fit together, I'll move it. > > Personally, I think the current organization makes more sense. > > Personally, I also think that section 1.2 is rather clear where the > pieces fit. If I would anything to explain this better, I would do so > directly before 1.3 by adding a sentence or extending that last > sentence before 1.3. > > Yes, adding a sentence to the end of s1.2 would be a good idea. I agree that it is clear for those of us who have followed isms but I do not think the explanation of why there are three I-Ds will be clear to others (and I seem to recall this having to be explained several times on this list). So I would add (stating the obvious) - the Transport Security Model provides a concrete implementation of the Security Subsystem, as an alternative to USM - the Transport Model enables the use of existing security mechanisms such as (TLS) [RFC4346] or SSH [RFC4251] - the Secure Shell Transport Model [I-D.ietf-isms-secshell] defines the such a use for SSH Tom Petch /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 28 14:08:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKFl-00083j-PN; Fri, 28 Sep 2007 14:07:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKFk-00081S-07 for isms@ietf.org; Fri, 28 Sep 2007 14:07:52 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbKFe-0000SB-Gs for isms@ietf.org; Fri, 28 Sep 2007 14:07:51 -0400 Received: from pc6 (1Cust34.tnt101.lnd4.gbr.da.uu.net [213.116.50.34]) by ranger.systems.pipex.net (Postfix) with SMTP id 4A138E00049F; Fri, 28 Sep 2007 19:07:30 +0100 (BST) Message-ID: <00a201c801f1$20c6ba60$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , References: <010801c80125$20960720$6502a8c0@china.huawei.com> Subject: Re: [Isms] SnmpSSHAddress Date: Fri, 28 Sep 2007 18:56:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -104.0 (---------------------------------------------------) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org ----- Original Message ----- From: "David Harrington" To: Sent: Thursday, September 27, 2007 6:40 PM Subject: [Isms] SnmpSSHAddress > Hi, > > Bert and Jeff raised questions about the format for IPv4/IPv6 > addresses and hostnames. Is the following acceptable? > > Is there an RFC that describes the textual representation of an IPv6 > address? RFC4291 s2.2 The ABNF for this is somewhere unexpected (which I will stumble across sometime). But note that this section does not cover the interface number, which has provoked discussion on URI because of the use of the percent character, nor the port number Tom Petch > > Bert pointed out that MIB addresses have been inconsistent - some use > '/' to separate the port nunber and others use ':'. Jeff pointed out > that using a colon makes it difficult to determine where an IPv6 > address ends and the port starts. Maybe we should use the ':' > separator for the hostname format, and the '/' separator for the IP > address formats to eliminate the ambiguity. RFC4181 has no guidance on > this point; are there other documents that provide guidance on the > separator character for hostnames and/or IP adddresses? > > SnmpSSHAddress ::= TEXTUAL-CONVENTION > DISPLAY-HINT "1a" > STATUS current > DESCRIPTION > "Represents either a hostname with a port number or an IP > address with a port number. > > The hostname must be encoded in ASCII, as specified in > RFC3490 (Internationalizing Domain Names in Applications) > followed by a colon ':' (ASCII character 0x3A) and a > decimal port number in ASCII. The name SHOULD be fully > qualified whenever possible. > > An IPv4 address must be a dotted decimal format followed > by a colon ':' (ASCII character 0x3A) and a decimal port > number in ASCII. > > An IPv6 address must be a colon separated format, > surrounded by brackets, followed by a colon ':' (ASCII > character 0x3A) and a decimal port number in ASCII. > > Values of this textual convention may not be directly useable > as transport-layer addressing information, and may require > runtime resolution. As such, applications that write them > must be prepared for handling errors if such values are > not supported, or cannot be resolved (if resolution occurs > at the time of the management operation). > > The DESCRIPTION clause of TransportAddress objects that may > have snmpSSHAddress values must fully describe how (and > when) such names are to be resolved to IP addresses and vice > versa. > > This textual convention SHOULD NOT be used directly in > object definitions since it restricts addresses to a > specific format. However, if it is used, it MAY be used > either on its own or in conjunction with > TransportAddressType or TransportDomain as a pair. > > When this textual convention is used as a syntax of an > index object, there may be issues with the limit of 128 > sub-identifiers specified in SMIv2, STD 58. In this case, > the OBJECT-TYPE declaration MUST include a 'SIZE' clause > to limit the number of potential instance sub-identifiers." > SYNTAX OCTET STRING (SIZE (1..255)) > > David Harrington > 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