From isms-bounces@lists.ietf.org Fri Sep 02 13:50:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBFfy-00082M-EC; Fri, 02 Sep 2005 13:50:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBFfw-00080l-FX for isms@megatron.ietf.org; Fri, 02 Sep 2005 13:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20218 for ; Fri, 2 Sep 2005 13:50:03 -0400 (EDT) Received: from hosting.revelstone.com ([66.36.242.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBFi5-0003qz-OP for isms@ietf.org; Fri, 02 Sep 2005 13:52:20 -0400 Received: from localhost ([127.0.0.1] helo=aud) by hosting.revelstone.com with smtp (Exim 4.50) id 1EBFfe-0005qm-Qr; Fri, 02 Sep 2005 13:49:46 -0400 Date: Fri, 2 Sep 2005 13:49:47 -0400 From: Robert Story To: ietfdbh@comcast.net Subject: Re: [Isms] SSH vs SNMP concepts Message-ID: <20050902134947.4802a824@aud> In-Reply-To: <200508301425.KAA16003@ietf.org> References: <010601c5ad17$7cf03fe0$7f1afea9@oemcomputer> <200508301425.KAA16003@ietf.org> X-Mailer: Sylpheed-Claws 1.9.13 (GTK+ 2.4.14; powerpc-yellowdog-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Tue, 30 Aug 2005 10:24:59 -0400 David wrote: DBH> The question asked was about whether SSH had a mechanism that would DBH> allow us to mirror a specific SNMP capability - "If multiple SSH DBH> servers or multiple SSH clients exist on the DBH> same host, how would one differentiate them? Is this standardized?" Peeking at the OpenSSH sshd man page, it looks like the host key and port can both be specified on the command line. However, when the client stores known host keys, the port is not stored, so the client will cry foul when connecting to a second server on the same host with a different host key. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 02 15:20:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBH4z-0006rC-IV; Fri, 02 Sep 2005 15:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBH4y-0006pk-3i for isms@megatron.ietf.org; Fri, 02 Sep 2005 15:20:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25423 for ; Fri, 2 Sep 2005 15:19:58 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBH7A-0006tU-0y for isms@ietf.org; Fri, 02 Sep 2005 15:22:17 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j82JJgBT007204; Fri, 2 Sep 2005 12:19:42 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j82JJa1u018197; Fri, 2 Sep 2005 12:19:36 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j82JJatb018194; Fri, 2 Sep 2005 12:19:36 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 2 Sep 2005 12:19:36 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Robert Story Subject: Re: [Isms] SSH vs SNMP concepts In-Reply-To: <20050902134947.4802a824@aud> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, Thanks for reexamining the MAN pages. Are you saying that the client can specify the host key on the command line, or just the server. If client, sorry I missed that option. Also, I didn't spot such an option on other SSH implementations such as putty and teraterm (with the ttssh addin). Both allow you to specify the port to use on connect, so you can communicate with multiple SSH servers on the same IP address (each with a different port). I couldn't figure out what DBH meant by "differentiating SSH clients", and sent him a private message for which I haven't yet gotten a response. On Fri, 2 Sep 2005, Robert Story wrote: > On Tue, 30 Aug 2005 10:24:59 -0400 David wrote: > DBH> The question asked was about whether SSH had a mechanism that would > DBH> allow us to mirror a specific SNMP capability - "If multiple SSH > DBH> servers or multiple SSH clients exist on the > DBH> same host, how would one differentiate them? Is this standardized?" > > Peeking at the OpenSSH sshd man page, it looks like the host key and port can > both be specified on the command line. However, when the client stores known > host keys, the port is not stored, so the client will cry foul when connecting > to a second server on the same host with a different host key. > Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Sep 03 17:46:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBfqJ-0002nS-6c; Sat, 03 Sep 2005 17:46:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBfqG-0002mM-Jf for isms@megatron.ietf.org; Sat, 03 Sep 2005 17:46:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26160 for ; Sat, 3 Sep 2005 17:46:26 -0400 (EDT) Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBfsg-0005wr-QI for isms@ietf.org; Sat, 03 Sep 2005 17:49:00 -0400 Received: from h-68-166-189-209.snvacaid.dynamic.covad.net ([68.166.189.209] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EBfq7-0006em-00 for isms@ietf.org; Sat, 03 Sep 2005 17:46:20 -0400 Message-ID: <00f501c5b0d1$378d7cc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <010601c5ad17$7cf03fe0$7f1afea9@oemcomputer><200508301425.KAA16003@ietf.org> <20050902134947.4802a824@aud> Subject: Re: [Isms] SSH vs SNMP concepts Date: Sat, 3 Sep 2005 14:48:14 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 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: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Robert Story" > To: > Cc: > Sent: Friday, September 02, 2005 10:49 AM > Subject: Re: [Isms] SSH vs SNMP concepts > > On Tue, 30 Aug 2005 10:24:59 -0400 David wrote: > DBH> The question asked was about whether SSH had a mechanism that would > DBH> allow us to mirror a specific SNMP capability - "If multiple SSH > DBH> servers or multiple SSH clients exist on the > DBH> same host, how would one differentiate them? Is this standardized?" > > Peeking at the OpenSSH sshd man page, it looks like the host key and port can > both be specified on the command line. However, when the client stores known > host keys, the port is not stored, so the client will cry foul when connecting > to a second server on the same host with a different host key. ... This sounds like an implementation problem, rather than a protocol issue. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Sep 03 20:54:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBilr-0000oP-RS; Sat, 03 Sep 2005 20:54:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBilq-0000oK-Tu for isms@megatron.ietf.org; Sat, 03 Sep 2005 20:54:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02753 for ; Sat, 3 Sep 2005 20:54:05 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBioI-000250-Gg for isms@ietf.org; Sat, 03 Sep 2005 20:56:39 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j840rnBT032254; Sat, 3 Sep 2005 17:53:49 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j840rhKj030147; Sat, 3 Sep 2005 17:53:43 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j840rghG030141; Sat, 3 Sep 2005 17:53:42 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Sat, 3 Sep 2005 17:53:42 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Randy Presuhn Subject: Re: [Isms] SSH vs SNMP concepts In-Reply-To: <00f501c5b0d1$378d7cc0$7f1afea9@oemcomputer> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, Randy, yes it does look like an "implementation" rather than a "protocol" limitation. However, the goal of the WG is to use existing security infrastructure. The ssh_hosts file on client machines is part of a client's existing security infrastructure. So, given that limitation (no port, that is, only a network address), how would you solve the problem of supporting multiple independent SNMP agents on a system? Well, one pretty straight forward approach is what has been done to support v1 managers, but one the other end. That is 1) use SNMPv3/ISMS-SSH between a command generator (management app) and command responder (agent) which are located on different systems. 2) have the SNMPv3/ISMS-SSH agent serve as a proxy (or encapsulating) agent to the independent SNNPv1/v2c/v3USM agents via a loopback address. On Sat, 3 Sep 2005, Randy Presuhn wrote > Hi - > > > From: "Robert Story" > > To: > > Cc: > > Sent: Friday, September 02, 2005 10:49 AM > > Subject: Re: [Isms] SSH vs SNMP concepts > > > > > On Tue, 30 Aug 2005 10:24:59 -0400 David wrote: > > DBH> The question asked was about whether SSH had a mechanism that would > > DBH> allow us to mirror a specific SNMP capability - "If multiple SSH > > DBH> servers or multiple SSH clients exist on the > > DBH> same host, how would one differentiate them? Is this standardized?" > > > > Peeking at the OpenSSH sshd man page, it looks like the host key and port can > > both be specified on the command line. However, when the client stores known > > host keys, the port is not stored, so the client will cry foul when connecting > > to a second server on the same host with a different host key. > ... > > This sounds like an implementation problem, rather than a protocol issue. > > Randy Enjoy, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 06 09:02:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECd60-00043m-Fh; Tue, 06 Sep 2005 09:02:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECd5y-00043h-OV for isms@megatron.ietf.org; Tue, 06 Sep 2005 09:02:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25999 for ; Tue, 6 Sep 2005 09:02:37 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECd8w-0004Y9-0U for isms@ietf.org; Tue, 06 Sep 2005 09:05:43 -0400 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j86D0Eg20976; Tue, 6 Sep 2005 09:00:14 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] SSH vs SNMP concepts Date: Tue, 6 Sep 2005 09:02:15 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D50467818D@zcarhxm2.corp.nortel.com> Thread-Topic: [Isms] SSH vs SNMP concepts Thread-Index: AcWw62GZzgAq+VKARCmFgnxv7oh69AB91DIQ From: "Martin Soukup" To: "David T. Perkins" , "Randy Presuhn" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org In the case of OpenSSH, at least, multiple keys can also be specified. >From the man pages for "SSH_KNOWN_HOSTS FILE FORMAT": "When performing host authentication, authentication is accepted if any matching line has the proper key. It is thus permissible (but not recom- mended) to have several lines or different host keys for the same names. This will inevitably happen when short forms of host names from different domains are put in the file." E.g.: Ismsagent PUB-KEY1 Ismsagent PUB-KEY2 Alternatively, an implementation could require hosts with multiple agents to have multiple names, but that sounds messier. Martin. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David T. Perkins Sent: Saturday, September 03, 2005 8:54 PM To: Randy Presuhn Cc: isms@ietf.org Subject: Re: [Isms] SSH vs SNMP concepts HI, Randy, yes it does look like an "implementation" rather than a "protocol" limitation. However, the goal of the WG is to use existing security infrastructure. The ssh_hosts file on client machines is part of a client's existing security infrastructure. So, given that limitation (no port, that is, only a network address), how would you solve the problem of supporting multiple independent SNMP agents on a system? Well, one pretty straight forward approach is what has been done to support v1 managers, but one the other end. That is=20 1) use SNMPv3/ISMS-SSH between a command generator (management app) and command responder (agent) which are located on different systems. 2) have the SNMPv3/ISMS-SSH agent serve as a proxy (or encapsulating) agent to the independent SNNPv1/v2c/v3USM agents via a loopback address. On Sat, 3 Sep 2005, Randy Presuhn wrote > Hi - >=20 > > From: "Robert Story" > > To: > > Cc: > > Sent: Friday, September 02, 2005 10:49 AM > > Subject: Re: [Isms] SSH vs SNMP concepts > > >=20 > > On Tue, 30 Aug 2005 10:24:59 -0400 David wrote: > > DBH> The question asked was about whether SSH had a mechanism that=20 > > DBH> would allow us to mirror a specific SNMP capability - "If=20 > > DBH> multiple SSH servers or multiple SSH clients exist on the same=20 > > DBH> host, how would one differentiate them? Is this standardized?" > > > > Peeking at the OpenSSH sshd man page, it looks like the host key and > > port can both be specified on the command line. However, when the=20 > > client stores known host keys, the port is not stored, so the client > > will cry foul when connecting to a second server on the same host=20 > > with a different host key. > ... >=20 > This sounds like an implementation problem, rather than a protocol=20 > issue. >=20 > Randy Enjoy, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 06 09:52:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECdsd-0003ya-Eb; Tue, 06 Sep 2005 09:52:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECdsc-0003yV-Ic for isms@megatron.ietf.org; Tue, 06 Sep 2005 09:52:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28096 for ; Tue, 6 Sep 2005 09:52:53 -0400 (EDT) Received: from [69.25.196.185] (helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECdva-0005qn-93 for isms@ietf.org; Tue, 06 Sep 2005 09:55:59 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 80CFAE0049; Tue, 6 Sep 2005 09:52:48 -0400 (EDT) To: isms@ietf.org From: Sam Hartman Date: Tue, 06 Sep 2005 09:52:48 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Isms] Charter approved for external review X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi. I wanted to let you all know that the chairs submitted the charter for consideration by the IESG last week. It was approved for external review with one typo correction: the charter posted on this list claimed that the work to define local account mappings for ISMS would happen in the radext working group. The chairs intended to suggest that the work for RADIUS attribute definitions might happen n RADEXT, not the local account work. The next step is that the IESG secretary will send out the charter to the ietf-announce and new-work lists to solicit external comments. Depending on what comes up during this review period, the charter could be up for approval as soon as the September 15th telechat. Thanks for your help in getting to this point. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 06 12:45:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECgZg-0007vK-51; Tue, 06 Sep 2005 12:45:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECgZe-0007vC-5C for isms@megatron.ietf.org; Tue, 06 Sep 2005 12:45:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07411 for ; Tue, 6 Sep 2005 12:45:27 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECgcd-00023c-GT for isms@ietf.org; Tue, 06 Sep 2005 12:48:36 -0400 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 668011BAC4D; Tue, 6 Sep 2005 18:45:02 +0200 (CEST) Date: Tue, 06 Sep 2005 18:45:00 +0200 From: Juergen Quittek To: Sam Hartman , isms@ietf.org Subject: Re: [Isms] Charter approved for external review Message-ID: <660D3D4BD6F3DFD3FFD9D724@[10.1.1.171]> In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org --On 9/6/2005 3:52 PM +0200 Sam Hartman wrote: > > Hi. > > I wanted to let you all know that the chairs submitted the charter for > consideration by the IESG last week. > > > It was approved for external review with one typo correction: the > charter posted on this list claimed that the work to define local > account mappings for ISMS would happen in the radext working group. > The chairs intended to suggest that the work for RADIUS attribute > definitions might happen n RADEXT, not the local account work. This was my fault. When applying the changes suggested by DBH I appended the phrase "This item might be shared with the RADEXT WG." to the wrong work item. Sam, thanks for catching this. Another modification applied by Sam after he received our submission was removing targets from the charter that are to be achieved by the RADEXT WG. We have to discuss with the RADEXT WG how we can work on these issues jointly, once the charter is approved. > The next step is that the IESG secretary will send out the charter to > the ietf-announce and new-work lists to solicit external comments. > > Depending on what comes up during this review period, the charter > could be up for approval as soon as the September 15th telechat. Thanks, Juergen > Thanks for your help in getting to this point. > > --Sam > > > _______________________________________________ > 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 06 13:19:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECh6I-00049z-4T; Tue, 06 Sep 2005 13:19:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECh6G-00049u-Sw for isms@megatron.ietf.org; Tue, 06 Sep 2005 13:19:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08641 for ; Tue, 6 Sep 2005 13:19:10 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECh9G-0002r2-MS for isms@ietf.org; Tue, 06 Sep 2005 13:22:19 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 06 Sep 2005 10:19:03 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j86HIsZ1002650; Tue, 6 Sep 2005 10:18:54 -0700 (PDT) Received: from [212.254.247.4] (ams-clip-vpn-dhcp4272.cisco.com [10.61.80.175]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j86HEEo2028748; Tue, 6 Sep 2005 10:14:15 -0700 Message-ID: <431DCF80.6000402@cisco.com> Date: Tue, 06 Sep 2005 19:18:56 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman Subject: Re: [Isms] Charter approved for external review References: In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=388; t=1126026856; x=1126459056; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20Charter=20approved=20for=20external=20review| From:Eliot=20Lear=20| Date:Tue,=2006=20Sep=202005=2019=3A18=3A56=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=UcfCFC8d1VXbPGtGo8afawSZ94djNzecK14UIAI6yb/X0pcWGUTiEzhM/k7uuBc9wVJf/wRl pwk4Fq3e4WDmrqQZ6PZNcD+HUcuEPTcLgLwcDfCZJELQBL3zTaE/tfYAIHQ8+GU5F2ZcNw33j4H btJ4Rxpg6Kw2iPtnQUqBWtrg= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Sam, > Depending on what comes up during this review period, the charter > could be up for approval as soon as the September 15th telechat. I will send out a message today. However, I am not going to be around for 5 of the 8 days that this external review will last for, and will not be able to respond to messages in that time. I ask that you put over the discussion for an additional week (which also puts it more in line for the length of time of a normal IETF-wide review). Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 06 14:07:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EChrQ-0004GI-A6; Tue, 06 Sep 2005 14:07:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EChrP-0004GA-MI for isms@megatron.ietf.org; Tue, 06 Sep 2005 14:07:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10901 for ; Tue, 6 Sep 2005 14:07:54 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EChuN-0004Bf-Vi for isms@ietf.org; Tue, 06 Sep 2005 14:11:03 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 850F4E0049; Tue, 6 Sep 2005 14:07:46 -0400 (EDT) To: Eliot Lear Subject: Re: [Isms] Charter approved for external review References: <431DCF80.6000402@cisco.com> From: Sam Hartman Date: Tue, 06 Sep 2005 14:07:46 -0400 In-Reply-To: <431DCF80.6000402@cisco.com> (Eliot Lear's message of "Tue, 06 Sep 2005 19:18:56 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Eliot" == Eliot Lear writes: Eliot> Sam, >> Depending on what comes up during this review period, the >> charter could be up for approval as soon as the September 15th >> telechat. Eliot> I will send out a message today. However, I am not going Eliot> to be around for 5 of the 8 days that this external review Eliot> will last for, and will not be able to respond to messages Eliot> in that time. I ask that you put over the discussion for Eliot> an additional week (which also puts it more in line for the Eliot> length of time of a normal IETF-wide review). I am not sure I can do that although I could certainly extend by two weeks. Let's see how much interest your message gets. If there is an active discussion going on and you haven't been around for a significant part of it, then it is probably desirable to delay the chartering. If you are the only one who expresses interest in the change, I'm reluctant to delay the process. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 06 14:40:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECiMm-0001Mc-MY; Tue, 06 Sep 2005 14:40:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECiMk-0001MU-Tn for isms@megatron.ietf.org; Tue, 06 Sep 2005 14:40:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12539 for ; Tue, 6 Sep 2005 14:40:17 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECiPm-00055G-4n for isms@ietf.org; Tue, 06 Sep 2005 14:43:26 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 0D099E0049; Tue, 6 Sep 2005 14:40:15 -0400 (EDT) To: isms@ietf.org From: Sam Hartman Date: Tue, 06 Sep 2005 14:40:15 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: Subject: [Isms] [Eliot Lear] ISMS working group and charter problems X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org --=-=-= Discussion should happen on the ietf list, but here is a heads up. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Tue, 06 Sep 2005 13:41:38 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 160C51383C for ; Tue, 6 Sep 2005 13:41:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EChNm-0006qR-Kf; Tue, 06 Sep 2005 13:37:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EChNk-0006pI-IK; Tue, 06 Sep 2005 13:37:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09326; Tue, 6 Sep 2005 13:37:15 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EChQl-0003JI-68; Tue, 06 Sep 2005 13:40:23 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 06 Sep 2005 10:37:07 -0700 X-IronPort-AV: i="3.96,172,1122879600"; d="scan'208"; a="658442805:sNHT34267274" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j86Hb40J009770; Tue, 6 Sep 2005 10:37:05 -0700 (PDT) Received: from [212.254.247.4] (ams-clip-vpn-dhcp4272.cisco.com [10.61.80.175]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j86HWIqk028993; Tue, 6 Sep 2005 10:32:19 -0700 Message-ID: <431DD3BD.9090108@cisco.com> Date: Tue, 06 Sep 2005 19:37:01 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en To: IETF Discussion , nanog@merit.edu, iesg@ietf.org X-Enigmail-Version: 0.92.0.0 DKIM-Signature: a=rsa-sha1; q=dns; l=5505; t=1126027941; x=1126460141; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:ISMS=20working=20group=20and=20charter=20problems| From:Eliot=20Lear=20| Date:Tue,=2006=20Sep=202005=2019=3A37=3A01=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=fOtvHs+uPqaj8OkdPAQywXO3UfTHVkYRnq7qn5kRd/+u2D7YxCQVfWEAMqezTkKR3yG/JVnG 7Hpgjg+6VriPHZo5kCRqr0jahS+SDVAx12FNFCEKXM72QJ/LdmYGaIyt4SSIDIE2aQKKtwtO3hy PfU9eaUqOqldwKOMYT+6TRjI= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: Subject: ISMS working group and charter problems X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on solipsist-nation.suchdamage.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.0.2 MIME-Version: 1.0 Dear Communities, I need your help to correct for an impending mistake by the ISMS working group in the IETF. Short Version The ISMS working group is chartered to find a way for SNMP to make use of existing authentication mechanisms. The current proposed approaches will make use of TCP. I seek a change to the proposed ISMS charter that requests the working group pay attention to firewall and NAT concerns. The current envisioned approach will not work through firewalls and NATs. I specifically request that the working group be directed to consider "Call Home" functionality as a non-exclusive alternative, where the managed device contacts the manager much the same way as your PC contacts Microsoft, Apple, etc for updates. The addition of call home functionality won't represent a major architectural change to SNMP. The major architectural change (if there is one) will be the use of SSH at all and the use of TCP. If you agree with me, I ask that you respond to this note including the ietf@ietf.org and iesg@ietf.org so indicating. Reasoning Long gone are the days when the IETF can simply ignore firewalls, as this working group is currently planning. An approach that demonstrates robustness in the face of firewalls is required. Long Version SNMP version 3 has a unique authentication mechanism that does not easily integrate with other AAA systems such as radius or kerberos. After many years of complaints and lack of deployment of SNMPv3, a working group called ISMS was chartered last year to address this problem. At IETF 63 the working group decided to move forward with an approach based on SSH. As you all know, SSH is TCP-based. This represents a substantial change for SNMP. It also represents a substantial opportunity to extend manageability through firewalls. Currently, if you want to manage devices with SNMP through firewalls you must either have the firewall run an application layer gateway or you must poke a hole in the firewall based on UDP ports. If you do not control the network element, the network manager, AND the firewall, you assuredly have no hope of getting SNMP through. Even if you DO control the firewall, configuration of authorized address mappings may make it prohibitively difficult to allow management protocols through, especially in the face of dynamic address assignment mechanisms such as DHCP and PPP. Because we now are considering a TCP-based approach we have the opportunity to fix this huge problem. Why is this important? Firewalls exist today throughout our infrastructure. There's a good chance you have a simple one at home. Indeed firewalls exist between departments within enterprises. As companies add services and functions onto the Internet their ability to manage these services with SNMP deteriorates, requiring the need for expensive custom solutions and out of band management. Furthermore, many telcos today offer managed services, where they manage enterprise and consumer devices (routers, switches, etc). The whole concept of an enterprise network has, if you will, become virtualized. Today SNMP does not offer any joy to those who want to build a unified management system. More and more voice over ip (VoIP) has gained acceptance in the market place. However, the ability to debug end points real time is limited. Wouldn't it be nice for a manager to query a phone to determine how many data packets it thinks it has sent to a far end and then follow that stream to determine who is dropping? In order to accomplish this task, the manager has to have access to a phone which, if remote, may well be sitting behind a firewall such as the one you have at home. Furthermore, if the phone wants to send a notification to a manager, it too is likely to reside behind a firewall. Networks are certainly not the only functions to be managed. One could easily imagine power management services making use of standard MIBs as well as enterprise MIBs to handle capacity planning as well as dispatch in the face of live problems. What is currently envisioned by ISMS? What is currently being discussed is the traditional model, where if you want to request information you open up an SSH connection and make an SNMP query on top of it once you've authenticated. If the managed device resides behind a firewall, you lose. Worse, the currently envisioned solution calls for a separate connection to be opened to send notifications (traps). This time, if the network management station resides behind you lose again. What this means is that if there exists a firewall anywhere between the firewall and the management station, the currently proposed solution will fail. The astute will note that this approach looks a lot like old fashion FTP and will break just in just the same way. What is needed? I propose a flexible standard mechanism where either the device or the manager can be configured to initiate a connection, and that notifications occur either across the same TCP stream, when it exists. For instance, if in the classic case of a manager connecting to the element the manager requests the "snmp-request" ssh service, we also simply allow for the device to also initiate a connection but instead ask for the "snmp-turn" service (with all due credit to the authors of SMTP who first anticipated this problem over 20 years ago!). The same for notifications. This "-turn" approach is sometimes referred to as "Call Home" (CH) functionality. CH has an added advantage as well. Many devices come and go from the network, and it is not reasonable, scalable, or cost effective to poll such devices if they are not there. CH provides a natural discovery mechanism for such devices because they initiate request for management. This proposal does NOT represent a dramatic architectural change to SNMP. The dramatic architectural change will be the use of SSH at all, and not who initiates the connection. What I'm asking you to do The good news here is that all you have to do is drop the IETF and the IESG a note, saying you want to a solution. This is one of those times when you don't even need to fix it yourself. Please reply to this message, CCing the iesg@ietf.org and ietf@ietf.org indicating that you agree that ISMS should not miss the opportunity now take into account firewalls. If you do nothing, the problem will probably be ignored by ISMS. SNMP will continue to serve the needs it serves today, but likely no more. Proprietary and competing standards approaches will continue to be developed. Multiple standards in this space would be a waste of effort on the part of implementors and operators alike. Don't let this happen! Eliot _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --=-=-= 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 --=-=-=-- From isms-bounces@lists.ietf.org Wed Sep 07 10:47:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED1DI-0000vR-OP; Wed, 07 Sep 2005 10:47:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED1DG-0000uf-IG for isms@megatron.ietf.org; Wed, 07 Sep 2005 10:47:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24099 for ; Wed, 7 Sep 2005 10:47:44 -0400 (EDT) Message-Id: <200509071447.KAA24099@ietf.org> Received: from rwcrmhc13.comcast.net ([216.148.227.118] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED1GO-0007gi-Nl for isms@ietf.org; Wed, 07 Sep 2005 10:51:04 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <2005090714472201500j0ksge>; Wed, 7 Sep 2005 14:47:22 +0000 From: "David B Harrington" To: Date: Wed, 7 Sep 2005 10:47:20 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_04FD_01C5B399.85FB3C10" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWzuwxpIjZ+o4LMSSmms8XWqnjFlA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: ded1d986fdc82ac23092f3330fd9e841 Cc: Subject: [Isms] Draft-harrington-isms-SecShell-00.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_04FD_01C5B399.85FB3C10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have submitted the attached draft for -00- publication. I have published it primarily so the WG can see that progress is being made on the document. The current document is raw and missing many parts and some questioins have already been answered but are not reflected here. Nevertheless, the document should be helpful to organize the work effort, and focus discussions on various issues that need to be addressed by an SSH-based security model. It can also be used to understand some aspects of the USM approach that may not be needed with an SSH (or any TMSM) approach. Contributed text is welcome, especially for the [todo] sections. David Harrington dbharrington@comcast.net ------=_NextPart_000_04FD_01C5B399.85FB3C10 Content-Type: text/plain; name="draft-harrington-isms-SecShell-00-c.txt" Content-Disposition: attachment; filename="draft-harrington-isms-SecShell-00-c.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Harrington Internet-Draft Effective Software Expires: March 6, 2006 J. Schoenwaelder International University Bremen J. Salowey Cisco Systems September 2, 2005 Secure Shell Security Model for SNMP draft-harrington-isms-SecShell-00.txt 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 6, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo describes a Security Model for the Simple Network Management Protocol, using the Secure Shell protocol within a Transport Mapping. Harrington, et al. Expires March 6, 2006 [Page 1] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 The Internet-Standard Management Framework . . . . . . . . 6 1.3 The Secure Shell Protocol . . . . . . . . . . . . . . . . 6 1.4 Constraints . . . . . . . . . . . . . . . . . . . . . . . 7 1.5 Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 2. How SSHSM Fits into the TMSM Architecture . . . . . . . . . . 7 2.1 Security Capabilities of this Model . . . . . . . . . . . 8 2.1.1 Threats . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2 Sessions . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.3 Authentication Protocol . . . . . . . . . . . . . . . 10 2.1.4 Privacy Protocol . . . . . . . . . . . . . . . . . . . 11 2.1.5 Protection against Message Replay, Delay and Redirection . . . . . . . . . . . . . . . . . . . . . 11 2.1.6 [todo] Security Protocol Requirements . . . . . . . . 11 2.2 Security Parameter Passing Requirement . . . . . . . . . . 13 2.3 Requirements for Notifications . . . . . . . . . . . . . . 14 2.4 Scenario Diagrams . . . . . . . . . . . . . . . . . . . . 14 2.4.1 Command Generator or Notification Originator . . . . . 14 2.4.2 Command Responder . . . . . . . . . . . . . . . . . . 15 2.5 Abstract Service Interfaces . . . . . . . . . . . . . . . 16 3. RFC 3411 Abstract Service Interfaces . . . . . . . . . . . . . 17 3.1 Public Abstract Service Interfaces . . . . . . . . . . . . 17 3.1.1 Public ASIs for Outgoing Messages . . . . . . . . . . 17 3.1.2 Public ASIs for Incoming Messages . . . . . . . . . . 19 3.2 Private Abstract Service Interfaces . . . . . . . . . . . 20 4. SNMP Messages Using this Security Model . . . . . . . . . . . 22 4.1 SNMPv1 and SNMPv2c Messages Using this Security Model . . 22 4.2 SNMPv3 Messages Using this Security Model . . . . . . . . 23 4.2.1 msgGlobalData . . . . . . . . . . . . . . . . . . . . 25 4.3 Passing Security Parameters . . . . . . . . . . . . . . . 26 4.3.1 Transport Session Parameters . . . . . . . . . . . . . 27 4.3.2 [todo] Using Local Accounts to Authenticate Users . . 28 4.3.3 [todo] Using RADIUS Accounts to Authenticate Users . . 28 4.3.4 securityStateReference for SSHSM . . . . . . . . . . . 28 4.4 MIB Module for SSH Security Model . . . . . . . . . . . . 28 4.5 [todo] Notifications . . . . . . . . . . . . . . . . . . . 28 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 29 5.1 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 29 5.2 Establishing a Session . . . . . . . . . . . . . . . . . . 29 5.3 Generating an Outgoing SNMP Message . . . . . . . . . . . 31 5.4 Sending an Outgoing SNMP Message to the Network . . . . . 33 5.5 [todo] Prepare Data Elements from an Incoming SNMP Message . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.6 Processing an Incoming SNMP Message . . . . . . . . . . . 34 6. MIB module definition . . . . . . . . . . . . . . . . . . . . 34 Harrington, et al. Expires March 6, 2006 [Page 2] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.1 Normative References . . . . . . . . . . . . . . . . . . . 37 10.2 Informative References . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39 A. Change Log from the first revision of -00- . . . . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . . 41 Harrington, et al. Expires March 6, 2006 [Page 3] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 1. Introduction This memo describes a Security Model for the Simple Network Management Protocol, using the Secure Shell protocol within a Transport Mapping. It is important to understand the SNMP architecture and the terminology of the architecture to understand where the Security Model described in this memo fits into the architecture and interacts with other subsystems within the architecture. The reader is expected to have read and understood the description of the SNMP architecture, as defined in [RFC3411],and the "Transport Mapping Security Model (TMSM) for the Simple Network Management Protocol" architecture extension defined in [TMSM], which enables the use of external "lower layer" protocols to provide message security, tied into the SNMP architecture through the transport mapping subsystem. One such external protocol is the Secure Shell protocol [SSHArch]. This memo describes the Secure Shell Security Model for SNMP, a specific SNMP security model to be used within the SNMP Architecture, to provide authentication, encryption, and integrity checking of SNMP messages. This memo 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 Secure Shell Security Model for SNMP. 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 Security Model for SNMP. These MIB objects should not be referenced in other documents. This allows the Secure Shell Security Model for SNMP 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. 1.1 Motivation Version 3 of the Simple Network Management Protocol (SNMPv3) added security to the previous versions of the protocol. The User Security Model (USM) [RFC3414] was designed to be independent of other existing security infrastructures, to ensure it could function when Harrington, et al. Expires March 6, 2006 [Page 4] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 third party authentication services were not available, such as in a broken network. As a result, USM typically utilizes a separate user and key management infrastructure. Operators have reported that deploying another user and key management infrastructure in order to use SNMPv3 is a reason for not deploying SNMPv3 at this point in time. This memo describes a security model that will make use of the existing and commonly deployed Secure Shell security infrastructure. It is designed to meet the security and operational needs of network administrators, maximize useability 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. The work will include the ability for the SSH client to authenticate the SSH server, and for the SSH server to authenticate the SSH client. [todo] A large portion of SSH deals actually with authenticating the SSH server. It seems like this should be discussed as it should be important. How does this fit in versus user authentication? Do we do both server-auth and then user-auth? The work will include the ability to use any of the user authentication methods described in "SSH Authentication Protocol" [SSHAuth] - public key, password, and host-based. Local accounts may be supported through the use of the public key, host-based or password based mechanisms. The password based mechanism allows for integration with deployed password infrastructure such as AAA servers using the RADIUS protocol [RFC2865]. In the future it should also be able to take advantage of other defined authentication mechanism such as those defined in [gsskeyex] which will allow for user authentication mechanisms which support different security infrastructures and provide security properties. It is desirable to use mechanisms that could unify the approach for administrative security for SNMPv3 and CLI and other management interfaces. The use of security services provided by Secure Shell is the approach commonly used for the CLI, and is the approach being adopted for use with NETCONF [Netconf]. Similar to NETCONF over SSH [NetconfSSH], this memo describes a method for invoking and running the SNMP protocol within a Secure Shell (SSH) session as an SSH subsystem. This memo defines how SNMP can be used within a Secure Shell (SSH) session, using the SSH connection protocol [SSHConnect] over the SSH transport protocol [SSHTrans], using SSH user-auth [SSHAuth]for authentication. Harrington, et al. Expires March 6, 2006 [Page 5] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 There are a number of challenges to be addressed to map Secure Shell authentication method parameters into the SNMP architecture so that SNMP continues to work without any surprises. These are discussed in detail below. Some points requiring further WG research and discussion are identified by [todo] markers in the text. 1.2 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.3 The Secure Shell Protocol SSH is a protocol for secure remote login and other secure network services over an insecure network. It consists of three major components: o The Transport Layer Protocol [[SSHTrans] provides server authentication, confidentiality, and integrity. It may optionally also provide compression. The transport layer will typically be run over a TCP/IP connection, but might also be used on top of any other reliable data stream. o The User Authentication Protocol [SSHAuth] authenticates the client-side user to the server. It runs over the transport layer protocol. o The Connection Protocol [SSHConnect] multiplexes the encrypted tunnel into several logical channels. It runs over the user authentication protocol. The client sends a service request once a secure transport layer connection has been established. A second service request is sent after user authentication is complete. This allows new protocols to be defined and coexist with the protocols listed above. The connection protocol provides channels that can be used for a wide range of purposes. Standard methods are provided for setting up secure interactive shell sessions and for forwarding ("tunneling") arbitrary TCP/IP ports and X11 connections. Harrington, et al. Expires March 6, 2006 [Page 6] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 1.4 Constraints The design of this SNMP Security Model is also influenced by the following constraints: 1. When the requirements of effective management in times of network stress are inconsistent with those of security, the design of this model gives preference to the former. 2. In times of network stress, neither the security protocol nor its underlying security mechanisms should depend upon the ready availability of other network services (e.g., Network Time Protocol (NTP) or AAA protocols). 3. 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. 4. It may not be possible for the security model to determine when the network is under stress. 5. A security mechanism should entail no changes to the basic SNMP network management philosophy. 1.5 Conventions The terms "manager" and "agent" are not used in this document, because in the RFC 3411 architecture, all 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 Generator, Notification Rewsponder, and Proxy Forwarder are used. See "SNMP Applications" [RFC3413] for further information. Throughout this document, the terms "client" and "server" are used to refer to the two ends of the SSH transport connection. The client actively opens the SSH connection, and the server passively listens for the incoming SSH connection. Either entity may act as client or as server, as discussed further below. 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]. 2. How SSHSM Fits into the TMSM Architecture SSH is a security layer which is plugged into the TMSM architecture between the underlying transport layer and the message dispatcher. The SSHSM model will establish an encrypted tunnel between the transport mappings of two SNMP engines. The sending transport mapping security model instance encrypts outgoing messages, and the Harrington, et al. Expires March 6, 2006 [Page 7] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 receiving transport mapping security model instance decrypts the messages. After the transport layer tunnel is established, then SNMP messages can conceptually be sent through the tunnel from one SNMP message dispatcher to another SNMP message dispatcher. Once the tunnel is established, multiple SNMP messages may be able to be passed through the same tunnel. Within an engine, outgoing SNMP messages are passed unencrypted from the message dispatcher to the transport mapping, and incoming messages are passed unencrypted from the transport mapping to the message dispatcher. SSHSM security processing will be called from within the Transport Mapping functionality of an SNMP engine dispatcher to perform the translation of transport security parameters to/from security-model-independent parameters. Some SSHSM security processing will also be performed within a message processing portion of the model, for compatibility with the ASIs between the RFC 3411 Security Subsystem and the Message Processing Subsystem. 2.1 Security Capabilities of this Model 2.1.1 Threats The Secure Shell Security Model provides protection against the threats identified by the RFC 3411 architecture [RFC3411]: 1. Message stream modification - Provide for verification that each received SNMP message has not been modified during its transmission through the network. . 2. Information modification - Provide for verification that the contents of each received SNMP message has not been modified during its transmission through the network. Data has not been altered or destroyed in an unauthorized manner, nor have data sequences been altered to an extent greater than can occur non- maliciously 3. Masquerade - Provide for verification of the identity of the user on whose behalf a received SNMP message claims to have been generated. For the protocols specified in this memo, it is not possible to assure the specific originator of a received SNMP message; rather, it is the user on whose behalf the message was originated that is authenticated. 4. Disclosure - Provide, when necessary, that the contents of each received SNMP message are protected from disclosure to unauthorized persons.. Harrington, et al. Expires March 6, 2006 [Page 8] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 5. Replay - Provide for detection of received SNMP messages, which request or contain management information, whose time of generation was not recent. A message whose generation time is outside of a time window is not accepted. Note that message reordering is not dealt with and can occur in normal conditions 2.1.1.1 [todo] Data Origin Authentication Issues 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) [todo] (This paragraph is from the USM document; do we need a comparable paragraph?) For these protocols, it not possible to obtain data integrity without data origin authentication, nor is it possible to obtain data origin authentication without data integrity. Further, there is no provision for data confidentiality without both data integrity and data origin authentication. 2.1.1.1.1 [todo] noAuthPriv SSH provides the "none" userauth method, which is normally rejected by servers and used only to find out what userauth methods are supported. However, it is legal for a server to accept this method, which has the effect of not authenticating the ssh client to the ssh server. Doing this does not compromise authentication of the ssh server to the ssh client, nor does it compromise data confidentiality or data integrity. [todo] The RFC 3411 architecture does not permit noAuthPriv. [todo] Should the SSHSM refuse a noAuth session, and subsequent encryption? or should we simply not accept any noAuth sessions? or should we change the architecture to permit noAuthPriv? If we do not allow some of these options, how do we determine the option was used, so we can reject it? How does an SNMP engine reject a session? 2.1.1.1.2 [todo] skipping public key verification [todo] Most key exchange algorithms are able to authenticate the SSH server's identity to the client. However, for the common case of DH signed by public keys, this requires the client to know the host's public key a priori and to verify that the correct key is being used. If this step is skipped, you no longer have authentication of the ssh server to the ssh client. You do still get data confidentiality and data integrity protection to whatever server you're talking to, but these are of dubious value when an attacker can insert himself between the client and the real ssh server. Note that some userauth Harrington, et al. Expires March 6, 2006 [Page 9] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 methods may defend against this situation, but many of the common ones (including password and keyboard-interactive) do not, and in fact depend on the fact that the server's identity has been verified (otherwise you may be giving your password to an attacker). 2.1.1.1.3 [todo] the 'none' MAC algorithm [todo] Finally, SSH does provide the "none" MAC algorithm, which would allow you to turn off data integrity while maintaining confidentiality. However, if you do this, then an attacker may be able to modify the data in flight, which means you effectively have no authentication. This is not a limitation of ssh; it is a fundamental principle. The security protocols used in this memo are considered acceptably secure at the time of writing. However, the procedures allow for new authentication and privacy methods to be specified at a future time if the need arises. 2.1.2 Sessions Sessions are not part of RFC 3411 architecture, but are considered desirable because the cost of authentication can be amortized over potentially many transactions. The Secure Shell security model will utilize sessions, with a single user and security level associated with each session. If an exchange with another engine would require a different security level or would be on behalf of a different user, 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. This document will discuss the impact of sessions on SNMP usage. [todo] 2.1.2.1 Message security versus session security [todo] 2.1.3 Authentication Protocol The SSH Authentication Protocol document describes three authentication methods - publickey, password, and host-based. All three authentication methods are supported by the Secure Shell Security Model for SNMP. The password authentication mechanism allows for integration with deployed password based infrastructure. It is possible to hand a password to a service for validation similar to what the PPP password authentication protocol (PAP) [todo: reference] does. This is one possible way to integrate with RADIUS. It is also possible to use Harrington, et al. Expires March 6, 2006 [Page 10] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 the password in a more secure protocol such as CHAP [todo: reference] or digest authentication [todo: reference] which can provide another way to integrate with RADIUS. Any of these mechanism leave the password in the clear on the device that is authenticating the password which introduces threats on the authentication infrastructure which is less than ideal. It is possible that new mechanism will be developed using authentication mechanisms defined in [gsskeyex] which will allow for user authentication mechanisms which support different security infrastructures and provide security properties. [todo] Which if these approaches are supported by the Secure Shell Security Model for SNMP? Which would require more work? 2.1.4 Privacy Protocol The Secure Shell Security Model uses the SSH transport layer protocol, which provides strong encryption, server authentication, and integrity protection. 2.1.5 Protection against Message Replay, Delay and Redirection The Secure Shell Security Model uses the SSH transport layer protocol. SSH uses sequence numbers and integrity checks to protect against replay and reordering of messages within a connection. SSH also provides protection against replay of entire sessions. In a properly-implemented DH exchange, both sides will generate new random numbers for each exchange, which means the exchange hash and thus the encryption and integrity keys will be distinct for every session. This would prevent capturing an SNMP message and redirecting it to another SNMP engine. Message delay is not as important an issue with SSH as it is with USM. USM checks the timeliness of messages because it does not provide session protection or message sequence ordering. The only delay that would seem to be possible would be to capture the next sequence numbered packet and hold it to play within the same session later. 2.1.6 [todo] Security Protocol Requirements Using a protocol in a manner for which it was not designed has numerous problems. Secure Shell was designed to provide a secure interactive shell for manual interaction. It is frequently used to secure the Command Line Interface (CLI) for interactive management of a managed device. SNMP was designed to automate management and is Harrington, et al. Expires March 6, 2006 [Page 11] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 frequenetly used in a programmatic manner with no operator present. This document will discuss security and operational considerations of utilizing Secure Shell for SNMP management purposes. [todo] Modifying the Secure Shell protocol, or configuring it a particular manner, may change its security 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. This document will include a discussion of the potential impact on other usages of the protocol. [todo] It has been a long-standing requirement that SNMP be able to work when the network is unstable, to enable network troubleshooting and repair. The UDP approach has been considered to meet that need well, with an assumption that getting small messages through, even if out of order, is better than gettting no messages through. There has been a long debate about whether UDP actually offers better support than TCP when the underlying IP or lower layers are unstable. There has been recent discussion of whether operators actually use SNMP to troubleshoot and repair unstable networks. This document will include a discussion of the operational expectations of this model for use in troubleshooting a broken network.[todo] This may belong in the TMSM document [todo] There has been discussion of ways SNMP could be extended to better support management/monitoring needs when a network is running just fine. Use of a TCP transport, for example, could enable larger message sizes and more efficient table retrievals. Secure Shell runs over TCP. This document will discuss the expected ramifications of using a TCP transport for SNMP, and the coexistence of UDP and TCP transport for SNMP. [todo] Should this be discussed in the TMSM document? The Secure Shell security model must be able to coexist with other SNMP security models. This document will discuss the coexistence of this model with the only other existing security model - the USM security model. [todo]. 2.1.6.1 [todo] Mapping SSH to EngineID [todo] In this section we talk about authentication of the "user". Here is my knowledge of SNMP is a little week. In the simple case the SSH server will be a command responder and a Notification generator. I believe these entities are identified by their SNMP engine ID. Doe we need a mapping between SSH key and SNMP engine ID(s)? [todo]> I think the SNMP entity and the SSH server are separate, and Harrington, et al. Expires March 6, 2006 [Page 12] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 > co-exist on the target system. I don't think the SSH server > will exist inside the SNMP entity, but that the SNMP entity > will talk to the co-resident SSH server. > > This is somewhat important because there can be multiple SNMP > entities operating on the same system, probably on different > ports, providing different MIB module support. For example, > one commercial SNMP agent might provide support for the > interfaces, while another commercial agent supports the RDBMS > (relational database management), and a third could act as an > RMON probe. > > Assuming we complete the ISMS work, they might be configured > to share the SSH server for access to the common RADIUS > client or the local accounts. Does this make sense for SSH? > [Joe] In general what you say makes sense, however one thing I find missing in much of the discussion is how one identifies and authenticates the engine that one is communicating with. Perhaps it is sufficient to just authenticate the host, but this appears to be somewhat different than what USM does since in USM the key localization essentially creates a shared secret between a user and a particular engine. The SSH SNMP subsystem would be responsible for making sure the correct requests get to the correct engine and that engine only send response on the correct (authoritative?) engine ID. [Joe 8/29]Multiple SSH clients can be resident on a host. I believe that multiple SSH server would require each server to run on a different port. Depending on what you want to achieve you may be able to have multiple subsystems running in a single server, however all of those subsystems would be authenticated to the SSH client with the same credential used in establishing the SSH session. 2.2 Security Parameter Passing Requirement [SSHSM follows the TMSM approach, in which the security -model specific parameters can be determined from the transport layer by the transport mapping, before the message processing begins. [todo] For outgoing messages, it is necessary to have an MPSP portion of the security model because it is the MPSP that actually creates the WholeMsg from its component parts. In the SSHSM model, the MPSP does not apply encryption, integrity-checking, or authentication. For example, an SNMPv3 message is built without any content in the SecurityParameters field, and the WholeMsg is passed unencrypted back to the Message Processing Model for forwarding to the Transport Mapping. A cache mechanism will be used, into which the TMSP puts information about the security applied to an incoming message, and an MPSP extracts that information from the cache. Given that there may be Harrington, et al. Expires March 6, 2006 [Page 13] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 multiple TM-security caches, a cache ID will need to be passed through an ASI so the MPSP knows which cache of information to consult. [todo] The cache reference could be thought of as an additional parameter in the ASIs between the transport mapping and the messaging security model. The RFC 3411 ASIs would not need to be changed since the SNMPv3 WG expected that additional parameters could be passed for value-add features of specific implementations. This approach does create dependencies between a model-specific TPSP and a corresponding specific MPSP. If a TMSM-model-independent ASI parameter is passed, this approach would be consistent with the securityStateReference cache already being passed around in the ASI. 2.3 Requirements for Notifications [todo] cleanup this section RFC 3430 (SNMP over TCP) suggests that TCP connections are initiated by notification originators in case there is no currently established connection that can be used to send the notification. Following this approach with ssh would require to provision authentication credentials on the agent so that agents can successfully authenticate to a notification receiver. There might be other approaches, like the reuse of manager initiated secure transport connections for notifications. There is some text in Appendix A in RFC 3430 which captures some of these discussions when RFC 3430 was written. 2.4 Scenario Diagrams RFC 3411 section 4.6 provides scenario diagrams to illustrate how an outgoing message is created, and how an incoming message is processed. Both diagrams are incomplete, however.In section 4.61, the diagram doesn't show the ASI for sending an SNMP request to the network or receiving an SNMP response message from the network. In section 4.6.2, the diagram doesn't illustrate the interfaces required to receive an SNMP message from the network, or to send an SNMP message to the network. 2.4.1 Command Generator or Notification Originator This diagram from RFC 3411 4.6.1 shows how a Command Generator or Notification Originator application requests that a PDU be sent, and how the response is returned (asynchronously) to that application. Harrington, et al. Expires March 6, 2006 [Page 14] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 Command Dispatcher Message Security Generator | Processing Model | | Model | | sendPdu | | | |------------------->| | | | | prepareOutgoingMessage | | : |----------------------->| | : | | generateRequestMsg | : | |-------------------->| : | | | : | |<--------------------| : | | | : |<-----------------------| | : | | | : |------------------+ | | : | Send SNMP | | | : | Request Message | | | : | to Network | | | : | v | | : : : : : : : : : : : : : : : : | | | | : | Receive SNMP | | | : | Response Message | | | : | from Network | | | : |<-----------------+ | | : | | | : | prepareDataElements | | : |----------------------->| | : | | processIncomingMsg | : | |-------------------->| : | | | : | |<--------------------| : | | | : |<-----------------------| | | processResponsePdu | | | |<-------------------| | | | | | | 2.4.2 Command Responder This diagram shows how a Command Responder or Notification Receiver application registers for handling a pduType, how a PDU is dispatched to the application after an SNMP message is received, and how the Harrington, et al. Expires March 6, 2006 [Page 15] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 Response is (asynchronously) send back to the network. Command Dispatcher Message Security Responder | Processing Model | | Model | | | | | | registerContextEngineID | | | |------------------------>| | | |<------------------------| | | | | | Receive SNMP | | | : | Message | | | : | from Network | | | : |<-------------+ | | : | | | : |prepareDataElements | | : |------------------->| | : | | processIncomingMsg | : | |------------------->| : | | | : | |<-------------------| : | | | : |<-------------------| | | processPdu | | | |<------------------------| | | | | | | : : : : : : : : | returnResponsePdu | | | |------------------------>| | | : | prepareResponseMsg | | : |------------------->| | : | |generateResponseMsg | : | |------------------->| : | | | : | |<-------------------| : | | | : |<-------------------| | : | | | : |--------------+ | | : | Send SNMP | | | : | Message | | | : | to Network | | | : | v | | 2.5 Abstract Service Interfaces Harrington, et al. Expires March 6, 2006 [Page 16] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 3. RFC 3411 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. The Secure Shell Security Model uses some of these conceptual data flows when communicating with other subsystems, such as the Message Processing Subsystem. These RFC 3411-defined data flows are referred to here as public interfaces. 3.1 Public Abstract Service Interfaces 3.1.1 Public ASIs for Outgoing Messages The IN parameters of the prepareOutgoingMessage() ASI are used to pass information from the dispatcher (application subsystem) to the message processing subsystem. The OUT parameters are used to pass information from the message processing subsystem to the dispatcher and on to the transport mapping: 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 ) The abstract service primitive from a Message Processing Model to a Security Model to generate the components of a Request message is: Harrington, et al. Expires March 6, 2006 [Page 17] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 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 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 ) The abstract service primitive from a Message Processing Model to a Security Model to generate the components of a Response message is: 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 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 ) The abstract data elements passed as parameters in the abstract service primitives are as follows: [todo] check each parameter and determine if it is necessary for SSHSM and whether the description is accurate statusInformation - An indication of whether the encoding and securing of the message was successful. If not it is an indication of the problem. messageProcessingModel - The SNMP version number for the message to be generated. This data is not used by the User-based Security module. Harrington, et al. Expires March 6, 2006 [Page 18] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 globalData - The message header (i.e., its administrative information). This data is not used by the User-based Security module. maxMessageSize - The maximum message size as included in the message. This data is not used by the User-based Security module. securityParameters - These are the security parameters. They will be filled in by the SSH Security module. securityModel - The securityModel in use. Should be SSH Security Model. securityName - identifies a principal to be used for securing an outgoing message. The securityName has a format that is independent of the Security Model. In case of a response this parameter is ignored and the value from the cache is used. securityLevel - The Level of Security from which the SSH Security module determines if the message needs to be protected from disclosure and if the message needs to be authenticated. securityEngineID - The snmpEngineID of the [todo: authoritative?] SNMP engine to which a dateRequest message is to be sent. In case of a response it is implied to be the processing SNMP engine's snmpEngineID and so if it is specified, then it is ignored. scopedPDU - The message payload. The data is opaque as far as the SSH Security Model is concerned. securityStateReference - A handle/reference to cachedSecurityData to be used when securing an outgoing Response message. This is the exact same handle/reference as it was generated by the SSH Security module when processing the incoming Request message to which this is the Response message. wholeMsg - The fully encoded SNMP message ready for sending on the wire. wholeMsgLength - The length of the encoded SNMP message (wholeMsg). Upon completion of the process, the SSH Security module returns statusInformation. If the process was successful, the completed message is returned, without the privacy and authentication applied yet. If the process was not successful, then an errorIndication is returned. 3.1.2 Public ASIs for Incoming Messages The abstract service primitive from a Transport Mapping (in the dispatcher) to a Message Processing Model for a received message is:: Harrington, et al. Expires March 6, 2006 [Page 19] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 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 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 ) The abstract service primitive from a Message Processing Model to the Security Subsystem for a received message is:: 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 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 3.2 Private Abstract Service Interfaces A set of abstract service interfaces have been defined within this Harrington, et al. Expires March 6, 2006 [Page 20] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 document to describe the conceptual data flows between the Secure Shell Security Model (SSHSM) and the self-contained transport mapping services.These apply only to the Secure Shell Security Model (SSHSM), and are referred to here as private interfaces. The Secure Shell Security Model provides the following internal primitives to pass data back and forth between the Security Model itself and the SSH authentication service: statusInformation =3D establishSession( IN transportDomain -- transport domain to be used IN transportAddress -- transport address to be used IN securityModel -- Security Model to use IN securityEngineID -- SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested OUT sessionID ) [todo] - I think the following are not needed for SSHSM,, since authentication and encryption are handled by SSH at a lower layer without intervention by the SSHSM. For incoming messages, the first we see of the message is via the wholeMsg parameter of the prepareDataElements() ASI, by which time it has already been decrypted and authenticated. For outgoing messages, the last we see of the message is the outgoingMessage parameter of the prepareOutgoingMessage() ASI, at which point it is neither authenticated nor encrypted yet. Therefore, we never need to directly call functions for the authentication and privacy services. They are listed here for discussion purposes only, to ensure that consensus is that they are not needed. statusInformation =3D authenticateOutgoingMsg( IN wholeMsg -- unauthenticated complete message OUT authenticatedWholeMsg -- complete authenticated message ) Harrington, et al. Expires March 6, 2006 [Page 21] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 statusInformation =3D authenticateIncomingMsg( IN authKey -- secret key for authentication IN authParameters -- as received on the wire OUT tmSessionReference -- as received on the wire OUT authenticatedWholeMsg -- complete authenticated message ) The Secure Shell Security Model provides the following internal primitives to pass data back and forth between the Security Model itself and the SSH encryption service: statusInformation =3D encryptData( IN encryptKey -- secret key for encryption IN dataToEncrypt -- data to encrypt (scopedPDU) OUT encryptedData -- encrypted data (encryptedPDU) OUT privParameters -- filled in by service provider ) statusInformation =3D decryptData( IN decryptKey -- secret key for decrypting IN privParameters -- as received on the wire IN encryptedData -- encrypted data (encryptedPDU) OUT decryptedData -- decrypted data (scopedPDU) ) 4. SNMP Messages Using this Security Model The syntax of an SNMP message using this Security Model adheres to the message format defined in the version-specific Message Processing Model document (for example [RFC3412]). At the time of this writing, there are three defined message formats - SNMPv1, SNMPv2c, and SNMPv3. 4.1 SNMPv1 and SNMPv2c Messages Using this Security Model Since message security is provided by a "lower layer", the message does not need to carry message security parameters within the PDU. The securityModel and securityName parameters are determined by the Secure Shell Security Model from the SSH service. SSHSM requires Harrington, et al. Expires March 6, 2006 [Page 22] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 that transport always be authenticated and integrity-checked, and encrypted, so all SSHSM messages are authpriv. Since an incoming SNMPv1 or SNMPv2c message lacks a msgFlags field, the msgFlags is always treated as authPriv. [todo] The communitystring is not used as an authentication mechansism, since user authentication is provided by SSH userauth. The community string is still used to provide context information. The SNMPv1 and SNMPv2c message formats do not contain a contextEngineID, but do contain an IP Address field that can be used to perform proxy. [todo - determine the proxy forwarding mechanism, if any.] 4.2 SNMPv3 Messages Using this Security Model [todo] RFC 3412 defines two primitives, generateRequestMsg() and processIncomingMsg() which require the specification of an authoritative SNMP entity. [todo] We need to discuss what the meaning of authoritative would be in a TMSM environment, whether the specific services provided in USM security from msgSecurityParameters still are needed, and how the Message Processing model provides this information to the security model via generateRequestMsg() and processIncomingMsg() primitives. The SNMPv3Message SEQUENCE is defined in [RFC3412]. The following fields are specific to the Secure Shell Security Model: Harrington, et al. Expires March 6, 2006 [Page 23] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::=3D BEGIN SNMPv3Message ::=3D SEQUENCE { -- identify the layout of the SNMPv3Message -- this element is in same position as in SNMPv1 -- and SNMPv2c, allowing recognition -- the value 3 is used for snmpv3 msgVersion INTEGER ( 0 .. 2147483647 ), -- administrative parameters msgGlobalData HeaderData, -- security model-specific parameters -- format defined by Security Model msgSecurityParameters OCTET STRING, msgData ScopedPduData } HeaderData ::=3D SEQUENCE { msgID INTEGER (0..2147483647), msgMaxSize INTEGER (484..2147483647), msgFlags OCTET STRING (SIZE(1)), -- .... ...1 authFlag -- .... ..1. privFlag -- .... .1.. reportableFlag -- Please observe: -- .... ..00 is OK, means noAuthNoPriv -- .... ..01 is OK, means authNoPriv -- .... ..10 reserved, MUST NOT be used. -- .... ..11 is OK, means authPriv msgSecurityModel INTEGER (1..2147483647) } ScopedPduData ::=3D CHOICE { plaintext ScopedPDU, encryptedPDU OCTET STRING -- encrypted scopedPDU value } ScopedPDU ::=3D SEQUENCE { contextEngineID OCTET STRING, contextName OCTET STRING, data ANY -- e.g., PDUs as defined in [RFC3416] } END Harrington, et al. Expires March 6, 2006 [Page 24] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 4.2.1 msgGlobalData SSHSM requires that transport always be authenticated, integrity- checked, and encrypted, so all SSHSM messages are authpriv. The msgFlags MUST always be set to authPriv. msgSecurityModel is set to the IANA-assigned value for the Secure Shell Security Model. See http://www.iana.org/assignments/snmp-number-spaces. 4.2.1.1 msgSecurityParameters Since message security is provided by a "lower layer", and the securityName parameter is alsways determined from the SSH authentication method, the SNMP message does not need to carry message security parameters within the PDU. To prevent its being used in a manner that could be damaging, such as for carrying a virus or worm, when used with SSHSM, it is an empty field . The field msgSecurityParameters in SNMPv3 messages has a data type of OCTET STRING. Its value MUST be the BER serialization of the following ASN.1 sequence: SSHSMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::=3D = BEGIN SSHsmSecurityParameters ::=3D SEQUENCE { NULL } END 4.2.1.2 msgFlags [todo] For an outgoing message, msgFlags is the requested security for the message; if a SSHSM cannot provide the requested securityLevel, the request MUST be discarded and SHOULD notify the message processing model that the request failed. [todo: how does this apply in the SSHSM model, especially if the msgFlags MUST always be set to authpriv? (or more accurately, include authpriv flags)] [todo] do we need do discuss the rest of this, or is this applicable to all TMSM models? For an outgoing message, it is acceptable for the SSHSM to provide stronger than requested security. To avoid the need to mess with the ASN.1 encoding, the SNMPv3 message carries the requested msgFlags, not the actual securityLevel applied to the message. If a message Harrington, et al. Expires March 6, 2006 [Page 25] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 format other than SNMPv3 is used, then the new message may carry the more accurate securityLevel in the SNMP message. For an incoming message, the receiving SSHSM knows what must be done to process the message based on the transport layer mechanisms. If the underlying transport security mechanisms for the receiver cannot provide the matching securityLevel, then the message should follow the standard behaviors for the transport security mechanism, or be discarded silently. Part of the responsibility of the SSHSM is to ensure that the actual security provided by the underlying transport layer security mechanisms is configured to meet or exceed the securityLevel required by the msgFlags in the SNMP message. When the MPSP processes the incoming message, it should compare the msgFlags field to the securityLevel actually provided for the message by the transport layer security. If they differ, the MPSP should determine whether the changed securityLevel is acceptable. If not, it should discard the message. [todo] The MPSP may issue a reportPDU with the XXXXXXX model-specific counter. 4.3 Passing Security Parameters For each message received, the Security Model caches the state information such that a Response message can be generated using the same security information, even if the Configuration Datastore is altered between the time of the incoming request and the outgoing response. For SSHSM, there are three levels of state that need to be maintained: the session, the message, and the model-independent translations. [todo]ensuring consistent security for responses even if the datastore changes is important for USM because USM handles keychanges; will SSHSM allow keychanges to the SSH local datastore? if not, this cache of message-pair-state may be an unnecessary constraint. is it important to ensure responses use the same security as the request for secureity reasons? tmSessionReference is used to pass model- and mechanism-specific parameters to coordinate the session-related activities of the TMSP and MPSP. The SSHSM has the responsibility for explicitly releasing the tmSessionReference when the session is destroyed. tmStateReference is used to pass model- and mechanism-specific parameters to coordinate the activities of the TMSP and MPSP related to a specific pair of messages. The SSHSM has the responsibility for explicitly releasing the tmStateReference once a response message has been sent, or the data is no longer needed. Harrington, et al. Expires March 6, 2006 [Page 26] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 The MPSP translates select parameters from the tmSessionReference cache into model-independent parameters subsequently passed in the securityStateReference cache to a Message Processing Model. The Message Processing Model has the responsibility for explicitly releasing the securityStateReference if such data is no longer needed. The securityStateReference cached data may be implicitly released via the generation of a response, or explicitly released by using the stateRelease primitive, as described in RFC 3411 section 4.5.1." 4.3.1 Transport Session Parameters [todo] SSHSM will create a session between the TMSM of one SNMP entity and the TMSM of another SNMP entity. The created "tunnel" will provide encryption and data integrity. The SSHSM model MUST provide mutual authentication of the client and server, and MUST authenticate, integrity-check, and encrypt the messages. Upon establishment of a SSH session, the TMSP will cache the state information about the transport parameters. The tmSessionReference will be passed to the corresponding MPSP. [todo] The tmSessionReference cache for use with the SSH Authentication Protocol [SSHAuth]: tmStateReference tmSecurityStateReference tmTransportDomain =3D TCP/IPv4 tmTransportAddress =3D x.x.x.x:y tmSecurityModel - SSHSM tmSecurityLevel =3D "authPriv" tmSessionID =3D Handshake session identifier tmSessionKey =3D Handshake peer certificate tmSessionMasterSecret =3D master secret tmSessionParameters =3D compression method, cipher spec, is- resumable tmSecurityName =3D "dbharrington" tmAuthMechanism =3D "[todo]" tmAuthProtocol =3D "" tmRadiusServer =3D "" tmPrivProtocol =3D "" Additional information will be added to the tmStateReference by the authentication portion of the SSHSM. 4.3.1.1 Authenticating Servers and Clients [todo] can we mandate mutual authentication? Harrington, et al. Expires March 6, 2006 [Page 27] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 4.3.2 [todo] Using Local Accounts to Authenticate Users Upon creation of a SSH session leveraging SSH Local Accounts, the TMSP will cache the session authentication information in the tmSessionReference: tmSecurityName =3D "dbharrington" tmAuthMechanism =3D "public key" tmAuthProtocol =3D LocalAccounts 4.3.3 [todo] Using RADIUS Accounts to Authenticate Users Upon creation of a SSH session leveraging RADIUS Accounts, the TMSP will cache the session authentication information in the tmSessionReference: tmSecurityName is the name used in username field of the RADIUS ACCESS-REQUEST message. tmAuthMechanism =3D "[todo]" tmAuthProtocol =3D RADIUS tmRadiusServer =3D x.x.x.x:y 4.3.4 securityStateReference for SSHSM [todo] messageProcessingModel =3D SNMPv3 securityModel =3D SSHSM securityName =3D tmSecurityName securityLevel =3D msgSecurityLevel 4.4 MIB Module for SSH Security Model Each security model should use its own MIB module, rather than utilizing the USM MIB, to eliminate dependencies on a model that could be replaced some day. See RFC 3411 section 4.1.1. The SSHSM-MIB module needs to provide the mapping from model-specific identity to a model independent securityName, and possibly a mapping to a groupname. [todo] Module needs to be worked out once things become stable... 4.5 [todo] Notifications For notifications, if the cache has been released and then session closed, then the MPSP will request the TMSP to establish a session, populate the cache, and pass the securityStateReference to the MPSP. [todo] We need to determine what state needs to be saved here. Harrington, et al. Expires March 6, 2006 [Page 28] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 5. Elements of Procedure 5.1 Discovery [todo] how can the SNMP engine be discovered? Auto-discovery of SNMP devices is an important feature of many NMS platforms. Should we simply use a noAuthNoPriv request, and recommend an associated access control configuration that only makes accessible relatively benign data such as sysOID, sysDescription, and snmpEngineID? Should we standardize this approach for all TMSM models, including a "named policy" for what can be discovered (a policy to be configured within whatever access control system is used)? USM uses reports; can we let USM perform discovery so we don't have to attenpt to estabolish an SSH connection first? USM is the mandatory-to-implement security model, so this would make sense. 5.2 Establishing a Session The following describes the procedure to follow to establish a session between a client and sever to run SNMP over SSH. This process is followed by any SNMP engine establishing a session for subsequent use. In practice, this is done by an application that initiates a transaction, such as a Command Generator or a Notification Origintaor or a Proxy Forwarder. It is never triggered by an application preparing a response message, such as a Command Responder or Notification Receiver, because securityStatereference will always have session information for a response message. The parameters necessary to establish a session are provided by the Secure Shell Security Model to the SSH client code, using the establishSession() ASI. 1) If the securityLevel specifies that the message is to be authenticated, but the SSH implementation does not support an authentication protocol, then the message cannot be sent. An error indication (unsupportedSecurityLevel) is returned to the calling module. 2) If the securityLevel specifies that the message is to be protected from disclosure, but the SSH implementation does not support encryption, then the message cannot be sent. An error indication (unsupportedSecurityLevel) is returned to the calling module. 3) Using destTransportDomain and destTransportAddress, the client will establish an SSH transport connection using the SSH transport protocol, and the client and server will mutually authenticate, and exchange keys for message integrity and encryption. If the attempt Harrington, et al. Expires March 6, 2006 [Page 29] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 to establish a connection is unsuccessful, then an error indication [todo] will be returned, and [todo] processing stops. 4) Based on the securityEngineID, securityName, securityModel, and securityLevel, information concerning the user at the destination is extracted from the Local Configuration Datastore (LCD). This step allows preconfiguration of model-specific user identities mapped to a securityName. Set the username in the SSH_MSG_USERAUTH_REQUEST to the username extracted from the LCD. If information about the user is absent from the LCD, then set the username in the SSH_MSG_USERAUTH_REQUEST to the value of securityName. This allows a deployment without preconfigured mappings between model-specific and model-independent names, but the securityName will need to contain a username recognized by the authentication mechanism. 5)The client will then invoke the "ssh-userauth" service to authenticate the user, as described in the SSH authentication protocol [SSHAuth]. 6) If the authentication is unsuccessful, then the transport connection should be closed, tmStateReference is discarded, the message is discarded, an error indication (unknownSecurityName) is returned to the calling module, and processing stops for this message. 7) Once the user has been successfully authenticated, the client will invoke the "ssh- connection" service, also known as the SSH connection protocol [SSHConnect]. 8) After the ssh-connection service is established, the client will use an SSH_MSG_CHANNEL_OPEN message to open a channel of type "session", providing a selected sender channel number, and a maximum packet size based on maxMessageSize. 9) If successful, this will result in an SSH session. The "recipient channel" and "sender channel" and other relevant data from the SSH_MSG_CHANNEL_OPEN_CONFIRMATION are added to the tmStateReference for subsequent use. 10) Once the SSH session has been established, the SNMP engine will invoke SNMP as an SSH subsystem called "SNMP". Running SNMP as an SSH subsystem avoids the need for the script to recognize shell prompts or skip over extraneous information, such as a system message that is printed at shell start-up. In order to allow SNMP traffic to be easily identified and filtered Harrington, et al. Expires March 6, 2006 [Page 30] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 by firewalls and other network devices, servers associated with SNMP entities using the Secure Shell Security Model MUST default to providing access to the "SNMP" SSH subsystem only when the SSH session is established using the IANA-assigned TCP port (TBD). Servers SHOULD be configurable to allow access to the SNMP SSH subsystem over other ports. The SNMP engine should use the following command line to invoke SNMP as an SSH subsystem on the IANA-assigned port: [user@client]$ ssh -s server.example.org -p (TBD) SNMP [todo] check whether there is a better way to establish a tunnel for SNMP messages. [todo] Should we perform some type of engineID discovery to provide the mapping between transport address, session, and engineID at this point in the session establishment procedure? We have an established channel; can we simply send a GET of snmpEngineID and record the value i the tmStateReference? 5.3 Generating an Outgoing SNMP Message This section describes the procedure followed by the Secure Shell Security Model whenever it generates a message containing a management operation (like a request, a response, a notification, or a report) on behalf of a user. The parameters needed are supplied by the Message Processing Model via the generateRequestMsg() or the generateResponseMsg() ASI 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 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 -- reference to session info ) Harrington, et al. Expires March 6, 2006 [Page 31] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 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 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 -- reference to session info ) verify securityModel =3D sshsmSecurityModel If there is a securityStateReference, extract the tmStateReference information from the cachedSecurityData from the Request message. [todo] With USM, at the point the cachedSecurityData can now be discarded. Since we now have persistent sessions, this is no longer true, but can some of the cached data be discarded, such as message pair information? If there is no securityStateReference, then lookup the session info indexed by {securityEngineID, securityName, securityLevel}, and set tmStateReference. If there is no session info for this index, then create an incomplete tmStateReference indexed by the provided {securityEngineID, securityName, securityLevel}. Store the securityModel and maxMessageSize information. When the TMSP gets the incomplete tmStateReference, it will recognize that it needs to establish a new session, and fill in the rest of the information for subsequent use. fill in securityParameters a NULL octet string) OR These are steps from the USM model that we don't need to do: [todo] we don't need to send securityEngineID, unless we send an empty string to cause a report with the opposite engine's engineID. This could be done using USM with presumably less overhead, or it could be done as part of session establishment.. [todo] we don't need to send Boots and Time values [todo] we don't need to send a username, since we use the one from SSH authentication Harrington, et al. Expires March 6, 2006 [Page 32] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 [todo] we don't need to call authenticateOutgoingMsg() The wholeMsg is now serialized and then represents the unauthenticated message being prepared. The completed message (wholeMsg) with its length (wholeMsgLength) and securityParameters (a NULL octet string) and tmStateReference is returned to the calling module with the statusInformation set to success. The Message Processing Model then passes information to the disptacher for forwarding to the Transport Mapping. 5.4 Sending an Outgoing SNMP Message to the Network The TMSP portion of the Secure Shell Security Model performs the following tasks: Uses tmStateReference to lookup session information. [todo] verifies that auth and priv can be provided, as requested, and error-out if not. If the session information is incomplete (i.e, has no tmTransportAddress), then call establishSession() using the destTransportDomain and destTransportAddress (the output of the PrepareOutgoingMessage() ASI) and the securityModel, securityEngineID, securityName, securityLevel from the tmStateReference. Store all information in the tmStateReference for subsequent use. An SSH_MSG_CHANNEL_DATA message is sent, indicating the recipient channel and encapsulating the wholeMessage. [todo] According to RFC 3411, section 4.1.1, the application provides the transportDomain and transportAddress to the PDU dispatcher via the sendPDU() primitive. If we permit multiple sessions per transportAddress, then we would need to define how session identifiers get passed from the application to the PDU dispatcher (and then to the MP model). [todo] The SNMP over TCP Transport Mapping document [RFC3430] says that TCP connections can be recreated dynamically or kept for future use and actually leaves all that to the transport mapping. [todo] We might have a MIB module that records the session information for subsequent use by the applications and other subsytems, or it might be passed in the tmStateReference cache. For notifications, I assume the SNMPv3 notification tables would be a place to find the address, but I'm not sure how to identify the presumably-dynamic session identifiers. The MIB module could identify whether the session was initiated by the remote engine or initiated by the current engine, and possibly assigned a purpose (incoming request/response or outgoing notifications). First we need Harrington, et al. Expires March 6, 2006 [Page 33] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 to decide whether to handle notifications and requests in one or two (or more) sessions. Do we use an established session bi- directionally, or do we establish two separate sessions, one for each direction as needed? 5.5 [todo] Prepare Data Elements from an Incoming SNMP Message For an incoming message, the TMSP will need to put information from the transport mechanisms used into the tmStateReference so the MPSP can extract the information and add it conceptually to the securityStateReference. 5.6 Processing an Incoming SNMP Message 6. MIB module definition SSHSM-MIB DEFINITIONS ::=3D BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB; sshsmMIB MODULE-IDENTITY LAST-UPDATED "200509020000Z" ORGANIZATION "ISMS Working Group" CONTACT-INFO "WG-EMail: isms@lists.ietf.org Subscribe: isms-request@lists.ietf.org Chair: Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany +49 6221 90511-15 quittek@netlab.nec.de Co-editors: David Harrington Effective Software 50 Harding Rd Portsmouth, New Hampshire 03801 USA Harrington, et al. Expires March 6, 2006 [Page 34] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 +1 603-436-8634 ietfdbh@comcast.net Juergen Schoenwaelder International University Bremen Campus Ring 1 28725 Bremen Germany +49 421 200-3587 j.schoenwaelder@iu-bremen.de Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 USA jsalowey@cisco.com " DESCRIPTION "The Secure Shell Security Model MIB Copyright (C) The Internet Society (2005). 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 "200509020000Z" -- 02 September 2005 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 SSHSM-MIB -- ---------------------------------------------------------- -- sshsmNotifications OBJECT IDENTIFIER ::=3D { sshsmMIB 0 } sshsmObjects OBJECT IDENTIFIER ::=3D { sshsmMIB 1 } sshsmConformance OBJECT IDENTIFIER ::=3D { sshsmMIB 2 } -- ------------------------------------------------------------- -- Objects -- ------------------------------------------------------------- Harrington, et al. Expires March 6, 2006 [Page 35] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 -- ------------------------------------------------------------- -- sshsmMIB - Conformance Information -- ------------------------------------------------------------- sshsmGroups OBJECT IDENTIFIER ::=3D { sshsmConformance 1 } sshsmCompliances OBJECT IDENTIFIER ::=3D { sshsmConformance 2 } -- ------------------------------------------------------------- -- Units of conformance -- ------------------------------------------------------------- sshsmGroup OBJECT-GROUP OBJECTS { } STATUS current DESCRIPTION "Secure Shell Security Model objects" ::=3D { sshsmGroups 2 } -- ------------------------------------------------------------- -- Compliance statements -- ------------------------------------------------------------- sshsmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for support of the Secure Shell Security Model" MODULE MANDATORY-GROUPS { } ::=3D { sshsmCompliances 1 } END 7. Security Considerations This document describes a security model that would permit SNMP to utilize SSH security services. [todo] expand as needed. SSHv2 provides PFS for encryption keys. PFS is a major design goal of SSH, and any well-designed keyex algorithm will provide it. [todo] We will probably need to discuss the security implications of Harrington, et al. Expires March 6, 2006 [Page 36] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 password based authentication methods. 8. IANA Considerations IANA is requested to assign: a TCP port number which will be the default port for SNMP over SSH sessions as defined in this document, an SMI number under mib-2, for the MIB module in this document, an SNMP SecurityModel for the Secure Shell Security Model, as documented in the MIB module in this document, 9. Acknowledgments The editors would like to thank Jeffrey Hutzelman and Nicholas Williams for sharing their SSH insights. 10. References 10.1 Normative References [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 SNMP", STD 62, RFC 3412, 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. [RFC3417] Presuhn (Editor), R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. [RFC3430] Schoenwaelder, J., "Simple Network Management Protocol (SNMP) over Transmission Control Protocol (TCP) Transport Mapping", RFC 3430, December 2002. [TMSM] Harrington, D. and J. Schoenwaelder, "Transport Mapping Security Model (TMSM) for the Simple Network Management Protocol version 3 (SNMPv3)", draft-schoenw-snmp-tlsm-04.txt (work in progress), August 2005. [SSHArch] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", Harrington, et al. Expires March 6, 2006 [Page 37] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 draft-ietf-secsh-architecture-22 (work in progress), March 2005. [SSHTrans] Lonvick, C., "SSH Transport Layer Protocol", draft-ietf-secsh-transport-24 (work in progress), March 2005. [SSHAuth] Lonvick, C. and T. Ylonen, "SSH Authentication Protocol", draft-ietf-secsh-userauth-27 (work in progress), March 2005. [SSHConnect] Lonvick, C. and T. Ylonen, "SSH Connection Protocol", draft-ietf-secsh-connect-25 (work in progress), March 2005. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [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. 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. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [Netconf] Enns, R., "NETCONF Configuration Protocol", ID draft-ietf-netconf-prot-04.txt, October 2004. [NetconfSSH] Wasserman, M. and T. Goddard, "Using the NETCONF Harrington, et al. Expires March 6, 2006 [Page 38] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 Configuration Protocol over Secure Shell (SSH)", draft-ietf-netconf-ssh-04 (work in progress), April 2005. [gsskeyex] Hutzelman, J., "GSSAPI Authentication and Key Exchange for the Secure Shell Protocol", draft-ietf-secsh-gsskeyex-09 (work in progress), May 2005. Authors' Addresses David Harrington Effective Software Harding Rd Portsmouth NH USA Phone: +1 603 436 8634 Email: dbharrington@comcast.net Juergen Schoenwaelder International University Bremen Campus Ring 1 28725 Bremen Germany Phone: +49 421 200-3587 Email: j.schoenwaelder@iu-bremen.de Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 USA Email: jsalowey@cisco.com Appendix A. Change Log from the first revision of -00- re-ordered the sections from abstract to concrete. worked on how the SSHSM fitsinto the RFC3411 and TMSM architectures. added goals tot he Motivation section. worked on Security Capabilities based on input from Joe, Nick, and JHutz. Added Joe to the authors list based on contributed text. Harrington, et al. Expires March 6, 2006 [Page 39] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 created Data origin Authentication section, to separate this discussion. expanded "Authentication Protocol" section Updated Message replay section. worked on security information cacheing, including breaking caches into session, message, and model-independent (which we may want to remerge later) eliminated a lot of TMSM-carryover stuff and modified to be SSHSM- specific. updated references. Harrington, et al. Expires March 6, 2006 [Page 40] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Harrington, et al. Expires March 6, 2006 [Page 41] =0C ------=_NextPart_000_04FD_01C5B399.85FB3C10 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_04FD_01C5B399.85FB3C10-- From isms-bounces@lists.ietf.org Wed Sep 07 16:21:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED6Qc-00084M-5N; Wed, 07 Sep 2005 16:21:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED6QX-0007vd-I2; Wed, 07 Sep 2005 16:21:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19324; Wed, 7 Sep 2005 16:21:47 -0400 (EDT) Message-Id: <200509072021.QAA19324@ietf.org> From: The IESG To: IETF-Announce@ietf.org Date: Wed, 07 Sep 2005 16:21:47 -0400 Cc: isms@ietf.org Subject: [Isms] WG Review: Recharter of Integrated Security Model for SNMP (isms) X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org A modified charter has been submitted for the Integrated Security Model for SNMP (isms) working group in the Security Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by September 14. +++ Integrated Security Model for SNMP (isms) ========================================= Current Status: Active Working Group Chair(s): Ken Hornstein Juergen Quittek Security Area Director(s): Sam Hartman Russell Housley Security Area Advisor: Sam Hartman Mailing Lists: General discussion: isms@ietf.org To (un)subscribe: isms-request@ietf.org in body: (un)subscribe Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html Description of Working Group: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem, for which there is one currently defined model - the User-based Security Model (USM). However, the USM approach has seen limited deployment so far. One frequently reported reasons is the lack of integration of USM key and user management into deployed authentication infrastructures. SSH is a widely deployed access protocol for remote devices configuration. Many devices support the integration of SSH user authentication with AAA systems via protocols such as RADIUS. The goal of the ISMS working group is developing a new security model for SNMP that integrates with widely deployed user and key management systems, as a supplement to the USM security model. For this integration the working group will define a standard method for mapping from AAA-provisioned authorization parameter(s) to corresponding SNMP parameters. In order to leverage the authentication information already accessible at managed devices, the new security model will use the SSH protocol for message protection, and RADIUS for AAA-provisioned user authentication and authorization. However, the integration of a transport mapping security model into the SNMPv3 architecture should be defined such that it is open to support potential alternative transport mappings to protocols such as BEEP and TLS. The new security model must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). Work on new access control models or centralized administration of View-based Access Control Model (VACM) rules and mappings is outside the scope of the working group. The working group will cover the following work items: - Specify an architectural extension that describes how transport mapping security models (TMSMs) fit into the SNMPv3 architecture. - Specify an architectural extension that describes how to perform a mapping from AAA-provisioned user-authentication and authorization parameter(s)to securityName and other corresponding SNMP parameters. - Specify a mapping from RADIUS-provisioned authentication and authorization parameter(s) to securityName and other corresponding SNMP parameters. This item may be a RADEXT work item last-aclled in both groups. - Specify a mapping from locally-provisioned authentication and authorization parameter(s) to securityName and other corresponding SNMP parameters. - Define how to use SSH between the two SNMP engines - Specify the SSH security model for SNMP. Goals an Milestones: Oct 2005 Initial version of a general transport mapping security models (TMSMs) document that specifies how TMSMs fit into the SNMPv3 architecture and that defines the requirements for transport mapping security models. Oct 2005 Initial version of a document specifying the SSH security model for SNMP. Dec 2006 Initial version of a document specifying the RADIUS authentication and authorization mapping model for SNMP. Feb 2006 Initial version of an applicability statement that sets up reasonable mandatory to implement methods. Feb 2006 Submit TMSM document to IESG Jun 2006 Submit SSH TMSM to IESG Jun 2006 Submit RADIUS mapping model for SNMP to IESG Aug 2006 Submit applicability statement to IESG _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Sep 12 03:15:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEiWt-0007Ap-WB; Mon, 12 Sep 2005 03:15:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEiWq-00079H-RC; Mon, 12 Sep 2005 03:15:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00717; Mon, 12 Sep 2005 03:14:59 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEiaz-00025a-PL; Mon, 12 Sep 2005 03:19:18 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 12 Sep 2005 00:14:51 -0700 X-IronPort-AV: i="3.97,98,1125903600"; d="scan'208"; a="211137260:sNHT34067112" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8C7EhKC026555; Mon, 12 Sep 2005 00:14:44 -0700 (PDT) Received: from [212.254.247.4] (ams-clip-vpn-dhcp4556.cisco.com [10.61.81.203]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j8C7RUA3011185; Mon, 12 Sep 2005 00:27:30 -0700 Message-ID: <43252AE6.7000704@cisco.com> Date: Mon, 12 Sep 2005 09:14:46 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: iesg@ietf.org Subject: Re: [Isms] WG Review: Recharter of Integrated Security Model for SNMP (isms) References: <200509072021.QAA19324@ietf.org> In-Reply-To: <200509072021.QAA19324@ietf.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=4168; t=1126510052; x=1126942252; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20WG=20Review=3A=20Recharter=20of=20Integrated=20Security =20Model=20for=0A=20SNMP=09(isms)| From:Eliot=20Lear=20| Date:Mon,=2012=20Sep=202005=2009=3A14=3A46=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=WS9gmcCyV2zoHewODrex02V7etu1/71Zk82wFGOz+YRnh2z4HqYHS4HhQQCcPDZcOazlEhP+ 0tIhzGfQDyeGUGrft5BPkDSE58QTvFW0kd1CtJbLSFZ9AjmLb1FGB8ShFxhyoloIsSZI+fjjexA enIRgWDJnGUXc8+GrEIaY16s= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I request an extension of the deadline for comments to September 21st on the following basis: - the period of comment has been less than a week, far shorter than the normal period of IETF-wide review. - of the time allotted, the principle instigator of this review has been absent from debate for five days due to prior commitments. That was me. Thank you, Eliot The IESG wrote: > A modified charter has been submitted for the Integrated Security Model for SNMP (isms) > working group in the Security Area of the IETF. The IESG has not made any > determination as yet. The modified charter is provided below for informational > purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) > by September 14. > > +++ > > Integrated Security Model for SNMP (isms) > ========================================= > > Current Status: Active Working Group > > Chair(s): > Ken Hornstein > Juergen Quittek > > Security Area Director(s): > Sam Hartman > Russell Housley > > Security Area Advisor: > Sam Hartman > > Mailing Lists: > General discussion: isms@ietf.org > To (un)subscribe: isms-request@ietf.org > in body: (un)subscribe > Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html > > Description of Working Group: > > The Simple Network Management Protocol version 3 (SNMPv3) provides > message security services through the security subsystem, for which > there is one currently defined model - the User-based Security Model > (USM). However, the USM approach has seen limited deployment so far. > One frequently reported reasons is the lack of integration of USM > key and user management into deployed authentication infrastructures. > > SSH is a widely deployed access protocol for remote devices configuration. > Many devices support the integration of SSH user authentication with > AAA systems via protocols such as RADIUS. > > The goal of the ISMS working group is developing a new security model > for SNMP that integrates with widely deployed user and key management > systems, as a supplement to the USM security model. > > For this integration the working group will define a standard method > for mapping from AAA-provisioned authorization parameter(s) to > corresponding SNMP parameters. > > In order to leverage the authentication information already accessible > at managed devices, the new security model will use the SSH protocol > for message protection, and RADIUS for AAA-provisioned user authentication > and authorization. > However, the integration of a transport mapping security model into > the SNMPv3 architecture should be defined such that it is open to support > potential alternative transport mappings to protocols such as BEEP and TLS. > > The new security model must not modify any other aspects of SNMPv3 > protocol as defined in STD 62 (e.g., it must not create new PDU types). > > Work on new access control models or centralized administration of > View-based Access Control Model (VACM) rules and mappings is outside > the scope of the working group. > > The working group will cover the following work items: > > - Specify an architectural extension that describes how transport > mapping security models (TMSMs) fit into the SNMPv3 architecture. > - Specify an architectural extension that describes how to perform a > mapping from AAA-provisioned user-authentication and authorization > parameter(s)to securityName and other corresponding SNMP parameters. > - Specify a mapping from RADIUS-provisioned authentication and > authorization parameter(s) to securityName and other corresponding > SNMP parameters. This item may be a RADEXT work item last-aclled > in both groups. > - Specify a mapping from locally-provisioned authentication and > authorization parameter(s) to securityName and other corresponding > SNMP parameters. > - Define how to use SSH between the two SNMP engines > - Specify the SSH security model for SNMP. > > Goals an Milestones: > > Oct 2005 Initial version of a general transport mapping security models > (TMSMs) document that specifies how TMSMs fit into the SNMPv3 > architecture and that defines the requirements for transport > mapping security models. > Oct 2005 Initial version of a document specifying the SSH security > model for SNMP. > Dec 2006 Initial version of a document specifying the RADIUS > authentication and authorization mapping model for SNMP. > Feb 2006 Initial version of an applicability statement that sets up > reasonable mandatory to implement methods. > Feb 2006 Submit TMSM document to IESG > Jun 2006 Submit SSH TMSM to IESG > Jun 2006 Submit RADIUS mapping model for SNMP to IESG > Aug 2006 Submit applicability statement to IESG > > > _______________________________________________ > 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 12 09:38:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEoWL-0006kh-5C; Mon, 12 Sep 2005 09:38:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEnga-00060S-Bm; Mon, 12 Sep 2005 08:45:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15472; Mon, 12 Sep 2005 08:45:23 -0400 (EDT) Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEnkm-0002Mo-1t; Mon, 12 Sep 2005 08:49:44 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j8CCikHp167088; Mon, 12 Sep 2005 13:44:48 +0100 Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8CCifZm128390; Mon, 12 Sep 2005 13:44:41 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j8CCiePm030794; Mon, 12 Sep 2005 13:44:40 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j8CCidgr030749; Mon, 12 Sep 2005 13:44:39 +0100 Received: from zurich.ibm.com (sig-9-145-250-246.de.ibm.com [9.145.250.246]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA69430; Mon, 12 Sep 2005 14:44:38 +0200 Message-ID: <43257835.4080405@zurich.ibm.com> Date: Mon, 12 Sep 2005 14:44:37 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Eliot Lear Subject: Re: [Isms] WG Review: Recharter of Integrated Security Model for SNMP (isms) References: <200509072021.QAA19324@ietf.org> <43252AE6.7000704@cisco.com> In-Reply-To: <43252AE6.7000704@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 12 Sep 2005 09:38:52 -0400 Cc: iesg@ietf.org, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Acually, the normal review period for re-charters does tend to be short, so as to fit between two successive IESG telechat. The question is whether everyone who has an opinion has had a chance to express it. Brian Eliot Lear wrote: > I request an extension of the deadline for comments to September 21st on > the following basis: > > - the period of comment has been less than a week, far shorter than > the normal period of IETF-wide review. > - of the time allotted, the principle instigator of this review has > been absent from debate for five days due to prior commitments. > That was me. > > Thank you, > > Eliot > > The IESG wrote: > >>A modified charter has been submitted for the Integrated Security Model for SNMP (isms) >>working group in the Security Area of the IETF. The IESG has not made any >>determination as yet. The modified charter is provided below for informational >>purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) >>by September 14. >> >>+++ >> >>Integrated Security Model for SNMP (isms) >>========================================= >> >>Current Status: Active Working Group >> >>Chair(s): >>Ken Hornstein >>Juergen Quittek >> >>Security Area Director(s): >>Sam Hartman >>Russell Housley >> >>Security Area Advisor: >>Sam Hartman >> >>Mailing Lists: >>General discussion: isms@ietf.org >>To (un)subscribe: isms-request@ietf.org >>in body: (un)subscribe >>Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html >> >>Description of Working Group: >> >>The Simple Network Management Protocol version 3 (SNMPv3) provides >>message security services through the security subsystem, for which >>there is one currently defined model - the User-based Security Model >>(USM). However, the USM approach has seen limited deployment so far. >>One frequently reported reasons is the lack of integration of USM >>key and user management into deployed authentication infrastructures. >> >>SSH is a widely deployed access protocol for remote devices configuration. >>Many devices support the integration of SSH user authentication with >>AAA systems via protocols such as RADIUS. >> >>The goal of the ISMS working group is developing a new security model >>for SNMP that integrates with widely deployed user and key management >>systems, as a supplement to the USM security model. >> >>For this integration the working group will define a standard method >>for mapping from AAA-provisioned authorization parameter(s) to >>corresponding SNMP parameters. >> >>In order to leverage the authentication information already accessible >>at managed devices, the new security model will use the SSH protocol >>for message protection, and RADIUS for AAA-provisioned user authentication >>and authorization. >>However, the integration of a transport mapping security model into >>the SNMPv3 architecture should be defined such that it is open to support >>potential alternative transport mappings to protocols such as BEEP and TLS. >> >>The new security model must not modify any other aspects of SNMPv3 >>protocol as defined in STD 62 (e.g., it must not create new PDU types). >> >>Work on new access control models or centralized administration of >>View-based Access Control Model (VACM) rules and mappings is outside >>the scope of the working group. >> >>The working group will cover the following work items: >> >>- Specify an architectural extension that describes how transport >>mapping security models (TMSMs) fit into the SNMPv3 architecture. >>- Specify an architectural extension that describes how to perform a >>mapping from AAA-provisioned user-authentication and authorization >>parameter(s)to securityName and other corresponding SNMP parameters. >>- Specify a mapping from RADIUS-provisioned authentication and >>authorization parameter(s) to securityName and other corresponding >>SNMP parameters. This item may be a RADEXT work item last-aclled >>in both groups. >>- Specify a mapping from locally-provisioned authentication and >>authorization parameter(s) to securityName and other corresponding >>SNMP parameters. >>- Define how to use SSH between the two SNMP engines >>- Specify the SSH security model for SNMP. >> >>Goals an Milestones: >> >>Oct 2005 Initial version of a general transport mapping security models >>(TMSMs) document that specifies how TMSMs fit into the SNMPv3 >>architecture and that defines the requirements for transport >>mapping security models. >>Oct 2005 Initial version of a document specifying the SSH security >>model for SNMP. >>Dec 2006 Initial version of a document specifying the RADIUS >>authentication and authorization mapping model for SNMP. >>Feb 2006 Initial version of an applicability statement that sets up >>reasonable mandatory to implement methods. >>Feb 2006 Submit TMSM document to IESG >>Jun 2006 Submit SSH TMSM to IESG >>Jun 2006 Submit RADIUS mapping model for SNMP to IESG >>Aug 2006 Submit applicability statement to IESG >> >> >>_______________________________________________ >>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 12 12:38:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EErKC-00011f-4Y; Mon, 12 Sep 2005 12:38:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EErKA-0000uk-PA; Mon, 12 Sep 2005 12:38:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00615; Mon, 12 Sep 2005 12:38:18 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EErOC-0001Ab-S4; Mon, 12 Sep 2005 12:42:43 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id EA0B7E0049; Mon, 12 Sep 2005 12:38:17 -0400 (EDT) To: Eliot Lear Subject: Re: [Isms] WG Review: Recharter of Integrated Security Model for SNMP (isms) References: <200509072021.QAA19324@ietf.org> <43252AE6.7000704@cisco.com> From: Sam Hartman Date: Mon, 12 Sep 2005 12:38:17 -0400 In-Reply-To: <43252AE6.7000704@cisco.com> (Eliot Lear's message of "Mon, 12 Sep 2005 09:14:46 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: iesg@ietf.org, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Eliot" == Eliot Lear writes: Eliot> I request an extension of the deadline for comments to Eliot> September 21st on the following basis: Eliot> - the period of comment has been less than a week, far Eliot> shorter than the normal period of IETF-wide review. - of Eliot> the time allotted, the principle instigator of this review Eliot> has been absent from debate for five days due to prior Eliot> commitments. That was me. Hi, Eliot. I have not made any determination as yet about whether I will pull ISMS from the Thursday telechat and am unlikely to make a final determination until the time of that telechat. When I originally ruled call home out of scope I gave you some suggestions for how to approach things from a process standpoint. In evaluating your request I will consider how much progress has been made on these issues so far and on whether it is likely that you could make additional progress on these issues by September 21. Let us go back and consider my original advice to you: When the charter is sent to me for IESG review, ask me to send it out for external review (IETF wide) rather than just approving it; I will honor such a request. You will need a proposal ready to present to the community when the charter comes out for review. The proposal should include proposed modifications to the charter to make call home in scope. In addition you probably want to answer the following concerns: * People believe that architectural changes to SNMP should happen in the management not security area. Either convince them that this is OK in the security area, propose moving the working group, or propose splitting the work appropriately. * Address the concerns about the lack of MIBs and other facilities for managing call home. Have a proposal ready for what is involved in doing the work. * Understand concerns Bert is likely to raise and respond to them. so, here are some specific questions related to our progress to date on these items. Answering these questions will help me determine whether extending the review period to September 21 is likely to be productive. 1) Have you proposed a specific set of charter changes? Who has supported these charter changes? 2) How have you addressed the specific concerns about the location of the work ? Who has agreed with your proposed resolution? 3) Is there a consensus emerging that CH needs to be solved as part of ISMS? This is the part where additional time is most likely to help you, but I think it fair to ask who has supported blocking ISMS on CH so far. Note that people who support CH but who believe it could be done in a separate working group or who have not expressed an opinion do not count. They may well count for justifying support for a CH BOF or for justification of a publication request for an individual submission adding CH to the SNMP architecture. 4) What response have you given to concerns about whether the architectural extensions for CH are sufficiently well defined? Who has supported this proposal? 5) How are your discussions going with Bert to resolve his concerns? What about other key members of the management community who have expressed concerns? Here's how I'm going to make a decision. I believe that in order to get a change to the SNMP charter it is necessary to make significant progress on all of these issues. I'm going to evaluate your answers and consider whether I think the progress to date makes it likely that you will have sufficient support for a new charter by September 21 without significant opposition. In other words whether the community and IESG can agree to the new charter by the end of the review period. If the progress to date makes it likely that we're headed in that direction, I'll grant the request. Otherwise I will ask the IESG to approve the charter on Thursday. There's an internal issue that may well prevent the charter from being announced before the 21st even if no formal extension is granted. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Sep 12 15:53:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEuMo-0004xG-36; Mon, 12 Sep 2005 15:53:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEuMm-0004uu-5O; Mon, 12 Sep 2005 15:53:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11962; Mon, 12 Sep 2005 15:53:22 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEuR0-0007Dw-Jm; Mon, 12 Sep 2005 15:57:48 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 12 Sep 2005 12:53:12 -0700 X-IronPort-AV: i="3.97,102,1125903600"; d="scan'208"; a="340935239:sNHT35095060" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8CJr94u009211; Mon, 12 Sep 2005 12:53:10 -0700 (PDT) Received: from [212.254.247.4] (ams-clip-vpn-dhcp4541.cisco.com [10.61.81.188]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j8CK5mbr017325; Mon, 12 Sep 2005 13:05:49 -0700 Message-ID: <4325DCA2.2070400@cisco.com> Date: Mon, 12 Sep 2005 21:53:06 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman References: <200509072021.QAA19324@ietf.org> <43252AE6.7000704@cisco.com> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=5228; t=1126555551; x=1126987751; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:ISMS=20charter=20broken-=20onus=20should=20be=20on=20WG=20to=20fix=20it| From:Eliot=20Lear=20| Date:Mon,=2012=20Sep=202005=2021=3A53=3A06=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=E9IqOZOZrawqsH/djvp3Hia4Dn/z3zssdRSCka8qSVzzQ4mLU5OfMDLSxkHTlbI4Qy34pNYi JtMB3RAc5IA+HPNtt0VcLV2flNoqhuFbts00NJ3FTQndk25aYnmAJ7sx4EGF01P3p+HhCX0HwJC YA7y09dklGvN6qF/5XIU4RCc= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: 7bit Cc: IETF Discussion , iesg@ietf.org, isms@ietf.org Subject: [Isms] ISMS charter broken- onus should be on WG to fix it X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Sam, I believe the approach you have proposed is quite simply wrong. As an AD you're supposed to provide technical oversight and not simply hold a popularity contest. If you have technical questions or wish to challenge me on a technical point, I think that's fair game. As I've written, the path we are headed down technically will not work in the face of firewalls and NATs, and nobody has refuted this. Furthermore you've heard from a reasonably large customer (Boeing) as well as your predecessor on the prevalence of such middle boxes that demonstrates the complexity of today's environment and the need for this sort of functionality as part of the solution. You've heard from an author of SNMP that the major architectural change is the use of session based security and NOT CH, the same from the former O&M AD and IETF chair. You've heard from a service provider as well as numerous members of the community who see the problem. You may or may not have yet heard from other standards bodies but if you were to delay it is quite possible they will chime in since one was specifically interested in this sort of function. The amount of changes required to support CH cannot fully be ascertained until more of the the [Todo]s are filled in with Dave's draft, but I don't imagine the work would be much more than: - specifying how to initiate the connection and if necessary turn it - the identity used for requests received from command generators that did not initiate the connection along with potential prepopulating of various tables - an appendix of how the SNMP-TARGET-MIB would be populated - a discussion on when to initiate connections and what to do when they fail (mind you this is needed anyway regardless of CH) - security considerations involving firewalls, blocking, etc. - possibly one additional table describing the state of SSH peer connectivity (which probably wouldn't be bad to have anyway). Decide for yourself if you think this is a substantial amount of text, but I won't leave it to your imagination for long. I will attempt this week to post a derivative of the draft that Dave is working on to give people an idea of what the changes would be. Again it's difficult to diff an incomplete specification. Eliot >>>>>>>>>>> "Eliot" == Eliot Lear writes: > > > Eliot> I request an extension of the deadline for comments to > Eliot> September 21st on the following basis: > > Eliot> - the period of comment has been less than a week, far > Eliot> shorter than the normal period of IETF-wide review. - of > Eliot> the time allotted, the principle instigator of this review > Eliot> has been absent from debate for five days due to prior > Eliot> commitments. That was me. > > Hi, Eliot. I have not made any determination as yet about whether I > will pull ISMS from the Thursday telechat and am unlikely to make a > final determination until the time of that telechat. > > > When I originally ruled call home out of scope I gave you some > suggestions for how to approach things from a process standpoint. In > evaluating your request I will consider how much progress has been > made on these issues so far and on whether it is likely that you could > make additional progress on these issues by September 21. > > Let us go back and consider my original advice to you: > > When the charter is sent to me for IESG review, ask me to send it out > for external review (IETF wide) rather than just approving it; I will > honor such a request. You will need a proposal ready to present to > the community when the charter comes out for review. The proposal > should include proposed modifications to the charter to make call home > in scope. In addition you probably want to answer the following > concerns: > > * People believe that architectural changes to SNMP should happen in > the management not security area. Either convince them that this is > OK in the security area, propose moving the working group, or > propose splitting the work appropriately. > > * Address the concerns about the lack of MIBs and other facilities for > managing call home. Have a proposal ready for what is involved in > doing the work. > > > * Understand concerns Bert is likely to raise and respond to them. > > > > so, here are some specific questions related to our progress to date > on these items. Answering these questions will help me determine > whether extending the review period to September 21 is likely to be > productive. > > 1) Have you proposed a specific set of charter changes? Who has > supported these charter changes? > > 2) How have you addressed the specific concerns about the location of > the work ? Who has agreed with your proposed resolution? > > 3) Is there a consensus emerging that CH needs to be solved as part of > ISMS? This is the part where additional time is most likely to > help you, but I think it fair to ask who has supported blocking > ISMS on CH so far. Note that people who support CH but who > believe it could be done in a separate working group or who have > not expressed an opinion do not count. They may well count for > justifying support for a CH BOF or for justification of a > publication request for an individual submission adding CH to the > SNMP architecture. > > > 4) What response have you given to concerns about whether the > architectural extensions for CH are sufficiently well defined? Who > has supported this proposal? > > > > 5) How are your discussions going with Bert to resolve his concerns? > What about other key members of the management community who have > expressed concerns? > > > > Here's how I'm going to make a decision. I believe that in order to > get a change to the SNMP charter it is necessary to make significant > progress on all of these issues. I'm going to evaluate your answers > and consider whether I think the progress to date makes it likely that > you will have sufficient support for a new charter by September 21 > without significant opposition. In other words whether the community > and IESG can agree to the new charter by the end of the review period. > If the progress to date makes it likely that we're headed in that > direction, I'll grant the request. Otherwise I will ask the IESG to > approve the charter on Thursday. > > > There's an internal issue that may well prevent the charter from being > announced before the 21st even if no formal extension is granted. > > > --Sam > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Sep 12 23:36:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF1aT-0002sj-1A; Mon, 12 Sep 2005 23:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EExJp-0000rs-Oq; Mon, 12 Sep 2005 19:02:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07622; Mon, 12 Sep 2005 19:02:19 -0400 (EDT) Message-Id: <200509122302.TAA07622@ietf.org> Received: from rwcrmhc13.comcast.net ([216.148.227.118] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EExNw-0000dz-1O; Mon, 12 Sep 2005 19:06:48 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <2005091223021101500ispj1e>; Mon, 12 Sep 2005 23:02:12 +0000 From: "David B Harrington" To: "'Eliot Lear'" , "'Sam Hartman'" Subject: RE: [Isms] ISMS charter broken- onus should be on WG to fix it Date: Mon, 12 Sep 2005 19:02:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW34RbrjggwIpl5Rg6XW9p29PZUnwAA7ktg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <4325DCA2.2070400@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org, 'IETF Discussion' , iesg@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, As primary editor of the SSH draft (SSHSM), I spoke with Eliot last week. I agree that it is difficult for him to develop a reasonable proposal that piggybacks on the SSH draft, because the SSH draft is so incomplete. I am not convinced that SNMP needs to add a new call-home (CH) functionality, nor that this feature is needed in SNMP now, but there is a danger that CH might never be possible if we don't consider its impact on the SSHSM model before SSHSM is cast in stone. If it complicates the SSHSM model, I would prefer to not include it; a new model could be developed to replace or supplement the SSHSM model if demand increases for this functionality. I recommended to Eliot that he contribute some text for the SSH document, describing the CH functionality and proposed elements of procedure, that I could include as an appendix to the SSHSM document so the WG could review his proposal, and then the WG could decide whether it should remain as an appendix, be incorporated into the SSH document, be split out as a separate document, or be abandoned altogether. I felt this was a reasonable alternative to making the decision whether CH is or is not in scope at this time. He has not yet had a chance to develop the text and send it to me. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Eliot Lear > Sent: Monday, September 12, 2005 3:53 PM > To: Sam Hartman > Cc: IETF Discussion; iesg@ietf.org; isms@ietf.org > Subject: [Isms] ISMS charter broken- onus should be on WG to fix it > > Sam, > > I believe the approach you have proposed is quite simply wrong. As an > AD you're supposed to provide technical oversight and not > simply hold a > popularity contest. If you have technical questions or wish to > challenge me on a technical point, I think that's fair game. > > As I've written, the path we are headed down technically will not work > in the face of firewalls and NATs, and nobody has refuted this. > > Furthermore you've heard from a reasonably large customer (Boeing) as > well as your predecessor on the prevalence of such middle boxes that > demonstrates the complexity of today's environment and the > need for this > sort of functionality as part of the solution. > > You've heard from an author of SNMP that the major > architectural change > is the use of session based security and NOT CH, the same from the > former O&M AD and IETF chair. You've heard from a service provider as > well as numerous members of the community who see the problem. > > You may or may not have yet heard from other standards bodies > but if you > were to delay it is quite possible they will chime in since one was > specifically interested in this sort of function. > > The amount of changes required to support CH cannot fully be > ascertained > until more of the the [Todo]s are filled in with Dave's draft, but I > don't imagine the work would be much more than: > > - specifying how to initiate the connection and if necessary turn it > - the identity used for requests received from command > generators that > did not initiate the connection along with potential prepopulating > of various tables > - an appendix of how the SNMP-TARGET-MIB would be populated > - a discussion on when to initiate connections and what to do when > they fail (mind you this is needed anyway regardless of CH) > - security considerations involving firewalls, blocking, etc. > - possibly one additional table describing the state of SSH peer > connectivity (which probably wouldn't be bad to have anyway). > > Decide for yourself if you think this is a substantial amount of text, > but I won't leave it to your imagination for long. I will > attempt this > week to post a derivative of the draft that Dave is working on to give > people an idea of what the changes would be. > > Again it's difficult to diff an incomplete specification. > > Eliot > > >>>>>>>>>>> "Eliot" == Eliot Lear writes: > > > > > > Eliot> I request an extension of the deadline for comments to > > Eliot> September 21st on the following basis: > > > > Eliot> - the period of comment has been less than a week, far > > Eliot> shorter than the normal period of IETF-wide review. - of > > Eliot> the time allotted, the principle instigator of > this review > > Eliot> has been absent from debate for five days due to prior > > Eliot> commitments. That was me. > > > > Hi, Eliot. I have not made any determination as yet about whether I > > will pull ISMS from the Thursday telechat and am unlikely to make a > > final determination until the time of that telechat. > > > > > > When I originally ruled call home out of scope I gave you some > > suggestions for how to approach things from a process > standpoint. In > > evaluating your request I will consider how much progress has been > > made on these issues so far and on whether it is likely > that you could > > make additional progress on these issues by September 21. > > > > Let us go back and consider my original advice to you: > > > > When the charter is sent to me for IESG review, ask me to > send it out > > for external review (IETF wide) rather than just > approving it; I will > > honor such a request. You will need a proposal ready to > present to > > the community when the charter comes out for review. The proposal > > should include proposed modifications to the charter to > make call home > > in scope. In addition you probably want to answer the following > > concerns: > > > > * People believe that architectural changes to SNMP > should happen in > > the management not security area. Either convince them > that this is > > OK in the security area, propose moving the working group, or > > propose splitting the work appropriately. > > > > * Address the concerns about the lack of MIBs and other > facilities for > > managing call home. Have a proposal ready for what is > involved in > > doing the work. > > > > > > * Understand concerns Bert is likely to raise and respond to them. > > > > > > > > so, here are some specific questions related to our progress to date > > on these items. Answering these questions will help me determine > > whether extending the review period to September 21 is likely to be > > productive. > > > > 1) Have you proposed a specific set of charter changes? Who has > > supported these charter changes? > > > > 2) How have you addressed the specific concerns about the > location of > > the work ? Who has agreed with your proposed resolution? > > > > 3) Is there a consensus emerging that CH needs to be solved > as part of > > ISMS? This is the part where additional time is most likely to > > help you, but I think it fair to ask who has supported blocking > > ISMS on CH so far. Note that people who support CH but who > > believe it could be done in a separate working group or who have > > not expressed an opinion do not count. They may well count for > > justifying support for a CH BOF or for justification of a > > publication request for an individual submission adding > CH to the > > SNMP architecture. > > > > > > 4) What response have you given to concerns about whether the > > architectural extensions for CH are sufficiently well > defined? Who > > has supported this proposal? > > > > > > > > 5) How are your discussions going with Bert to resolve his concerns? > > What about other key members of the management > community who have > > expressed concerns? > > > > > > > > Here's how I'm going to make a decision. I believe that in order to > > get a change to the SNMP charter it is necessary to make significant > > progress on all of these issues. I'm going to evaluate your answers > > and consider whether I think the progress to date makes it > likely that > > you will have sufficient support for a new charter by September 21 > > without significant opposition. In other words whether the > community > > and IESG can agree to the new charter by the end of the > review period. > > If the progress to date makes it likely that we're headed in that > > direction, I'll grant the request. Otherwise I will ask the IESG to > > approve the charter on Thursday. > > > > > > There's an internal issue that may well prevent the charter > from being > > announced before the 21st even if no formal extension is granted. > > > > > > --Sam > > > > > > _______________________________________________ > 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 13 10:43:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFC0O-0000Zs-Cv; Tue, 13 Sep 2005 10:43:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEymm-00032F-Pe; Mon, 12 Sep 2005 20:36:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10321; Mon, 12 Sep 2005 20:36:31 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEyr2-0002P4-PZ; Mon, 12 Sep 2005 20:40:59 -0400 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 41C951BAC4D; Tue, 13 Sep 2005 02:36:20 +0200 (CEST) Date: Tue, 13 Sep 2005 02:36:26 +0200 From: Juergen Quittek To: Eliot Lear , Sam Hartman Subject: Re: [Isms] ISMS charter broken- onus should be on WG to fix it Message-ID: <56410FF569BC2359E7BBA4E4@[192.168.0.112]> In-Reply-To: <4325DCA2.2070400@cisco.com> References: <200509072021.QAA19324@ietf.org> <43252AE6.7000704@cisco.com> <4325DCA2.2070400@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org, IETF Discussion , iesg@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Eliot, At the SBSM and ISMS BoF sessions at IETF 58 and 60 the need for integrating SNMP into existing security frameworks was extensively discussed. Wes presented the issue at NANOG and performed a survey among operators. The output of all this work is the idenitfication of a well founded general requirement for working on the integration of SNMP into existing security frameworks in an IETF working group. Now you claim that solving this issue is technically wrong without considering a different problem that you call "call home". Rather you request adding the issue of solving the "call home" to the ISMS charter. However, nobody raised this issue at the ISMS BoFs nor has the issue been discussed in depth in the OaM area. But we should have such a discussion before adding the issue to any IETF WG charter. It looks like a good topic for a BoF session in the OaM area. There we could find out the relevance of the problem and discuss requirements for potential solutions. Also there we can identify which working group would be the right one to deal with the issue. But until then, I propose that we let the ISMS group work on solving its original problem. Thanks, Juergen --On 9/12/2005 9:53 PM +0200 Eliot Lear wrote: > Sam, > > I believe the approach you have proposed is quite simply wrong. As an > AD you're supposed to provide technical oversight and not simply hold a > popularity contest. If you have technical questions or wish to > challenge me on a technical point, I think that's fair game. > > As I've written, the path we are headed down technically will not work > in the face of firewalls and NATs, and nobody has refuted this. > > Furthermore you've heard from a reasonably large customer (Boeing) as > well as your predecessor on the prevalence of such middle boxes that > demonstrates the complexity of today's environment and the need for this > sort of functionality as part of the solution. > > You've heard from an author of SNMP that the major architectural change > is the use of session based security and NOT CH, the same from the > former O&M AD and IETF chair. You've heard from a service provider as > well as numerous members of the community who see the problem. > > You may or may not have yet heard from other standards bodies but if you > were to delay it is quite possible they will chime in since one was > specifically interested in this sort of function. > > The amount of changes required to support CH cannot fully be ascertained > until more of the the [Todo]s are filled in with Dave's draft, but I > don't imagine the work would be much more than: > > - specifying how to initiate the connection and if necessary turn it > - the identity used for requests received from command generators that > did not initiate the connection along with potential prepopulating > of various tables > - an appendix of how the SNMP-TARGET-MIB would be populated > - a discussion on when to initiate connections and what to do when > they fail (mind you this is needed anyway regardless of CH) > - security considerations involving firewalls, blocking, etc. > - possibly one additional table describing the state of SSH peer > connectivity (which probably wouldn't be bad to have anyway). > > Decide for yourself if you think this is a substantial amount of text, > but I won't leave it to your imagination for long. I will attempt this > week to post a derivative of the draft that Dave is working on to give > people an idea of what the changes would be. > > Again it's difficult to diff an incomplete specification. > > Eliot > >>>>>>>>>>>> "Eliot" == Eliot Lear writes: >> >> >> Eliot> I request an extension of the deadline for comments to >> Eliot> September 21st on the following basis: >> >> Eliot> - the period of comment has been less than a week, far >> Eliot> shorter than the normal period of IETF-wide review. - of >> Eliot> the time allotted, the principle instigator of this review >> Eliot> has been absent from debate for five days due to prior >> Eliot> commitments. That was me. >> >> Hi, Eliot. I have not made any determination as yet about whether I >> will pull ISMS from the Thursday telechat and am unlikely to make a >> final determination until the time of that telechat. >> >> >> When I originally ruled call home out of scope I gave you some >> suggestions for how to approach things from a process standpoint. In >> evaluating your request I will consider how much progress has been >> made on these issues so far and on whether it is likely that you could >> make additional progress on these issues by September 21. >> >> Let us go back and consider my original advice to you: >> >> When the charter is sent to me for IESG review, ask me to send it out >> for external review (IETF wide) rather than just approving it; I will >> honor such a request. You will need a proposal ready to present to >> the community when the charter comes out for review. The proposal >> should include proposed modifications to the charter to make call home >> in scope. In addition you probably want to answer the following >> concerns: >> >> * People believe that architectural changes to SNMP should happen in >> the management not security area. Either convince them that this is >> OK in the security area, propose moving the working group, or >> propose splitting the work appropriately. >> >> * Address the concerns about the lack of MIBs and other facilities for >> managing call home. Have a proposal ready for what is involved in >> doing the work. >> >> >> * Understand concerns Bert is likely to raise and respond to them. >> >> >> >> so, here are some specific questions related to our progress to date >> on these items. Answering these questions will help me determine >> whether extending the review period to September 21 is likely to be >> productive. >> >> 1) Have you proposed a specific set of charter changes? Who has >> supported these charter changes? >> >> 2) How have you addressed the specific concerns about the location of >> the work ? Who has agreed with your proposed resolution? >> >> 3) Is there a consensus emerging that CH needs to be solved as part of >> ISMS? This is the part where additional time is most likely to >> help you, but I think it fair to ask who has supported blocking >> ISMS on CH so far. Note that people who support CH but who >> believe it could be done in a separate working group or who have >> not expressed an opinion do not count. They may well count for >> justifying support for a CH BOF or for justification of a >> publication request for an individual submission adding CH to the >> SNMP architecture. >> >> >> 4) What response have you given to concerns about whether the >> architectural extensions for CH are sufficiently well defined? Who >> has supported this proposal? >> >> >> >> 5) How are your discussions going with Bert to resolve his concerns? >> What about other key members of the management community who have >> expressed concerns? >> >> >> >> Here's how I'm going to make a decision. I believe that in order to >> get a change to the SNMP charter it is necessary to make significant >> progress on all of these issues. I'm going to evaluate your answers >> and consider whether I think the progress to date makes it likely that >> you will have sufficient support for a new charter by September 21 >> without significant opposition. In other words whether the community >> and IESG can agree to the new charter by the end of the review period. >> If the progress to date makes it likely that we're headed in that >> direction, I'll grant the request. Otherwise I will ask the IESG to >> approve the charter on Thursday. >> >> >> There's an internal issue that may well prevent the charter from being >> announced before the 21st even if no formal extension is granted. >> >> >> --Sam >> > > > > _______________________________________________ > 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 13 15:31:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGUf-0003cc-Gh; Tue, 13 Sep 2005 15:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF4RM-0007tX-1V; Tue, 13 Sep 2005 02:38:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06175; Tue, 13 Sep 2005 02:38:45 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EF4Vg-0001bf-VY; Tue, 13 Sep 2005 02:43:17 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 12 Sep 2005 23:38:37 -0700 X-IronPort-AV: i="3.97,104,1125903600"; d="scan'208"; a="659426397:sNHT36429844" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8D6cWKC026791; Mon, 12 Sep 2005 23:38:33 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp4354.cisco.com [10.61.81.1]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j8D6pBoa021183; Mon, 12 Sep 2005 23:51:11 -0700 Message-ID: <432673E6.1020603@cisco.com> Date: Tue, 13 Sep 2005 08:38:30 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [Isms] ISMS charter broken- onus should be on WG to fix it References: <200509072021.QAA19324@ietf.org> <43252AE6.7000704@cisco.com> <4325DCA2.2070400@cisco.com> <56410FF569BC2359E7BBA4E4@[192.168.0.112]> In-Reply-To: <56410FF569BC2359E7BBA4E4@[192.168.0.112]> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=7823; t=1126594274; x=1127026474; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20ISMS=20charter=20broken-=20onus=20should=20be=20on=20WG =20to=20fix=20it| From:Eliot=20Lear=20| Date:Tue,=2013=20Sep=202005=2008=3A38=3A30=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=PJp+Kofqr+VBkmJPtQBZGC76H7VtW6trRvSQdiAe1aU3ZX+8DobcytZt2oCZhUMBb6QDKpXo mIy57P5rVtyOpTftCoXw0GdUZ2af3aHGKOpQT2m17XR0W1jYxqAFxkkdzCb0DBIgkbIyJ5l6KKs N6ztHsh4tn/XkjkmqZthgmbg= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Content-Transfer-Encoding: 7bit Cc: isms@ietf.org, Sam Hartman , IETF Discussion , iesg@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen, Wes received the obvious feedback that operators find SNMP unusable with the USM model because they cannot integrate it with their existing security infrastructures and there is no denying that this is a real problem. But this is NOT the only problem operators face with SNMP. While the group focused on UDP-based solutions it made no sense to raise concerns about firewall and NAT traversal, because in my opinion UDP traversal would likely be no different for ISMS or non-ISMS. With TCP and SSH in particular, the group can reasonably deal with the problem with very little additional work, as I described. Because it can, it should. In other words, firewall/NAT traversal has always been a problem, but the choice of either SSH or BEEP could easily provide a means to address it. People have suggested a BoF on this subject. I am perfectly happy to hold a BoF in November on this subject if the WG and IESG are adamant that this work be done elsewhere. I suggest that it occur adjacent to the ISMS working group, so that people understand just the sort of changes that will be required between ISMS and this other thing. I would also agree with Dave that if the necessary work for CH turns out to be onerous in ISMS the the WG should reconsider. I just don't envision the premise of that statement being true. Eliot Juergen Quittek wrote: > Eliot, > > At the SBSM and ISMS BoF sessions at IETF 58 and 60 the need for > integrating SNMP into existing security frameworks was extensively > discussed. Wes presented the issue at NANOG and performed a survey > among operators. The output of all this work is the idenitfication > of a well founded general requirement for working on the integration > of SNMP into existing security frameworks in an IETF working group. > > Now you claim that solving this issue is technically wrong without > considering a different problem that you call "call home". Rather > you request adding the issue of solving the "call home" to the ISMS > charter. > > However, nobody raised this issue at the ISMS BoFs nor has the > issue been discussed in depth in the OaM area. But we should have > such a discussion before adding the issue to any IETF WG charter. > It looks like a good topic for a BoF session in the OaM area. > There we could find out the relevance of the problem and discuss > requirements for potential solutions. Also there we can identify > which working group would be the right one to deal with the issue. > > But until then, I propose that we let the ISMS group work on solving > its original problem. > > Thanks, > > Juergen > > > --On 9/12/2005 9:53 PM +0200 Eliot Lear wrote: > >> Sam, >> >> I believe the approach you have proposed is quite simply wrong. As an >> AD you're supposed to provide technical oversight and not simply hold a >> popularity contest. If you have technical questions or wish to >> challenge me on a technical point, I think that's fair game. >> >> As I've written, the path we are headed down technically will not work >> in the face of firewalls and NATs, and nobody has refuted this. >> >> Furthermore you've heard from a reasonably large customer (Boeing) as >> well as your predecessor on the prevalence of such middle boxes that >> demonstrates the complexity of today's environment and the need for this >> sort of functionality as part of the solution. >> >> You've heard from an author of SNMP that the major architectural change >> is the use of session based security and NOT CH, the same from the >> former O&M AD and IETF chair. You've heard from a service provider as >> well as numerous members of the community who see the problem. >> >> You may or may not have yet heard from other standards bodies but if you >> were to delay it is quite possible they will chime in since one was >> specifically interested in this sort of function. >> >> The amount of changes required to support CH cannot fully be ascertained >> until more of the the [Todo]s are filled in with Dave's draft, but I >> don't imagine the work would be much more than: >> >> - specifying how to initiate the connection and if necessary turn it >> - the identity used for requests received from command generators that >> did not initiate the connection along with potential prepopulating >> of various tables >> - an appendix of how the SNMP-TARGET-MIB would be populated >> - a discussion on when to initiate connections and what to do when >> they fail (mind you this is needed anyway regardless of CH) >> - security considerations involving firewalls, blocking, etc. >> - possibly one additional table describing the state of SSH peer >> connectivity (which probably wouldn't be bad to have anyway). >> >> Decide for yourself if you think this is a substantial amount of text, >> but I won't leave it to your imagination for long. I will attempt this >> week to post a derivative of the draft that Dave is working on to give >> people an idea of what the changes would be. >> >> Again it's difficult to diff an incomplete specification. >> >> Eliot >> >>>>>>>>>>>>> "Eliot" == Eliot Lear writes: >>> >>> >>> >>> Eliot> I request an extension of the deadline for comments to >>> Eliot> September 21st on the following basis: >>> >>> Eliot> - the period of comment has been less than a week, far >>> Eliot> shorter than the normal period of IETF-wide review. - of >>> Eliot> the time allotted, the principle instigator of this review >>> Eliot> has been absent from debate for five days due to prior >>> Eliot> commitments. That was me. >>> >>> Hi, Eliot. I have not made any determination as yet about whether I >>> will pull ISMS from the Thursday telechat and am unlikely to make a >>> final determination until the time of that telechat. >>> >>> >>> When I originally ruled call home out of scope I gave you some >>> suggestions for how to approach things from a process standpoint. In >>> evaluating your request I will consider how much progress has been >>> made on these issues so far and on whether it is likely that you could >>> make additional progress on these issues by September 21. >>> >>> Let us go back and consider my original advice to you: >>> >>> When the charter is sent to me for IESG review, ask me to send it out >>> for external review (IETF wide) rather than just approving it; I will >>> honor such a request. You will need a proposal ready to present to >>> the community when the charter comes out for review. The proposal >>> should include proposed modifications to the charter to make call home >>> in scope. In addition you probably want to answer the following >>> concerns: >>> >>> * People believe that architectural changes to SNMP should happen in >>> the management not security area. Either convince them that this is >>> OK in the security area, propose moving the working group, or >>> propose splitting the work appropriately. >>> >>> * Address the concerns about the lack of MIBs and other facilities for >>> managing call home. Have a proposal ready for what is involved in >>> doing the work. >>> >>> >>> * Understand concerns Bert is likely to raise and respond to them. >>> >>> >>> >>> so, here are some specific questions related to our progress to date >>> on these items. Answering these questions will help me determine >>> whether extending the review period to September 21 is likely to be >>> productive. >>> >>> 1) Have you proposed a specific set of charter changes? Who has >>> supported these charter changes? >>> >>> 2) How have you addressed the specific concerns about the location of >>> the work ? Who has agreed with your proposed resolution? >>> >>> 3) Is there a consensus emerging that CH needs to be solved as part of >>> ISMS? This is the part where additional time is most likely to >>> help you, but I think it fair to ask who has supported blocking >>> ISMS on CH so far. Note that people who support CH but who >>> believe it could be done in a separate working group or who have >>> not expressed an opinion do not count. They may well count for >>> justifying support for a CH BOF or for justification of a >>> publication request for an individual submission adding CH to the >>> SNMP architecture. >>> >>> >>> 4) What response have you given to concerns about whether the >>> architectural extensions for CH are sufficiently well defined? Who >>> has supported this proposal? >>> >>> >>> >>> 5) How are your discussions going with Bert to resolve his concerns? >>> What about other key members of the management community who have >>> expressed concerns? >>> >>> >>> >>> Here's how I'm going to make a decision. I believe that in order to >>> get a change to the SNMP charter it is necessary to make significant >>> progress on all of these issues. I'm going to evaluate your answers >>> and consider whether I think the progress to date makes it likely that >>> you will have sufficient support for a new charter by September 21 >>> without significant opposition. In other words whether the community >>> and IESG can agree to the new charter by the end of the review period. >>> If the progress to date makes it likely that we're headed in that >>> direction, I'll grant the request. Otherwise I will ask the IESG to >>> approve the charter on Thursday. >>> >>> >>> There's an internal issue that may well prevent the charter from being >>> announced before the 21st even if no formal extension is granted. >>> >>> >>> --Sam >>> >> >> >> >> _______________________________________________ >> 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 13 15:31:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGVF-0003yC-Sg; Tue, 13 Sep 2005 15:31:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF6WV-0004ry-4A for isms@megatron.ietf.org; Tue, 13 Sep 2005 04:52:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10770 for ; Tue, 13 Sep 2005 04:52:11 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EF6ap-0004qa-U5 for isms@ietf.org; Tue, 13 Sep 2005 04:56:45 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IMQ00AWXZL00R@szxga01-in.huawei.com> for isms@ietf.org; Tue, 13 Sep 2005 16:58:13 +0800 (CST) Received: from m19684a ([10.110.100.101]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IMQ00DSEZL0SA@szxga01-in.huawei.com> for isms@ietf.org; Tue, 13 Sep 2005 16:58:12 +0800 (CST) Date: Tue, 13 Sep 2005 16:52:08 +0800 From: Miao Fuyou Subject: RE: [Isms] Draft-harrington-isms-SecShell-00.txt In-reply-to: <200509071447.KAA24099@ietf.org> To: dbharrington@comcast.net Message-id: <000001c5b840$6ce21220$65646e0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7BIT Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, In section 1.1 the draft discusses server authentication and user authentication. I believe server authentication is important for user authentication. In SNMP, it is the tranport protocol to provide confidentiality for password user authentication, and it is sent in clear. If the server is not authenticated, an attacker can spoof a SSH server to get user's password. Miao -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Wednesday, September 07, 2005 10:47 PM To: isms@ietf.org Subject: [Isms] Draft-harrington-isms-SecShell-00.txt Hi, I have submitted the attached draft for -00- publication. I have published it primarily so the WG can see that progress is being made on the document. The current document is raw and missing many parts and some questioins have already been answered but are not reflected here. Nevertheless, the document should be helpful to organize the work effort, and focus discussions on various issues that need to be addressed by an SSH-based security model. It can also be used to understand some aspects of the USM approach that may not be needed with an SSH (or any TMSM) approach. Contributed text is welcome, especially for the [todo] sections. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 13 15:33:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGWb-0004q5-JD; Tue, 13 Sep 2005 15:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFCMl-0003tY-Jr; Tue, 13 Sep 2005 11:06:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26312; Tue, 13 Sep 2005 11:06:22 -0400 (EDT) Message-Id: <200509131506.LAA26312@ietf.org> Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFCR0-0004bd-QS; Tue, 13 Sep 2005 11:10:59 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <2005091315060401400a8sbde>; Tue, 13 Sep 2005 15:06:04 +0000 From: "David B Harrington" To: "'Juergen Quittek'" , "'Eliot Lear'" , "'Sam Hartman'" Subject: RE: [Isms] ISMS charter broken- onus should be on WG to fix it Date: Tue, 13 Sep 2005 11:05:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW4cdHDqYCyEeBNQ36sSCaeYD2fFAAAQcpQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <56410FF569BC2359E7BBA4E4@[192.168.0.112]> X-Spam-Score: 0.1 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, david.kessens@nokia.com, isms@ietf.org, 'IETF Discussion' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, Personally, I'd rather see the issue of working through NATs and firewalls solved at the SSH level, and then SNMP and other SSH-using applications, such as Netconf and CLI, could use the solution in a consistent manner. The O&M community has gone through a multi-year effort to better understand operators' needs in network management. That effort started years ago at an Open O&M meeting. Bert and David are tentatively planning another Open O&M meeting at IETF64. Since the O-side draws more operators than the M-side of O&M, it might be worthwhile asking the operators that are present at that meeting if they believe this is an important problem to solve at the SNMP level, and whether they would prefer it be solved at the SSH level. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen Quittek > Sent: Monday, September 12, 2005 8:36 PM > To: Eliot Lear; Sam Hartman > Cc: isms@ietf.org; IETF Discussion; iesg@ietf.org > Subject: Re: [Isms] ISMS charter broken- onus should be on WG > to fix it > > Eliot, > > At the SBSM and ISMS BoF sessions at IETF 58 and 60 the need for > integrating SNMP into existing security frameworks was extensively > discussed. Wes presented the issue at NANOG and performed a survey > among operators. The output of all this work is the idenitfication > of a well founded general requirement for working on the integration > of SNMP into existing security frameworks in an IETF working group. > > Now you claim that solving this issue is technically wrong without > considering a different problem that you call "call home". Rather > you request adding the issue of solving the "call home" to the ISMS > charter. > > However, nobody raised this issue at the ISMS BoFs nor has the > issue been discussed in depth in the OaM area. But we should have > such a discussion before adding the issue to any IETF WG charter. > It looks like a good topic for a BoF session in the OaM area. > There we could find out the relevance of the problem and discuss > requirements for potential solutions. Also there we can identify > which working group would be the right one to deal with the issue. > > But until then, I propose that we let the ISMS group work on solving > its original problem. > > Thanks, > > Juergen > > > --On 9/12/2005 9:53 PM +0200 Eliot Lear wrote: > > > Sam, > > > > I believe the approach you have proposed is quite simply > wrong. As an > > AD you're supposed to provide technical oversight and not > simply hold a > > popularity contest. If you have technical questions or wish to > > challenge me on a technical point, I think that's fair game. > > > > As I've written, the path we are headed down technically > will not work > > in the face of firewalls and NATs, and nobody has refuted this. > > > > Furthermore you've heard from a reasonably large customer > (Boeing) as > > well as your predecessor on the prevalence of such middle boxes that > > demonstrates the complexity of today's environment and the > need for this > > sort of functionality as part of the solution. > > > > You've heard from an author of SNMP that the major > architectural change > > is the use of session based security and NOT CH, the same from the > > former O&M AD and IETF chair. You've heard from a service > provider as > > well as numerous members of the community who see the problem. > > > > You may or may not have yet heard from other standards > bodies but if you > > were to delay it is quite possible they will chime in since one was > > specifically interested in this sort of function. > > > > The amount of changes required to support CH cannot fully > be ascertained > > until more of the the [Todo]s are filled in with Dave's draft, but I > > don't imagine the work would be much more than: > > > > - specifying how to initiate the connection and if > necessary turn it > > - the identity used for requests received from command > generators that > > did not initiate the connection along with potential > prepopulating > > of various tables > > - an appendix of how the SNMP-TARGET-MIB would be populated > > - a discussion on when to initiate connections and what to do when > > they fail (mind you this is needed anyway regardless of CH) > > - security considerations involving firewalls, blocking, etc. > > - possibly one additional table describing the state of SSH peer > > connectivity (which probably wouldn't be bad to have anyway). > > > > Decide for yourself if you think this is a substantial > amount of text, > > but I won't leave it to your imagination for long. I will > attempt this > > week to post a derivative of the draft that Dave is working > on to give > > people an idea of what the changes would be. > > > > Again it's difficult to diff an incomplete specification. > > > > Eliot > > > >>>>>>>>>>>> "Eliot" == Eliot Lear writes: > >> > >> > >> Eliot> I request an extension of the deadline for comments to > >> Eliot> September 21st on the following basis: > >> > >> Eliot> - the period of comment has been less than a week, far > >> Eliot> shorter than the normal period of IETF-wide > review. - of > >> Eliot> the time allotted, the principle instigator of > this review > >> Eliot> has been absent from debate for five days due to prior > >> Eliot> commitments. That was me. > >> > >> Hi, Eliot. I have not made any determination as yet about > whether I > >> will pull ISMS from the Thursday telechat and am unlikely to make a > >> final determination until the time of that telechat. > >> > >> > >> When I originally ruled call home out of scope I gave you some > >> suggestions for how to approach things from a process > standpoint. In > >> evaluating your request I will consider how much progress has been > >> made on these issues so far and on whether it is likely > that you could > >> make additional progress on these issues by September 21. > >> > >> Let us go back and consider my original advice to you: > >> > >> When the charter is sent to me for IESG review, ask me > to send it out > >> for external review (IETF wide) rather than just > approving it; I will > >> honor such a request. You will need a proposal ready to > present to > >> the community when the charter comes out for review. > The proposal > >> should include proposed modifications to the charter to > make call home > >> in scope. In addition you probably want to answer the following > >> concerns: > >> > >> * People believe that architectural changes to SNMP > should happen in > >> the management not security area. Either convince > them that this is > >> OK in the security area, propose moving the working group, or > >> propose splitting the work appropriately. > >> > >> * Address the concerns about the lack of MIBs and other > facilities for > >> managing call home. Have a proposal ready for what is > involved in > >> doing the work. > >> > >> > >> * Understand concerns Bert is likely to raise and > respond to them. > >> > >> > >> > >> so, here are some specific questions related to our > progress to date > >> on these items. Answering these questions will help me determine > >> whether extending the review period to September 21 is likely to be > >> productive. > >> > >> 1) Have you proposed a specific set of charter changes? Who has > >> supported these charter changes? > >> > >> 2) How have you addressed the specific concerns about the > location of > >> the work ? Who has agreed with your proposed resolution? > >> > >> 3) Is there a consensus emerging that CH needs to be > solved as part of > >> ISMS? This is the part where additional time is most likely to > >> help you, but I think it fair to ask who has supported blocking > >> ISMS on CH so far. Note that people who support CH but who > >> believe it could be done in a separate working group > or who have > >> not expressed an opinion do not count. They may well count for > >> justifying support for a CH BOF or for justification of a > >> publication request for an individual submission > adding CH to the > >> SNMP architecture. > >> > >> > >> 4) What response have you given to concerns about whether the > >> architectural extensions for CH are sufficiently well > defined? Who > >> has supported this proposal? > >> > >> > >> > >> 5) How are your discussions going with Bert to resolve his > concerns? > >> What about other key members of the management > community who have > >> expressed concerns? > >> > >> > >> > >> Here's how I'm going to make a decision. I believe that > in order to > >> get a change to the SNMP charter it is necessary to make > significant > >> progress on all of these issues. I'm going to evaluate > your answers > >> and consider whether I think the progress to date makes it > likely that > >> you will have sufficient support for a new charter by September 21 > >> without significant opposition. In other words whether > the community > >> and IESG can agree to the new charter by the end of the > review period. > >> If the progress to date makes it likely that we're headed in that > >> direction, I'll grant the request. Otherwise I will ask > the IESG to > >> approve the charter on Thursday. > >> > >> > >> There's an internal issue that may well prevent the > charter from being > >> announced before the 21st even if no formal extension is granted. > >> > >> > >> --Sam > >> > > > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 13 15:33:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGX5-00052c-IA; Tue, 13 Sep 2005 15:33:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFD1Q-0002RH-0O; Tue, 13 Sep 2005 11:48:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28162; Tue, 13 Sep 2005 11:48:22 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFD5a-0005aW-9D; Tue, 13 Sep 2005 11:53:00 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j8DFmGZC000039; Tue, 13 Sep 2005 11:48:16 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 13 Sep 2005 11:48:17 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Tue, 13 Sep 2005 11:48:17 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 13 Sep 2005 11:46:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] ISMS charter broken- onus should be on WG to fix it Date: Tue, 13 Sep 2005 11:46:54 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325A6@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] ISMS charter broken- onus should be on WG to fix it Thread-Index: AcW4cd1AkRSjA+ZuTuamDzLi0KTnPAAB0GwA From: "Nelson, David" To: , "IETF Discussion" , X-OriginalArrivalTime: 13 Sep 2005 15:46:54.0773 (UTC) FILETIME=[5DB71E50:01C5B87A] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:79.5348 M:97.0282 P:95.9108 R:95.9108 S:57.4322 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen Quittek writes... > It [call home] looks like a good topic for a BoF session in the=20 > OaM area. > There we could find out the relevance of the problem and discuss > requirements for potential solutions. Also there we can identify > which working group would be the right one to deal with the issue. >=20 > But until then, I propose that we let the ISMS group work on solving > its original problem. I agree that specifying Call Home functionality in SNMP should be out of scope for ISMS, which is attempting to solve a different, well-defined problem. I also agree with Dave Harrington's suggestion that the SSH transport mechanism for ISMS should be designed such that the initiation and termination of SSH sessions, and the use of such sessions by the command generator and command responder, would not preclude another WG from specifying Call Home functionality using the ISMS work, unless that requirement overly complicated the ISMS design work. I would call this division of labor an appropriate "separation of concerns".=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 13 15:34:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGXm-0005Qx-3J; Tue, 13 Sep 2005 15:34:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFE8y-0006as-Uz; Tue, 13 Sep 2005 13:00:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01797; Tue, 13 Sep 2005 13:00:17 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFEDH-0007QV-8B; Tue, 13 Sep 2005 13:04:56 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 13 Sep 2005 10:00:09 -0700 X-IronPort-AV: i="3.97,106,1125903600"; d="scan'208"; a="659531508:sNHT35397072" Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8DH04KC027682; Tue, 13 Sep 2005 10:00:04 -0700 (PDT) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA02515; Tue, 13 Sep 2005 10:00:06 -0700 (PDT) From: Keith McCloghrie Message-Id: <200509131700.KAA02515@cisco.com> Subject: Re: [Isms] ISMS charter broken- onus should be on WG to fix it To: ietfdbh@comcast.net Date: Tue, 13 Sep 2005 10:00:06 -0700 (PDT) In-Reply-To: from "David B Harrington" at Sep 12, 2005 07:02:12 PM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, 'Sam Hartman' , isms@ietf.org, 'IETF Discussion' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dave, I support the "alternative" you are recommending. Thanks, Keith. > As primary editor of the SSH draft (SSHSM), I spoke with Eliot last > week. I agree that it is difficult for him to develop a reasonable > proposal that piggybacks on the SSH draft, because the SSH draft is so > incomplete. > > I am not convinced that SNMP needs to add a new call-home (CH) > functionality, nor that this feature is needed in SNMP now, but there > is a danger that CH might never be possible if we don't consider its > impact on the SSHSM model before SSHSM is cast in stone. If it > complicates the SSHSM model, I would prefer to not include it; a new > model could be developed to replace or supplement the SSHSM model if > demand increases for this functionality. > > I recommended to Eliot that he contribute some text for the SSH > document, describing the CH functionality and proposed elements of > procedure, that I could include as an appendix to the SSHSM document > so the WG could review his proposal, and then the WG could decide > whether it should remain as an appendix, be incorporated into the SSH > document, be split out as a separate document, or be abandoned > altogether. I felt this was a reasonable alternative to making the > decision whether CH is or is not in scope at this time. He has not yet > had a chance to develop the text and send it to me. > > David Harrington > dbharrington@comcast.net > > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Eliot Lear > > Sent: Monday, September 12, 2005 3:53 PM > > To: Sam Hartman > > Cc: IETF Discussion; iesg@ietf.org; isms@ietf.org > > Subject: [Isms] ISMS charter broken- onus should be on WG to fix it > > > > Sam, > > > > I believe the approach you have proposed is quite simply wrong. As > an > > AD you're supposed to provide technical oversight and not > > simply hold a > > popularity contest. If you have technical questions or wish to > > challenge me on a technical point, I think that's fair game. > > > > As I've written, the path we are headed down technically will not > work > > in the face of firewalls and NATs, and nobody has refuted this. > > > > Furthermore you've heard from a reasonably large customer (Boeing) > as > > well as your predecessor on the prevalence of such middle boxes that > > demonstrates the complexity of today's environment and the > > need for this > > sort of functionality as part of the solution. > > > > You've heard from an author of SNMP that the major > > architectural change > > is the use of session based security and NOT CH, the same from the > > former O&M AD and IETF chair. You've heard from a service provider > as > > well as numerous members of the community who see the problem. > > > > You may or may not have yet heard from other standards bodies > > but if you > > were to delay it is quite possible they will chime in since one was > > specifically interested in this sort of function. > > > > The amount of changes required to support CH cannot fully be > > ascertained > > until more of the the [Todo]s are filled in with Dave's draft, but I > > don't imagine the work would be much more than: > > > > - specifying how to initiate the connection and if necessary turn > it > > - the identity used for requests received from command > > generators that > > did not initiate the connection along with potential > prepopulating > > of various tables > > - an appendix of how the SNMP-TARGET-MIB would be populated > > - a discussion on when to initiate connections and what to do when > > they fail (mind you this is needed anyway regardless of CH) > > - security considerations involving firewalls, blocking, etc. > > - possibly one additional table describing the state of SSH peer > > connectivity (which probably wouldn't be bad to have anyway). > > > > Decide for yourself if you think this is a substantial amount of > text, > > but I won't leave it to your imagination for long. I will > > attempt this > > week to post a derivative of the draft that Dave is working on to > give > > people an idea of what the changes would be. > > > > Again it's difficult to diff an incomplete specification. > > > > Eliot > > > > >>>>>>>>>>> "Eliot" == Eliot Lear writes: > > > > > > > > > Eliot> I request an extension of the deadline for comments to > > > Eliot> September 21st on the following basis: > > > > > > Eliot> - the period of comment has been less than a week, far > > > Eliot> shorter than the normal period of IETF-wide review. - > of > > > Eliot> the time allotted, the principle instigator of > > this review > > > Eliot> has been absent from debate for five days due to prior > > > Eliot> commitments. That was me. > > > > > > Hi, Eliot. I have not made any determination as yet about whether > I > > > will pull ISMS from the Thursday telechat and am unlikely to make > a > > > final determination until the time of that telechat. > > > > > > > > > When I originally ruled call home out of scope I gave you some > > > suggestions for how to approach things from a process > > standpoint. In > > > evaluating your request I will consider how much progress has been > > > made on these issues so far and on whether it is likely > > that you could > > > make additional progress on these issues by September 21. > > > > > > Let us go back and consider my original advice to you: > > > > > > When the charter is sent to me for IESG review, ask me to > > send it out > > > for external review (IETF wide) rather than just > > approving it; I will > > > honor such a request. You will need a proposal ready to > > present to > > > the community when the charter comes out for review. The > proposal > > > should include proposed modifications to the charter to > > make call home > > > in scope. In addition you probably want to answer the following > > > concerns: > > > > > > * People believe that architectural changes to SNMP > > should happen in > > > the management not security area. Either convince them > > that this is > > > OK in the security area, propose moving the working group, or > > > propose splitting the work appropriately. > > > > > > * Address the concerns about the lack of MIBs and other > > facilities for > > > managing call home. Have a proposal ready for what is > > involved in > > > doing the work. > > > > > > > > > * Understand concerns Bert is likely to raise and respond to > them. > > > > > > > > > > > > so, here are some specific questions related to our progress to > date > > > on these items. Answering these questions will help me determine > > > whether extending the review period to September 21 is likely to > be > > > productive. > > > > > > 1) Have you proposed a specific set of charter changes? Who has > > > supported these charter changes? > > > > > > 2) How have you addressed the specific concerns about the > > location of > > > the work ? Who has agreed with your proposed resolution? > > > > > > 3) Is there a consensus emerging that CH needs to be solved > > as part of > > > ISMS? This is the part where additional time is most likely > to > > > help you, but I think it fair to ask who has supported > blocking > > > ISMS on CH so far. Note that people who support CH but who > > > believe it could be done in a separate working group or who > have > > > not expressed an opinion do not count. They may well count > for > > > justifying support for a CH BOF or for justification of a > > > publication request for an individual submission adding > > CH to the > > > SNMP architecture. > > > > > > > > > 4) What response have you given to concerns about whether the > > > architectural extensions for CH are sufficiently well > > defined? Who > > > has supported this proposal? > > > > > > > > > > > > 5) How are your discussions going with Bert to resolve his > concerns? > > > What about other key members of the management > > community who have > > > expressed concerns? > > > > > > > > > > > > Here's how I'm going to make a decision. I believe that in order > to > > > get a change to the SNMP charter it is necessary to make > significant > > > progress on all of these issues. I'm going to evaluate your > answers > > > and consider whether I think the progress to date makes it > > likely that > > > you will have sufficient support for a new charter by September 21 > > > without significant opposition. In other words whether the > > community > > > and IESG can agree to the new charter by the end of the > > review period. > > > If the progress to date makes it likely that we're headed in that > > > direction, I'll grant the request. Otherwise I will ask the IESG > to > > > approve the charter on Thursday. > > > > > > > > > There's an internal issue that may well prevent the charter > > from being > > > announced before the 21st even if no formal extension is granted. > > > > > > > > > --Sam > > > > > > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 13 15:34:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGYH-0005jS-NL; Tue, 13 Sep 2005 15:34:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFFZk-0003ck-8P; Tue, 13 Sep 2005 14:32:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05456; Tue, 13 Sep 2005 14:31:59 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFFe0-00015T-5b; Tue, 13 Sep 2005 14:36:37 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 49DF2E0049; Tue, 13 Sep 2005 14:31:54 -0400 (EDT) To: Subject: Re: [Isms] ISMS charter broken- onus should be on WG to fix it References: <200509131506.j8DF664A016810@pacific-carrier-annex.mit.edu> From: Sam Hartman Date: Tue, 13 Sep 2005 14:31:54 -0400 In-Reply-To: <200509131506.j8DF664A016810@pacific-carrier-annex.mit.edu> (David B. Harrington's message of "Tue, 13 Sep 2005 11:05:49 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: david.kessens@nokia.com, isms@ietf.org, iesg@ietf.org, 'IETF Discussion' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "David" == David B Harrington writes: David> Hi, Personally, I'd rather see the issue of working through David> NATs and firewalls solved at the SSH level, and then SNMP David> and other SSH-using applications, such as Netconf and CLI, David> could use the solution in a consistent manner. I think that the ssh connection application already has a fairly reasonable story for NATs and firewalls, so I don't see much of a need for ssh itself to advance in this area. For the most part people who block port 22 really do intend to block ssh and so having standard facilities to get around that would not be appropriate. The port forwarding support in ssh seems to be an adequate solution for NATs. SNMP can use these facilities certainly. However you may want/need a more automated solution. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 13 15:34:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGYM-0005mm-OW; Tue, 13 Sep 2005 15:34:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFFey-0004g0-To; Tue, 13 Sep 2005 14:37:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05765; Tue, 13 Sep 2005 14:37:22 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFFjD-0001EE-SJ; Tue, 13 Sep 2005 14:42:01 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E9C09E0049; Tue, 13 Sep 2005 14:37:23 -0400 (EDT) To: ietfdbh@comcast.net Subject: Re: [Isms] ISMS charter broken- onus should be on WG to fix it References: <200509122302.TAA07622@ietf.org> From: Sam Hartman Date: Tue, 13 Sep 2005 14:37:23 -0400 In-Reply-To: <200509122302.TAA07622@ietf.org> (David B. Harrington's message of "Mon, 12 Sep 2005 19:02:12 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: iesg@ietf.org, isms@ietf.org, 'IETF Discussion' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "David" == David B Harrington writes: David> Hi, As primary editor of the SSH draft (SSHSM), I spoke David> with Eliot last week. I agree that it is difficult for him David> to develop a reasonable proposal that piggybacks on the SSH David> draft, because the SSH draft is so incomplete. David> I am not convinced that SNMP needs to add a new call-home David> (CH) functionality, nor that this feature is needed in SNMP David> now, but there is a danger that CH might never be possible David> if we don't consider its impact on the SSHSM model before David> SSHSM is cast in stone. If it complicates the SSHSM model, David> I would prefer to not include it; a new model could be David> developed to replace or supplement the SSHSM model if David> demand increases for this functionality. David> I recommended to Eliot that he contribute some text for the David> SSH document, describing the CH functionality and proposed David> elements of procedure, that I could include as an appendix David> to the SSHSM document so the WG could review his proposal, David> and then the WG could decide whether it should remain as an David> appendix, be incorporated into the SSH document, be split David> out as a separate document, or be abandoned altogether. I David> felt this was a reasonable alternative to making the David> decision whether CH is or is not in scope at this time. He David> has not yet had a chance to develop the text and send it to David> me. I completely agree that having Eliot and other interested parties work on how technical details of CH would work for ssh is a good idea. I also agree that having it be an appendix in the document is fine for now. I was hoping that Eliot would go forward in this direction; in my original message ruling CH out of scope I aske Eliot to work with the ssh document editor to see how CH might work. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 13 16:46:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFHfZ-0008CC-1n; Tue, 13 Sep 2005 16:46:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFHfS-0008BX-Sy; Tue, 13 Sep 2005 16:46:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25287; Tue, 13 Sep 2005 16:46:12 -0400 (EDT) Received: from ia6f2.i.pppool.de ([85.73.166.242] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFHju-0000Te-PR; Tue, 13 Sep 2005 16:50:52 -0400 Received: by boskop.local (Postfix, from userid 501) id 088133F6EB9; Tue, 13 Sep 2005 22:45:55 +0200 (CEST) Date: Tue, 13 Sep 2005 22:45:55 +0200 From: Juergen Schoenwaelder To: Sam Hartman Subject: Re: [Isms] ISMS charter broken- onus should be on WG to fix it Message-ID: <20050913204555.GA14153@boskop.local> Mail-Followup-To: Sam Hartman , ietfdbh@comcast.net, david.kessens@nokia.com, isms@ietf.org, iesg@ietf.org, 'Eliot Lear' , 'IETF Discussion' References: <200509131506.j8DF664A016810@pacific-carrier-annex.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.10i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: david.kessens@nokia.com, 'IETF Discussion' , iesg@ietf.org, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Tue, Sep 13, 2005 at 02:31:54PM -0400, Sam Hartman wrote: > >>>>> "David" == David B Harrington writes: > > David> Hi, Personally, I'd rather see the issue of working through > David> NATs and firewalls solved at the SSH level, and then SNMP > David> and other SSH-using applications, such as Netconf and CLI, > David> could use the solution in a consistent manner. > > I think that the ssh connection application already has a fairly > reasonable story for NATs and firewalls, so I don't see much of a need > for ssh itself to advance in this area. > > For the most part people who block port 22 really do intend to block > ssh and so having standard facilities to get around that would not be > appropriate. The port forwarding support in ssh seems to be an > adequate solution for NATs. Sam, this is not about blocking port 22 as far as I understand things. I think the issue here is that TCP connection establishment determines ssh client/server roles. If there would be a way to initiate the connection but subsequently taking over the server role, protocols like netconf and presumably isms would find it much easier to provide CH functionality. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 13 17:06:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFHzJ-0006qu-Cl; Tue, 13 Sep 2005 17:06:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFHzF-0006oS-JP; Tue, 13 Sep 2005 17:06:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27074; Tue, 13 Sep 2005 17:06:38 -0400 (EDT) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFI3h-0001Li-Rx; Tue, 13 Sep 2005 17:11:19 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 3F667E0049; Tue, 13 Sep 2005 17:06:40 -0400 (EDT) To: ietfdbh@comcast.net Subject: Re: [Isms] ISMS charter broken- onus should be on WG to fix it References: <200509131506.j8DF664A016810@pacific-carrier-annex.mit.edu> <20050913204555.GA14153@boskop.local> From: Sam Hartman Date: Tue, 13 Sep 2005 17:06:40 -0400 In-Reply-To: <20050913204555.GA14153@boskop.local> (Juergen Schoenwaelder's message of "Tue, 13 Sep 2005 22:45:55 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: david.kessens@nokia.com, 'IETF Discussion' , isms@ietf.org, iesg@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Juergen" == Juergen Schoenwaelder writes: Juergen> Sam, Juergen> this is not about blocking port 22 as far as I understand Juergen> things. I think the issue here is that TCP connection Juergen> establishment determines ssh client/server roles. If Juergen> there would be a way to initiate the connection but Juergen> subsequently taking over the server role, protocols like Juergen> netconf and presumably isms would find it much easier to Juergen> provide CH functionality. Right. But for the ssh-connect application I don't think you would want that unless you were trying to get around firewall policy. I suspect that the ssh community would decline to extend ssh in this direction; I certainly know I would not support it. I would support setting up port forwarding as a way to get a back channel; I would also support a facility to run an ssh protocol over ssh channel. One advantage of both port forwarding and ssh over ssh is that they provide a much more consistent model for authentication and authorization of the request to "turn" than an explicit turn facility. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 13 17:38:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFITZ-0007mw-Hi; Tue, 13 Sep 2005 17:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFITV-0007m8-GI; Tue, 13 Sep 2005 17:37:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28223; Tue, 13 Sep 2005 17:37:54 -0400 (EDT) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFIXv-00025b-S6; Tue, 13 Sep 2005 17:42:35 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa07195; 13 Sep 2005 17:37 EDT Date: Tue, 13 Sep 2005 17:37:49 -0400 From: Jeffrey Hutzelman To: Sam Hartman , ietfdbh@comcast.net Subject: Re: [Isms] ISMS charter broken- onus should be on WG to fix it Message-ID: <3C03BDBD60783D559EDAE652@sirius.fac.cs.cmu.edu> In-Reply-To: References: <200509131506.j8DF664A016810@pacific-carrier-annex.mit.edu> <20050913204555.GA14153@boskop.local> Originator-Info: login-token=Mulberry:01XqLN48gKQleq7UVkkSD9UvUUBA7l1kbLF/tIlCI=; 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: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, david.kessens@nokia.com, 'IETF Discussion' , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Tuesday, September 13, 2005 05:06:40 PM -0400 Sam Hartman wrote: >>>>>> "Juergen" == Juergen Schoenwaelder >>>>>> writes: > > Juergen> Sam, > > Juergen> this is not about blocking port 22 as far as I understand > Juergen> things. I think the issue here is that TCP connection > Juergen> establishment determines ssh client/server roles. If > Juergen> there would be a way to initiate the connection but > Juergen> subsequently taking over the server role, protocols like > Juergen> netconf and presumably isms would find it much easier to > Juergen> provide CH functionality. > > Right. But for the ssh-connect application I don't think you would > want that unless you were trying to get around firewall policy. I don't think that's necessarily the case. Sure, you might be trying to do that, but you also might be trying to get around the fact that the machines at your house are behind a NAT and thus lack routable addresses. > I suspect that the ssh community would decline to extend ssh in this > direction; I certainly know I would not support it. I'm not entirely sure _how_ I'd extend SSH in this direction, or how much utility it would have. I don't think I would object to it, especially since I suspect it might make some of the ISMS cases easier even if you don't care about the firewall problem. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 13 17:44:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFIZS-0000qd-9Q; Tue, 13 Sep 2005 17:44:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFIZQ-0000qK-OK; Tue, 13 Sep 2005 17:44:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28549; Tue, 13 Sep 2005 17:44:01 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFIds-0002Fk-64; Tue, 13 Sep 2005 17:48:42 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id B254811D40F; Tue, 13 Sep 2005 14:43:46 -0700 (PDT) From: Wes Hardaker To: Eliot Lear Subject: Re: [Isms] ISMS charter broken- onus should be on WG to fix it Organization: Sparta References: <200509072021.QAA19324@ietf.org> <43252AE6.7000704@cisco.com> <4325DCA2.2070400@cisco.com> <56410FF569BC2359E7BBA4E4@[192.168.0.112]> <432673E6.1020603@cisco.com> Date: Tue, 13 Sep 2005 14:43:45 -0700 In-Reply-To: <432673E6.1020603@cisco.com> (Eliot Lear's message of "Tue, 13 Sep 2005 08:38:30 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: iesg@ietf.org, IETF Discussion , Sam Hartman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Eliot> Wes received the obvious feedback that operators find SNMP Eliot> unusable with the USM model because they cannot integrate it Eliot> with their existing security infrastructures and there is no Eliot> denying that this is a real problem. But this is NOT the only Eliot> problem operators face with SNMP. FYI, there was a "other comments" field in the survey that the operators filled out. I just went back and reviewed everything entered into that space and no one asked for anything like the CH functionality, nor did they even mention NATs or firewalls at all. That being said, that wasn't the point of the survey and I do think the problem shouldn't be forgotten. I think we'd be stupid to let the work go forward and do something that deliberately prevented CH functionality from being usable in the ISMS/SSH draft. However, everything needs to be weighed and I do think we should make sure it's possible till we run into a problem. At that time we'd have to evaluate the choices to decide which was more important (the potential problem being unknown at this time of course). I'm not sure the charter needs to explicitly state that we must consider call home support. It sounds like there is enough energy to make sure we don't blow it. I would strongly object to anything that says we must support it, because as has been stated many times "that's not the point of the WG". At the same time, I think we'd be idiots not to at the very least leave room for it (but then, I think we're not being wise for dropping the consideration of a UDP solution too, so...) -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 13 17:44:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFIZi-0000tp-EQ; Tue, 13 Sep 2005 17:44:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFIZf-0000sz-JY; Tue, 13 Sep 2005 17:44:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28600; Tue, 13 Sep 2005 17:44:16 -0400 (EDT) Received: from ia6f2.i.pppool.de ([85.73.166.242] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFIe8-0002Ge-PN; Tue, 13 Sep 2005 17:48:57 -0400 Received: by boskop.local (Postfix, from userid 501) id 1E04A3FB7CE; Tue, 13 Sep 2005 23:44:07 +0200 (CEST) Date: Tue, 13 Sep 2005 23:44:07 +0200 From: Juergen Schoenwaelder To: Sam Hartman Subject: Re: [Isms] ISMS charter broken- onus should be on WG to fix it Message-ID: <20050913214407.GB11870@boskop.local> Mail-Followup-To: Sam Hartman , ietfdbh@comcast.net, david.kessens@nokia.com, 'IETF Discussion' , isms@ietf.org, 'Eliot Lear' , iesg@ietf.org References: <200509131506.j8DF664A016810@pacific-carrier-annex.mit.edu> <20050913204555.GA14153@boskop.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.10i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: david.kessens@nokia.com, isms@ietf.org, iesg@ietf.org, 'IETF Discussion' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Tue, Sep 13, 2005 at 05:06:40PM -0400, Sam Hartman wrote: > I would support setting up port forwarding as a way to get a back > channel; I would also support a facility to run an ssh protocol over > ssh channel. > > One advantage of both port forwarding and ssh over ssh is that they > provide a much more consistent model for authentication and > authorization of the request to "turn" than an explicit turn facility. Can you please elaborate a bit? I am not sure I understand the idea you seem to have in your mind... /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 13 21:15:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFLsO-0002uJ-Jw; Tue, 13 Sep 2005 21:15:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFLsL-0002q6-EA; Tue, 13 Sep 2005 21:15:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14006; Tue, 13 Sep 2005 21:15:47 -0400 (EDT) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFLwq-0000pL-Rd; Tue, 13 Sep 2005 21:20:29 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa08198; 13 Sep 2005 21:14 EDT Date: Tue, 13 Sep 2005 21:14:11 -0400 From: Jeffrey Hutzelman To: Ned Freed Subject: Re: [Isms] ISMS charter broken- onus should be on WG to fix it Message-ID: In-Reply-To: <01LSZP7AGR0Y000092@mauve.mrochek.com> References: <200509131506.j8DF664A016810@pacific-carrier-annex.mit.edu> <20050913204555.GA14153@boskop.local> <3C03BDBD60783D559EDAE652@sirius.fac.cs.cmu.edu> <01LSZP7AGR0Y000092@mauve.mrochek.com> Originator-Info: login-token=Mulberry:01PUlmoKex2xSJlN4hcMeWD9S7ncvEfd+qvpQFc8k=; 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: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: david.kessens@nokia.com, isms@ietf.org, iesg@ietf.org, Sam Hartman , 'IETF Discussion' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Tuesday, September 13, 2005 05:23:26 PM -0700 Ned Freed wrote: >> > I suspect that the ssh community would decline to extend ssh in this >> > direction; I certainly know I would not support it. > >> I'm not entirely sure _how_ I'd extend SSH in this direction, or how much >> utility it would have. I don't think I would object to it, especially >> since I suspect it might make some of the ISMS cases easier even if you >> don't care about the firewall problem. > > Well, the ssh client I use has the ability to do port forwarding in both > directions already. The only thing that has stopped me from using this > feature > to do SNMP monitoring of various mobile agents is that it doesn't work > with > UDP, and the SNMP stuff I use is UDP only. Aha! Another use case for UDP tunnelling in SSH, which is a topic that was recently brought up in that WG. In any event, the problem isn't carrying the SNMP traffic over an ssh connedction -- we're fairly confident we know how to do that, though the document isn't done yet. The problems are in determining when to establish an SSH connection for the purpose of _receiving_ traffic, and in making authentication work in cases where a managed device wants to authenticate to something that is essentially a user. With some authentication infrastructures the latter is easy; with others it is not. The former I think is always hard, but has nothing to do with SSH per se. I think that we can easily avoid making call-home harder than it needs to be, and that we should. I would not object to a change in ISMS's charter requiring that it consider the potential effects of any security solution it adopts on the ability to add a call-home mechanism, but I also don't think such a provision is necessary to achieve the desired result. I don't think extending the SNMP architecture to add call-home is within the scope of ISMS's charter, and I don't think it would be appropriate to add it at this time. I'm not quite as concerned as Margaret is about the "wrong area" problem, provided the right people are active in the WG and reviewing its output, which I believe is necessary in any event. However, I do believe the problems are separable, nearly orthogonal, and require somewhat different expertise. Provided that the ISMS work does not preclude call-home or some other solution to the problem, I think a narrowly-scoped working group is appropriate here. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Sep 14 11:41:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZNg-0000w5-5F; Wed, 14 Sep 2005 11:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFLZa-0005Nz-Vx; Tue, 13 Sep 2005 20:56:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12898; Tue, 13 Sep 2005 20:56:24 -0400 (EDT) Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFLe3-0000DL-Rv; Tue, 13 Sep 2005 21:01:06 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LSZP7BN6OW007T8P@mauve.mrochek.com> (original mail from ned.freed@mrochek.com); Tue, 13 Sep 2005 17:56:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1126659368; h=Date: From:Subject:MIME-version:Content-type; b=AzsQlw0FO/E0FygM56w5+gcjt QndOQ9VpoInNXY3eau9gpa5p1OEL++Lb53pc3eRqnEsg3G7KAYySdwwz2pCew== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LSZBHW7HR4000092@mauve.mrochek.com>; Tue, 13 Sep 2005 17:56:05 -0700 (PDT) To: Jeffrey Hutzelman Message-id: <01LSZP7AGR0Y000092@mauve.mrochek.com> Date: Tue, 13 Sep 2005 17:23:26 -0700 (PDT) From: Ned Freed Subject: Re: [Isms] ISMS charter broken- onus should be on WG to fix it In-reply-to: "Your message dated Tue, 13 Sep 2005 17:37:49 -0400" <3C03BDBD60783D559EDAE652@sirius.fac.cs.cmu.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <200509131506.j8DF664A016810@pacific-carrier-annex.mit.edu> <20050913204555.GA14153@boskop.local> <3C03BDBD60783D559EDAE652@sirius.fac.cs.cmu.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-Mailman-Approved-At: Wed, 14 Sep 2005 11:41:02 -0400 Cc: david.kessens@nokia.com, isms@ietf.org, iesg@ietf.org, Sam Hartman , 'IETF Discussion' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > On Tuesday, September 13, 2005 05:06:40 PM -0400 Sam Hartman > wrote: > >>>>>> "Juergen" == Juergen Schoenwaelder > >>>>>> writes: > > > > Juergen> Sam, > > > > Juergen> this is not about blocking port 22 as far as I understand > > Juergen> things. I think the issue here is that TCP connection > > Juergen> establishment determines ssh client/server roles. If > > Juergen> there would be a way to initiate the connection but > > Juergen> subsequently taking over the server role, protocols like > > Juergen> netconf and presumably isms would find it much easier to > > Juergen> provide CH functionality. > > > > Right. But for the ssh-connect application I don't think you would > > want that unless you were trying to get around firewall policy. > I don't think that's necessarily the case. Sure, you might be trying to do > that, but you also might be trying to get around the fact that the machines > at your house are behind a NAT and thus lack routable addresses. Or consider the case of a firewall whose policy is simply one where incoming connections are not allowed for fear of worms infecting vulnerable systems. The only way to monitor systems behind such a firewall is to have them establish outgoing connections. Such behavior is in no way, shape or form a violation of that firewall's policy, yet it is necessary to work properly in such a (very common) firewalled environment. More generally, every protocol we define, every enhancement to a protocol we specify, and every operational policy we advocate has the potential of being used to "get around firewall policy" in some situation or other. And this is especially true when we're defining protocols that provide some form of confidentiality, which of course we do more and more frequently. This is the nature of the beast, like it or not. Were we to use this as a criteria not to proceed with our work we might as well all go home. Furthermore, the fact of the matter is that specifying how something is supposed to be done tends to aid in establishing useful firewall policies far more than it hurts. People are going to use the "call home" approach for monitoring whether we like it or not - it is just too useful for them not to. And absent a specification it will be done in a zillion incompatible ways and without any real understanding of the security issues. And unless firewall operators are prepared to block absolutely everything (which of course they cannot) they don't stand a chance in hell of controlling such services. A timely specification, on the other hand, could simultaneously raise awareness of the security issues as well as provide some measure of consistency in such traffic, in turn allowing some measure of control. And make no mistake about it: When it comes to call home services, the situation is already dire. Only yesterday I observed a popup from a piece of video processing software I use informing me that a new version is now available. Obviously this application had just "called home" and found out about the new version. Hopefully that's all it did - nowhere in the product documentation does it mention it would do this, nor is there any preferences setting I can find to tell it not to. If I were to object to Eliot's proposal (I don't - in fact I strongly support it), it would be on the grounds that the IETF should be taking a long hard look at the issues surrounding call home in general, not just in the special case of SNMP. > > I suspect that the ssh community would decline to extend ssh in this > > direction; I certainly know I would not support it. > I'm not entirely sure _how_ I'd extend SSH in this direction, or how much > utility it would have. I don't think I would object to it, especially > since I suspect it might make some of the ISMS cases easier even if you > don't care about the firewall problem. Well, the ssh client I use has the ability to do port forwarding in both directions already. The only thing that has stopped me from using this feature to do SNMP monitoring of various mobile agents is that it doesn't work with UDP, and the SNMP stuff I use is UDP only. Ned _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Sep 14 15:15:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFcjI-000408-NQ; Wed, 14 Sep 2005 15:15:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFcjH-000403-PC for isms@megatron.ietf.org; Wed, 14 Sep 2005 15:15:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27842 for ; Wed, 14 Sep 2005 15:15:33 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFcnv-0002Fw-Dj for isms@ietf.org; Wed, 14 Sep 2005 15:20:24 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j8EJFIBT001880 for ; Wed, 14 Sep 2005 12:15:18 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j8EJFCQt024430 for ; Wed, 14 Sep 2005 12:15:12 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j8EJFCnO024424 for ; Wed, 14 Sep 2005 12:15:12 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 14 Sep 2005 12:15:12 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: isms@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Isms] Tests for ISMS X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, In evaluating any candidate ISMS solution, I'd like to remind all of the tests that I use: 1) What identity credentials does the candidate require from EACH end of the SNMP operation pair? 2) Does each end "already have" those credentials due to setting up some other service? If they don't have the credentials, then REJECT the candidate. 3) Does the candidate require that an existing security infrastructure be modified (or extended) for the candidate to work? If so, then REJECT the candidate. 4) Do other "management interfaces" use the same "operations model". If not, then hold the candidate to higher scrutiny. Note that the following are NOT reasons to REJECT a candidate: 1) backwards compatibility with an existing SNMP security model 2) new code for SNMP agents or managers 3) new SNMP terminology and ways of viewing the management model Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 15 14:13:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFyEw-0000th-87; Thu, 15 Sep 2005 14:13:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFyEu-0000tK-Kx for isms@megatron.ietf.org; Thu, 15 Sep 2005 14:13:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24865 for ; Thu, 15 Sep 2005 14:13:38 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFyJj-0008Kw-CX for isms@ietf.org; Thu, 15 Sep 2005 14:18:41 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j8FIDTBT014988 for ; Thu, 15 Sep 2005 11:13:29 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j8FIDNHk012642 for ; Thu, 15 Sep 2005 11:13:23 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j8FIDN9O012639 for ; Thu, 15 Sep 2005 11:13:23 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 15 Sep 2005 11:13:22 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: isms@ietf.org Subject: Re: [Isms] ISMS charter broken- onus should be on WG to fix it (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, This is a resend, since it doesn't appear that this was sent to the mailing list. Regards, /david t. perkins ---------- Forwarded message ---------- Date: Wed, 14 Sep 2005 11:38:16 -0700 (PDT) From: David T. Perkins To: Ned Freed Cc: Jeffrey Hutzelman , david.kessens@nokia.com, isms@ietf.org, iesg@ietf.org, Sam Hartman , 'IETF Discussion' Subject: Re: [Isms] ISMS charter broken- onus should be on WG to fix it HI, Ned, please note that SSH port forwarding (even if it supported UDP) doesn't do the job, since the SSH credentials are not made available to the SNMP entities. On Tue, 13 Sep 2005, Ned Freed wrote: > Well, the ssh client I use has the ability to do port forwarding in both > directions already. The only thing that has stopped me from using this feature > to do SNMP monitoring of various mobile agents is that it doesn't work with > UDP, and the SNMP stuff I use is UDP only. > Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 15 14:22:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFyNI-0003Hs-MJ; Thu, 15 Sep 2005 14:22:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFyNH-0003Hm-B4 for isms@megatron.ietf.org; Thu, 15 Sep 2005 14:22:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25352 for ; Thu, 15 Sep 2005 14:22:17 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFyS8-00007u-AB for isms@ietf.org; Thu, 15 Sep 2005 14:27:20 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j8FIMGBT017242 for ; Thu, 15 Sep 2005 11:22:16 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j8FIM90x016029 for ; Thu, 15 Sep 2005 11:22:10 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j8FIM9X4016026 for ; Thu, 15 Sep 2005 11:22:09 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 15 Sep 2005 11:22:09 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: isms@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 2.0 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Subject: [Isms] Questions for Call home X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, In "call home", 1) What identities and credentials are being used? 2) How are those identities "put on the box"? 3) Are those identities and credentials there due to other management operations? 4) Are they used by other management interfaces? 5) What are the possible exploits that performed with identities and credentials from a compromized system? 6) Are there any changes that need to be made to existing security infrastructure to support the "call home" functionality, such as defining new RADIUS extensions? Regards, /david t. perkins ---------- Forwarded message ---------- Date: Wed, 14 Sep 2005 12:15:12 -0700 (PDT) From: David T. Perkins To: isms@ietf.org Subject: [Isms] Tests for ISMS HI, In evaluating any candidate ISMS solution, I'd like to remind all of the tests that I use: 1) What identity credentials does the candidate require from EACH end of the SNMP operation pair? 2) Does each end "already have" those credentials due to setting up some other service? If they don't have the credentials, then REJECT the candidate. 3) Does the candidate require that an existing security infrastructure be modified (or extended) for the candidate to work? If so, then REJECT the candidate. 4) Do other "management interfaces" use the same "operations model". If not, then hold the candidate to higher scrutiny. Note that the following are NOT reasons to REJECT a candidate: 1) backwards compatibility with an existing SNMP security model 2) new code for SNMP agents or managers 3) new SNMP terminology and ways of viewing the management model Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 15 15:21:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFzIE-0001vz-Jd; Thu, 15 Sep 2005 15:21:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFzID-0001vu-Kt for isms@megatron.ietf.org; Thu, 15 Sep 2005 15:21:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29433 for ; Thu, 15 Sep 2005 15:21:07 -0400 (EDT) From: kaushik@cisco.com Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFzN5-0001oa-4Y for isms@ietf.org; Thu, 15 Sep 2005 15:26:11 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 15 Sep 2005 12:21:00 -0700 X-IronPort-AV: i="3.97,114,1125903600"; d="scan'208"; a="342094990:sNHT50747086" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8FJKOKe012493; Thu, 15 Sep 2005 12:20:53 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Sep 2005 12:20:56 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Questions for Call home Date: Thu, 15 Sep 2005 12:20:55 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C39E1046@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] Questions for Call home Thread-Index: AcW6IuEFXeAy3jHKQ1SijzVmsfoBjgAAzcUA To: "David T. Perkins" , X-OriginalArrivalTime: 15 Sep 2005 19:20:56.0056 (UTC) FILETIME=[988AE780:01C5BA2A] X-Spam-Score: 2.3 (++) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, I can give you a typical example of Call Home from the Cable space since I being going through some of their specifications. PacketCable 1.0 uses SNMPv3 for part of the provisioning, TFTP is used to download to the actual configuration file. Each MTA is required to provisioned with a X.509 certificate (actually there are separate certs for the cable modem and MTA) typically done at manufacturing. The MAC address is used as CN within the X.509 cert=20 The X.509 certificate is shared between SNMPv3 and IPSec that is used for communication between the MTA and the Call Management Server. Kerberized SNMPv3 is used for protection of SNMPv3 message, PKINIT is used for initial authentication and ticket generation. The MAC address is used as USM user name (identity) within the Kerberized SNMPv3 exchange, the cable modem (managed device) initiates the exchange.=20 Hope this helps. regards, kaushik! =20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David T. Perkins Sent: Thursday, September 15, 2005 11:22 AM To: isms@ietf.org Subject: [Isms] Questions for Call home HI, In "call home", 1) What identities and credentials are being used? 2) How are those identities "put on the box"? 3) Are those identities and credentials there due to other management operations? 4) Are they used by other management interfaces? 5) What are the possible exploits that performed with identities and credentials from a compromized system? 6) Are there any changes that need to be made to existing security infrastructure to support the "call home" functionality, such as defining new RADIUS extensions? Regards, /david t. perkins ---------- Forwarded message ---------- Date: Wed, 14 Sep 2005 12:15:12 -0700 (PDT) From: David T. Perkins To: isms@ietf.org Subject: [Isms] Tests for ISMS HI, In evaluating any candidate ISMS solution, I'd like to remind all of the tests that I use: 1) What identity credentials does the candidate require from EACH end of the SNMP operation pair?=20 2) Does each end "already have" those credentials due to setting up some other service? If they don't have the credentials, then REJECT the candidate. 3) Does the candidate require that an existing security infrastructure be modified (or extended) for the candidate to work? If so, then REJECT the candidate. 4) Do other "management interfaces" use the same "operations model". If not, then hold the candidate to higher scrutiny.=20 Note that the following are NOT reasons to REJECT a candidate: 1) backwards compatibility with an existing SNMP security model 2) new code for SNMP agents or managers 3) new SNMP terminology and ways of viewing the management model Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 15 16:23:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG0GX-0002Ct-Cy; Thu, 15 Sep 2005 16:23:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG0GW-0002Co-8g for isms@megatron.ietf.org; Thu, 15 Sep 2005 16:23:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08485 for ; Thu, 15 Sep 2005 16:23:24 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG0LK-0005iz-Me for isms@ietf.org; Thu, 15 Sep 2005 16:28:29 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j8FKNABT012435; Thu, 15 Sep 2005 13:23:10 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j8FKN3jH023727; Thu, 15 Sep 2005 13:23:03 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j8FKN3sH023723; Thu, 15 Sep 2005 13:23:03 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 15 Sep 2005 13:23:03 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: kaushik@cisco.com Subject: RE: [Isms] Questions for Call home In-Reply-To: <618694EF0B657246A4D55A97E38274C39E1046@xmb-sjc-22d.amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 2.0 (++) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, Thank you for providing this information. I believe that cable modems are a special case, which can not be used to project to other network infrastucture devices. That is, I believe the cable modems were designed to be primarily (or only) managed via SNMP and have no other management interface. If a cable modem is compromised, I would guess that the only sensitive info would be the private key for the cablem modem's X.509 cert. With these, the exploits could be any that required that identity. Could that allow theft of service? I do appreciate your response, and hope that similar info can be provided for SSH CH. On Thu, 15 Sep 2005 kaushik@cisco.com wrote: > Hi David, > > I can give you a typical example of Call Home from the Cable space since > I being going through some of their specifications. > > PacketCable 1.0 uses SNMPv3 for part of the provisioning, TFTP is used > to download to the actual configuration file. Each MTA is required to > provisioned with a X.509 certificate (actually there are separate certs > for the cable modem and MTA) typically done at manufacturing. The MAC > address is used as CN within the X.509 cert > > The X.509 certificate is shared between SNMPv3 and IPSec that is used > for communication between the MTA and the Call Management Server. > Kerberized SNMPv3 is used for protection of SNMPv3 message, PKINIT is > used for initial authentication and ticket generation. The MAC address > is used as USM user name (identity) within the Kerberized SNMPv3 > exchange, the cable modem (managed device) initiates the exchange. > > Hope this helps. > > regards, > kaushik! > > > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] > On Behalf Of David T. Perkins > Sent: Thursday, September 15, 2005 11:22 AM > To: isms@ietf.org > Subject: [Isms] Questions for Call home > > HI, > > In "call home", > > 1) What identities and credentials are being used? > 2) How are those identities "put on the box"? > 3) Are those identities and credentials there due to > other management operations? > 4) Are they used by other management interfaces? > 5) What are the possible exploits that performed > with identities and credentials from a > compromized system? > 6) Are there any changes that need to be made to > existing security infrastructure to support > the "call home" functionality, such as > defining new RADIUS extensions? > > Regards, > /david t. perkins > > > > ---------- Forwarded message ---------- > Date: Wed, 14 Sep 2005 12:15:12 -0700 (PDT) > From: David T. Perkins > To: isms@ietf.org > Subject: [Isms] Tests for ISMS > > HI, > > In evaluating any candidate ISMS solution, I'd like to remind all of the > tests that I use: > > 1) What identity credentials does the candidate require from EACH end of > the SNMP operation pair? > > 2) Does each end "already have" those credentials due to setting up some > other service? If they don't have the credentials, then REJECT the > candidate. > > 3) Does the candidate require that an existing security infrastructure > be modified (or extended) for the candidate to work? If so, then REJECT > the candidate. > > 4) Do other "management interfaces" use the same "operations model". If > not, then hold the candidate to higher scrutiny. > > > Note that the following are NOT reasons to REJECT a candidate: > 1) backwards compatibility with an existing SNMP security model > 2) new code for SNMP agents or managers > 3) new SNMP terminology and ways of viewing the management model > > Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 15 16:48:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG0ew-0000DM-DV; Thu, 15 Sep 2005 16:48:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG0eu-0000D0-88 for isms@megatron.ietf.org; Thu, 15 Sep 2005 16:48:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09701 for ; Thu, 15 Sep 2005 16:48:37 -0400 (EDT) From: kaushik@cisco.com Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG0jl-0006O1-92 for isms@ietf.org; Thu, 15 Sep 2005 16:53:42 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 15 Sep 2005 13:48:29 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8FKmFKK012669; Thu, 15 Sep 2005 13:48:24 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Sep 2005 13:48:26 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Questions for Call home Date: Thu, 15 Sep 2005 13:48:25 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C39E10B4@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] Questions for Call home Thread-Index: AcW6M1gnzS6g9AsAS2qi4NzAEl5cYAAAXcYg To: "David T. Perkins" X-OriginalArrivalTime: 15 Sep 2005 20:48:26.0408 (UTC) FILETIME=[D1FF0A80:01C5BA36] X-Spam-Score: 2.3 (++) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, Actually the reason I stated the cable case was because cable modems are a typical example of set of CallHome use cases that deal with SOHO devices (and some small branch offices). These include DSL, SOHO routers, Perosnal VPN/Firewall devices etc., these devices required to be managed, i.e. provisioning and monitoring. In most cases, these devices will be behind a NAT/Firewall and cannot be managed by requiring the NMS to initiate requests. The Cable folks have made very specific technology choices such as use of Kerberos but in general terms the notion of device identity and credentials is pretty similar. p.s. - The cable folks uses Syslog & DHCP for provisioning in addition to SNMP and the list of management protocols might grow in the future. regards, kaushik! =20 -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com]=20 Sent: Thursday, September 15, 2005 1:23 PM To: Kaushik Narayan [kaushik@cisco.com] Cc: isms@ietf.org Subject: RE: [Isms] Questions for Call home HI, Thank you for providing this information.=20 I believe that cable modems are a special case, which can not be used to project to other network infrastucture devices. That is, I believe the cable modems were designed to be primarily (or only) managed via SNMP and have no other management interface. If a cable modem is compromised, I would guess that the only sensitive info would be the private key for the cablem modem's X.509 cert. With these, the exploits could be any that required that identity. Could that allow theft of service? I do appreciate your response, and hope that similar info can be provided for SSH CH. On Thu, 15 Sep 2005 kaushik@cisco.com wrote: > Hi David, >=20 > I can give you a typical example of Call Home from the Cable space=20 > since I being going through some of their specifications. >=20 > PacketCable 1.0 uses SNMPv3 for part of the provisioning, TFTP is used > to download to the actual configuration file. Each MTA is required to=20 > provisioned with a X.509 certificate (actually there are separate=20 > certs for the cable modem and MTA) typically done at manufacturing.=20 > The MAC address is used as CN within the X.509 cert >=20 > The X.509 certificate is shared between SNMPv3 and IPSec that is used=20 > for communication between the MTA and the Call Management Server. > Kerberized SNMPv3 is used for protection of SNMPv3 message, PKINIT is=20 > used for initial authentication and ticket generation. The MAC address > is used as USM user name (identity) within the Kerberized SNMPv3=20 > exchange, the cable modem (managed device) initiates the exchange. >=20 > Hope this helps. >=20 > regards, > kaushik! > =20 >=20 > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] > On Behalf Of David T. Perkins > Sent: Thursday, September 15, 2005 11:22 AM > To: isms@ietf.org > Subject: [Isms] Questions for Call home >=20 > HI, >=20 > In "call home", >=20 > 1) What identities and credentials are being used? > 2) How are those identities "put on the box"? > 3) Are those identities and credentials there due to > other management operations? > 4) Are they used by other management interfaces? > 5) What are the possible exploits that performed > with identities and credentials from a > compromized system? > 6) Are there any changes that need to be made to > existing security infrastructure to support > the "call home" functionality, such as > defining new RADIUS extensions? >=20 > Regards, > /david t. perkins >=20 >=20 >=20 > ---------- Forwarded message ---------- > Date: Wed, 14 Sep 2005 12:15:12 -0700 (PDT) > From: David T. Perkins > To: isms@ietf.org > Subject: [Isms] Tests for ISMS >=20 > HI, >=20 > In evaluating any candidate ISMS solution, I'd like to remind all of=20 > the tests that I use: >=20 > 1) What identity credentials does the candidate require from EACH end=20 > of the SNMP operation pair? >=20 > 2) Does each end "already have" those credentials due to setting up=20 > some other service? If they don't have the credentials, then REJECT=20 > the candidate. >=20 > 3) Does the candidate require that an existing security infrastructure > be modified (or extended) for the candidate to work? If so, then=20 > REJECT the candidate. >=20 > 4) Do other "management interfaces" use the same "operations model".=20 > If not, then hold the candidate to higher scrutiny. >=20 >=20 > Note that the following are NOT reasons to REJECT a candidate: > 1) backwards compatibility with an existing SNMP security model > 2) new code for SNMP agents or managers > 3) new SNMP terminology and ways of viewing the management model >=20 >=20 Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 15 18:59:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG2hA-00018w-JP; Thu, 15 Sep 2005 18:59:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFdnH-00057z-4t; Wed, 14 Sep 2005 16:23:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08831; Wed, 14 Sep 2005 16:23:44 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFdrv-0006se-Ik; Wed, 14 Sep 2005 16:28:36 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 14 Sep 2005 13:23:36 -0700 X-IronPort-AV: i="3.97,110,1125903600"; d="scan'208"; a="659800879:sNHT34314984" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8EKNRKC014216; Wed, 14 Sep 2005 13:23:28 -0700 (PDT) Received: from [171.71.192.77] (dhcp-171-71-192-77.cisco.com [171.71.192.77]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j8EKa6KH006472; Wed, 14 Sep 2005 13:36:06 -0700 Message-ID: <432886C4.9040606@cisco.com> Date: Wed, 14 Sep 2005 13:23:32 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ned Freed Subject: Re: [Isms] ISMS charter broken- onus should be on WG to fix it References: <200509131506.j8DF664A016810@pacific-carrier-annex.mit.edu> <20050913204555.GA14153@boskop.local> <3C03BDBD60783D559EDAE652@sirius.fac.cs.cmu.edu> <01LSZP7AGR0Y000092@mauve.mrochek.com> In-Reply-To: <01LSZP7AGR0Y000092@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=269; t=1126730166; x=1127162366; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=mat@cisco.com; z=Subject:Re=3A=20[Isms]=20ISMS=20charter=20broken-=20onus=20should=20be=20on=20WG =20to=20fix=20it| From:Michael=20Thomas=20| Date:Wed,=2014=20Sep=202005=2013=3A23=3A32=20-0700| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=mv0bc/eGfw/exqznCy/VbBzrEHoWathz3FAn2HYwn57BvkAcqnfL2DNZY6Yz78c6s2wwkfDX wDQ3CSm7ZGVuQNhuZuQx0K51EWsmEom22vlNqvxNK6th1boaASGYhiOkyxjm+MQ0bsCQPt0cwaA oN4CH0V383AE8V3D/wjrDF7U= Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 15 Sep 2005 18:59:07 -0400 Cc: david.kessens@nokia.com, 'IETF Discussion' , iesg@ietf.org, Sam Hartman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Ned Freed wrote: > If I were to object to Eliot's proposal (I don't - in fact I strongly > support > it), it would be on the grounds that the IETF should be taking a long > hard look > at the issues surrounding call home in general, not just in the special > case of > SNMP. I'll bite: what could the IETF do if it looked long and hard? Mike _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 15 18:59:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG2hA-00019K-RO; Thu, 15 Sep 2005 18:59:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFgBx-000837-T7; Wed, 14 Sep 2005 18:57:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17656; Wed, 14 Sep 2005 18:57:22 -0400 (EDT) Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFgGd-0002my-N1; Wed, 14 Sep 2005 19:02:17 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LT0ZC70K68008434@mauve.mrochek.com> (original mail from ned.freed@mrochek.com); Wed, 14 Sep 2005 15:57:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1126738632; h=Date: From:Subject:MIME-version:Content-type; b=ISiuRMDlqmOMIWh170YhFZQ21 DX3T3ZOrODlY+uue0aA949oK+BzsuRbW45KPSwEkym5DDRZ4e6FXs7avKJa3g== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LT0PLKLAV4000092@mauve.mrochek.com>; Wed, 14 Sep 2005 15:57:08 -0700 (PDT) To: Michael Thomas Message-id: <01LT0ZC5UEV8000092@mauve.mrochek.com> Date: Wed, 14 Sep 2005 15:47:16 -0700 (PDT) From: Ned Freed Subject: Re: [Isms] ISMS charter broken- onus should be on WG to fix it In-reply-to: "Your message dated Wed, 14 Sep 2005 13:23:32 -0700" <432886C4.9040606@cisco.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed References: <200509131506.j8DF664A016810@pacific-carrier-annex.mit.edu> <20050913204555.GA14153@boskop.local> <3C03BDBD60783D559EDAE652@sirius.fac.cs.cmu.edu> <01LSZP7AGR0Y000092@mauve.mrochek.com> <432886C4.9040606@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Thu, 15 Sep 2005 18:59:07 -0400 Cc: isms@ietf.org, david.kessens@nokia.com, Ned Freed , 'IETF Discussion' , Sam Hartman , iesg@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > Ned Freed wrote: > > If I were to object to Eliot's proposal (I don't - in fact I strongly > > support > > it), it would be on the grounds that the IETF should be taking a long > > hard look > > at the issues surrounding call home in general, not just in the special > > case of > > SNMP. > I'll bite: what could the IETF do if it looked > long and hard? Well, the one approach that immediately comes to mind is that the introduction of a third party might provide a means of getting timely information about software updates without sacrificing user privacy. Such a third party would act as a repository for update information provided by vendors. Applications would then "call home" to one of these repositories rather than directly to the vendor. Various anonymyzing tricks could be employed to minimize information leakage even if the third party was compromised. Mind you, thiis all off the top of my head. This may not work for some reason I haven't considered, or there may be other, better approaches. Ned _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 15 18:59:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG2hC-00019h-0h; Thu, 15 Sep 2005 18:59:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFhfj-00087F-VN; Wed, 14 Sep 2005 20:32:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22420; Wed, 14 Sep 2005 20:32:14 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFhkQ-0005Sc-KN; Wed, 14 Sep 2005 20:37:07 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 14 Sep 2005 17:32:05 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8F0W24u022753; Wed, 14 Sep 2005 17:32:02 -0700 (PDT) Received: from [171.71.192.77] (dhcp-171-71-192-77.cisco.com [171.71.192.77]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j8F0iZfI008836; Wed, 14 Sep 2005 17:44:35 -0700 Message-ID: <4328C102.2010201@cisco.com> Date: Wed, 14 Sep 2005 17:32:02 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ned Freed Subject: Re: [Isms] ISMS charter broken- onus should be on WG to fix it References: <200509131506.j8DF664A016810@pacific-carrier-annex.mit.edu> <20050913204555.GA14153@boskop.local> <3C03BDBD60783D559EDAE652@sirius.fac.cs.cmu.edu> <01LSZP7AGR0Y000092@mauve.mrochek.com> <432886C4.9040606@cisco.com> <01LT0ZC5UEV8000092@mauve.mrochek.com> In-Reply-To: <01LT0ZC5UEV8000092@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=853; t=1126745075; x=1127177275; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=mat@cisco.com; z=Subject:Re=3A=20[Isms]=20ISMS=20charter=20broken-=20onus=20should=20be=20on=20WG =20to=20fix=20it| From:Michael=20Thomas=20| Date:Wed,=2014=20Sep=202005=2017=3A32=3A02=20-0700| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=CNiujVWXNBOFZHJ97kvlChyfXg8MYDB2zH1Z/NccSqARbjLyOXtFEn1vpaXdXrx9QpwlJp7J tU4SJVexHkc+zOobR80cBHJ3BcW8YN2ESBBPrbISMJsKmPf2y9TlWPassa468UMO4ldu+95CfZ8 k0hsbXjZ6HCCtQwPqMrdFW1E= Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 15 Sep 2005 18:59:07 -0400 Cc: david.kessens@nokia.com, isms@ietf.org, 'IETF Discussion' , Sam Hartman , iesg@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Ned Freed wrote: >> Ned Freed wrote: >> > If I were to object to Eliot's proposal (I don't - in fact I strongly >> > support >> > it), it would be on the grounds that the IETF should be taking a long >> > hard look >> > at the issues surrounding call home in general, not just in the special >> > case of >> > SNMP. > > >> I'll bite: what could the IETF do if it looked >> long and hard? > > > Well, the one approach that immediately comes to mind is that the > introduction > of a third party might provide a means of getting timely information about > software updates without sacrificing user privacy. > > Such a third party would act as a repository for update information > provided by > vendors. Applications would then "call home" to one of these repositories > rather than directly to the vendor. Various anonymyzing tricks could be > employed to minimize information leakage even if the third party was > compromised. You mean we could invent Bitorrent? :) Mike, doesn't it strike others as odd that ietf is completely outside of the p2p bizness? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 16 02:48:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGA1Y-0007Xd-GN; Fri, 16 Sep 2005 02:48:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGA1X-0007XY-1Y for isms@megatron.ietf.org; Fri, 16 Sep 2005 02:48:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27869 for ; Fri, 16 Sep 2005 02:48:37 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGA6U-0003d1-73 for isms@ietf.org; Fri, 16 Sep 2005 02:53:46 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id CA64511D44C; Thu, 15 Sep 2005 23:48:24 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Thu, 15 Sep 2005 23:48:22 -0700 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: Subject: [Isms] ISMS/SSH implementation report X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Now that I've caught your attention, I'm going to state more clearly I had a few hours to kill a few nights (hah) and wondered how quickly I could do a "hack" to get something working. My biggest question was, given the Net-SNMP stack, how much of a pain it was going to be to implement a tunneled protocol given the current signaling between different sections of the code. Specifically, I was most curious about how passing information from the transport layer all the way to the security layer was going to work out if I didn't want to modify the API sets at all. More importantly: this was a hack. It was a huge hack. It is not efficient nor is it implemented in a way that would be a reasonable way to do things in the long run. Details below. Have I mentioned this was a hack? Please don't slam the experiment below as being secure, robust, etc. It was a just an experiment. But I thought I'd at least report it. The results were that the total time I spent was about 4 and a half hours (4.42). Which isn't much time. (a bit more reading of code was involved beyond that time accumulation). Stack Modification Details: -------------------------------------------------- The hardest part about doing this wasn't the majority of the straight forward hack described below. The hardest part was making the transport (dispatcher in SNMPv3 speak) pass data to the local security model about the fact that the packet had arrived over a "trusted" mechanism (more below). I was most paranoid about having to modify APIs in order to pass that information around. Fortunately it only required modification of a structure and of the internals of a function. This was due to a large redesign that happened during the creation of the kerberos security model, however, where the API was left flexible through the passing of parameter structures rather than a fixed API (IE, the ASI data was passed through a structure instead). Hack details: -------------------------------------------------- Net-SNMP is very flexible with transports it can make use of. Because of this, adding a new one was fairly trivial. Adding SSH, however, was not going to be trivial because the lack of public libraries that would allow the easy addition of SSH code directly into Net-SNMP. So, I did the next worst thing: I added support for input and output to and from either stdin/stdout or from a application. This would easily allow for SNMP messages to be sent over just about anything, including directly to another application. The strangest invocation would be something like the following (I'm using this as an example because it gets more complex when we start involving ssh): % snmpget -t 5 'std:snmpd -f -Le -r std:' sysContact.0 SNMPv2-MIB::sysContact.0 = STRING: hardaker@ The above executes a GET PDU piped to the special designation name beginning with std: in single quotes, which in this case is the direct invocation of the agent who in turn was passed a port to open of 'std:' which is the magical invocation of stdin/out. IE, a pipe is opened by the snmpget application to and from the snmpd application. snmpd is invoked with the std: token to indicate it should open a channel from stdin, and respond back on stdout. snmpget, on the other hand, speaks to and from the pipe to the opened snmpd application. A large timeout (5 seconds) was needed to ensure the agent would start up within that time period. It is important to note that this is still sending SNMPv3/USM between the apps. To assume that the local user was the securityName to be used for the transaction, a "local" security model had to be developed. Which I also implemented where the internals did no checking of the packet and merely took the security name from the local process information. (and then, of course, that user name with that security model would have to be added to the VACM which was also done in the configuration of the agent). So, by doing this I'd no longer be tunneling USM and it's security but would rather be tunneling v3 with a 'local' security model. FYI, the local security model does no packet checking and has an empty security parameters field and forces the security level of the PDU to be flagged as noAuthNoPriv since it doesn't know the detail of the transport. Putting real ssh in place directly as a transport would fix this as the code really would know what the level was. If this code was left around in the future, I'd modify it to include an optional default context engineID probe. Finally, the code checks to make sure that the packet came in over a non-network transport (currently only the std: transport of some form). Not doing this would let UDP packets to trigger the local SM into thinking that the user name to pass to VACM was the user the agent was running at without any sort of authentication. %snmpget -u hardaker --defSecurityModel=localsm -t 5 'std:snmpd -f -Le -r std:' sysContact.0 SNMPv2-MIB::sysContact.0 = STRING: hardaker@ (in the config file was: "rouser -s localsm hardaker noauth") So, the next was to link these two stages through ssh. To do this, the sshd configuration was modified to call snmpd when the isms subsystem was invoked: Subsystem isms /bin/ismssnmpd and that program merely launched: snmpd -f -Le -r std: 2> /tmp/sshd.snmp.log Finally, snmpget could then invoke ssh to connect to the remote agent under the isms subsystem (everything was done connect to the localhost): % snmpget -u hardaker --defSecurityModel=localsm -t 5 'std:ssh -s localhost isms' sysContact.0 SNMPv2-MIB::sysContact.0 = STRING: hardaker@ Whew. And it worked (ok, not the first time of course). The ssh client logged me into the local server using my public/private key pair and executed the agent (as me) to pass the SNMP PDUs to. I'll be impressed if anyone understands the above given the attempt at a brief description of something fairly complex... Reminder: this was a hack test. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 16 03:25:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGAao-0007SF-60; Fri, 16 Sep 2005 03:25:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGAal-0007Rj-OG for isms@megatron.ietf.org; Fri, 16 Sep 2005 03:25:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29333 for ; Fri, 16 Sep 2005 03:25:01 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGAfi-0004Yk-MD for isms@ietf.org; Fri, 16 Sep 2005 03:30:12 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 16 Sep 2005 00:24:53 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8G7Ol4u002260; Fri, 16 Sep 2005 00:24:48 -0700 (PDT) Received: from [212.254.247.3] (ams-clip-vpn-dhcp4218.cisco.com [10.61.80.121]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j8G7bI6i021517; Fri, 16 Sep 2005 00:37:18 -0700 Message-ID: <432A7341.1030102@cisco.com> Date: Fri, 16 Sep 2005 09:24:49 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wes Hardaker Subject: Re: [Isms] ISMS/SSH implementation report References: In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1166; t=1126856239; x=1127288439; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20ISMS/SSH=20implementation=20report| From:Eliot=20Lear=20| Date:Fri,=2016=20Sep=202005=2009=3A24=3A49=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=rDSZ6YASuCFg7mN36GLypz7SsPQvGfZ/Yt/i1A2XxLhjO/0aifu6/rumS8ennLEODVRpm7en xvn8J2AbIJDf4Q1F2imBiEYhy+sCgcRxRU7jUbfIT3pAb8T5B5h+8K1EDvCpTkc4+dVgxPHr0LQ lhV64ZO61Vk8suh/fX7YIjyU= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Wes, Nice work. Please see below. > Net-SNMP is very flexible with transports it can make use of. Because > of this, adding a new one was fairly trivial. Adding SSH, however, > was not going to be trivial because the lack of public libraries that > would allow the easy addition of SSH code directly into Net-SNMP. Yah, I've noticed the sorry state of affairs of OpenSSH's libraries as well. > So, > I did the next worst thing: I added support for input and output to > and from either stdin/stdout or from a application. WHAT A KLUDGE! WHAT A HACK! HOW COULD YOU?! just kidding ;-) Actually it demonstrates something else... see below. > [...] > So, the next was to link these two stages through ssh. To do this, > the sshd configuration was modified to call snmpd when the isms > subsystem was invoked: > > Subsystem isms /bin/ismssnmpd > > and that program merely launched: > > snmpd -f -Le -r std: 2> /tmp/sshd.snmp.log So, to implement CH functionality, all one would need to do in your hack would be on one end to do the the following: agent% ssh -p {ISMS-port} -s isms-turn user@manager snmpd -f -Le -r std: 2> /tmp/isms-turn.log and on the other end... Subsystem issms /bin/isms-turn Where... isms-turn pipes, forks (in the simple similarly ugly way), and execs something along the following lines: exec("/usr/bin/snmpget", "--defSecurityModel=localsm", "std:???",...) Not quite sure of ???... Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 16 03:31:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGAhH-0008Ra-7s; Fri, 16 Sep 2005 03:31:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGAhG-0008RV-9Q for isms@megatron.ietf.org; Fri, 16 Sep 2005 03:31:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29639 for ; Fri, 16 Sep 2005 03:31:44 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGAm9-0004lM-74 for isms@ietf.org; Fri, 16 Sep 2005 03:36:54 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 67C3E3A94E; Fri, 16 Sep 2005 09:31:21 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 13436-07; Fri, 16 Sep 2005 09:31:20 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 358E43A8ED; Fri, 16 Sep 2005 09:31:20 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 601993FD661; Fri, 16 Sep 2005 09:31:20 +0200 (CEST) Date: Fri, 16 Sep 2005 09:31:20 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Subject: Re: [Isms] ISMS/SSH implementation report Message-ID: <20050916073120.GA15999@boskop.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.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Thu, Sep 15, 2005 at 11:48:22PM -0700, Wes Hardaker wrote: > Net-SNMP is very flexible with transports it can make use of. Because > of this, adding a new one was fairly trivial. Adding SSH, however, > was not going to be trivial because the lack of public libraries that > would allow the easy addition of SSH code directly into Net-SNMP. There is an LGPLed implementation called libssh which offers an API. Unfortunately, this seems to be client side only at the moment... /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 16 04:14:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGBLs-0002fX-FV; Fri, 16 Sep 2005 04:13:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGBLq-0002f4-7Q for isms@megatron.ietf.org; Fri, 16 Sep 2005 04:13:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01652 for ; Fri, 16 Sep 2005 04:13:39 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGBQn-00068u-Gp for isms@ietf.org; Fri, 16 Sep 2005 04:18:50 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 16 Sep 2005 01:13:32 -0700 X-IronPort-AV: i="3.97,115,1125903600"; d="scan'208"; a="660178627:sNHT32293444" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8G8DR4u018892; Fri, 16 Sep 2005 01:13:27 -0700 (PDT) Received: from [212.254.247.3] (ams-clip-vpn-dhcp4651.cisco.com [10.61.82.42]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j8G8Puhp021764; Fri, 16 Sep 2005 01:25:57 -0700 Message-ID: <432A7EA8.6000809@cisco.com> Date: Fri, 16 Sep 2005 10:13:28 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David T. Perkins" Subject: Re: [Isms] Questions for Call home References: In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1905; t=1126859157; x=1127291357; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20Questions=20for=20Call=20home| From:Eliot=20Lear=20| Date:Fri,=2016=20Sep=202005=2010=3A13=3A28=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=WIgzMZxSKAnw/sW/O7c7fU2v2bzIMflphA3NVajleKMbIDVDc7nwrQhpYw3vrGyTE+0S1h+4 fZ1vfbRFYA7YGg13TcYmS70uV68RhDiVeg9AjwdZg9vHopkjwh4Wcuwv4tmHoN22BjUrXB1L3M/ YXHASmqova2XDAKFdOaM6ES8= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 2.0 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dave, You asked a bunch of questions relating to CH. Please see below: > 1) What identities and credentials are being used? Borrowing from BEEP terminology for the moment, the initiator and listener will use any authentication mechanism supported by the underlying mapping protocol. That is to say, for SSH, the responder is configured to authenticate to the command generator via an appropriate SSH mechanism such as a user name and password. The generator would authenticate via a host key or other mechanism defined with SSH. The SNMP command generator is assigned an identity by the responder at the time of invocation and as part of configuration. > 2) How are those identities "put on the box"? In the case of user name/password authentication, the command responder is configured via configuration functions. This may include updating of various VACM tables once the connection is established. The command generator may hold the identities locally or may use a protocol such as radius, diameter, or TACACS+. > 3) Are those identities and credentials there due to > other management operations? On the command responder this will likely be the case. The command generator would use the same database used for other authentication. > 4) Are they used by other management interfaces? Quite possibly netconf as well as PPP. Other uses are possible, such as local consumer email access, account management web sites, etc. > 5) What are the possible exploits that performed > with identities and credentials from a > compromized system? I do not claim this is a complete analysis. However... If the command generator is compromised the exposure is the same as if any other command generator is compromised. If the command responder is compromised, its configuration and potentially and some identity information relating to its configuration may be exposed. The credentials used to authenticate administrative user access to the responder are not envisioned to be the same as those used by the responder to authenticate to the generator. Remember, the responder is requesting to be managed. > 6) Are there any changes that need to be made to > existing security infrastructure to support > the "call home" functionality, such as > defining new RADIUS extensions? No. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 16 05:11:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGCFb-0007eW-EB; Fri, 16 Sep 2005 05:11:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGCFZ-0007eN-D3 for isms@megatron.ietf.org; Fri, 16 Sep 2005 05:11:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03581 for ; Fri, 16 Sep 2005 05:11:14 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGCKW-0007cP-JI for isms@ietf.org; Fri, 16 Sep 2005 05:16:26 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id F0A5D3A839; Fri, 16 Sep 2005 11:11:04 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 22812-04; Fri, 16 Sep 2005 11:11:03 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 836DF3AA3C; Fri, 16 Sep 2005 11:11:02 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 8825F3FD79C; Fri, 16 Sep 2005 11:11:02 +0200 (CEST) Date: Fri, 16 Sep 2005 11:11:02 +0200 From: Juergen Schoenwaelder To: Eliot Lear Subject: Re: [Isms] Questions for Call home Message-ID: <20050916091102.GB16202@boskop.local> Mail-Followup-To: Eliot Lear , "David T. Perkins" , isms@ietf.org References: <432A7EA8.6000809@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <432A7EA8.6000809@cisco.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Fri, Sep 16, 2005 at 10:13:28AM +0200, Eliot Lear wrote: > You asked a bunch of questions relating to CH. Please see below: > > > 1) What identities and credentials are being used? > > Borrowing from BEEP terminology for the moment, the initiator and > listener will use any authentication mechanism supported by the > underlying mapping protocol. That is to say, for SSH, the responder is > configured to authenticate to the command generator via an appropriate > SSH mechanism such as a user name and password. The generator would > authenticate via a host key or other mechanism defined with SSH. So you are saying that for CH, the entity with the command generator you have to authenticate the user identity, that is the "agent" logs into the "manager" by sending a user identity and a password. So how does the agent then later on when the "manager" sends a request do the access control decision? As far as I can tell, the "agent" does not really have an authenticated securityName - the only thing the "agent" has is an authenticated host identity. Can you explain how you envision to resolve this? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 16 05:50:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGCrk-0000yf-Bj; Fri, 16 Sep 2005 05:50:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGCri-0000xJ-Bx for isms@megatron.ietf.org; Fri, 16 Sep 2005 05:50:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05782 for ; Fri, 16 Sep 2005 05:50:39 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGCwg-0000Mq-Gb for isms@ietf.org; Fri, 16 Sep 2005 05:55:51 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 16 Sep 2005 02:50:29 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8G9oQ4u023150; Fri, 16 Sep 2005 02:50:26 -0700 (PDT) Received: from [212.254.247.3] (ams-clip-vpn-dhcp529.cisco.com [10.61.66.17]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j8GA2rjx022216; Fri, 16 Sep 2005 03:02:54 -0700 Message-ID: <432A9561.1090703@cisco.com> Date: Fri, 16 Sep 2005 11:50:25 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de Subject: Re: [Isms] Questions for Call home References: <432A7EA8.6000809@cisco.com> <20050916091102.GB16202@boskop.local> In-Reply-To: <20050916091102.GB16202@boskop.local> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=833; t=1126864974; x=1127297174; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20Questions=20for=20Call=20home| From:Eliot=20Lear=20| Date:Fri,=2016=20Sep=202005=2011=3A50=3A25=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=kAZleKN/O1tk/HIE3RfxTVzgBpkX/oASHCEjUgWcGA0MdDH3m4TntBbEMiSXFLugZu5529Uo EzlRuVhmoAJ1tjeMT29kd91RMM8a5NG9geMIBd0g6PdHHEYzczbARHDSpWC4ZKJpYn25e3ShY+l q2jDqqejHnK3dzEPLhiksjBs= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen, > So you are saying that for CH, the entity with the command generator > you have to authenticate the user identity, that is the "agent" logs > into the "manager" by sending a user identity and a password. So how > does the agent then later on when the "manager" sends a request do the > access control decision? As far as I can tell, the "agent" does not > really have an authenticated securityName - the only thing the "agent" > has is an authenticated host identity. > > Can you explain how you envision to resolve this? I believe I commented on this in the same message. I envision the agent being configured with an identity that it would associate with the session. So in pseudo-command parlance: snmp-server call-home host 192.168.1.1 user eliot password LetMeIn snmp-user-is nocadmin Where 192.168.1.1 is the manager, the user and password to access the manager are 192.168.1.1 and password are eliot and LetMeIn, respectively. Where [ snmp-user-is .... ] might have default values. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 16 09:44:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGGW3-0001M6-Qo; Fri, 16 Sep 2005 09:44:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGGW0-0001Kw-5P for isms@megatron.ietf.org; Fri, 16 Sep 2005 09:44:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17527 for ; Fri, 16 Sep 2005 09:44:29 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGGb0-0006jW-C3 for isms@ietf.org; Fri, 16 Sep 2005 09:49:43 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 9721B11D44C; Fri, 16 Sep 2005 06:44:27 -0700 (PDT) From: Wes Hardaker To: Eliot Lear Subject: Re: [Isms] ISMS/SSH implementation report Organization: Sparta References: <432A7341.1030102@cisco.com> Date: Fri, 16 Sep 2005 06:44:26 -0700 In-Reply-To: <432A7341.1030102@cisco.com> (Eliot Lear's message of "Fri, 16 Sep 2005 09:24:49 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Fri, 16 Sep 2005 09:24:49 +0200, Eliot Lear said: Eliot> So, to implement CH functionality, all one would need to do in your hack Eliot> would be on one end to do the the following: Yeah, I almost tried to include that within the report too but in the end it didn't quite work. It'll take a bit more modification. However, fundamentally you're right that it should work about the same way. The agent, of course, has to have credentials and this is where currently this isn't deployed as most credentials out there are for the agent side and are not user based which is what is ideally needed for sending notifications. (this is one of the points that David P. has been trying to state I believe). Technically there is no reason you couldn't use the host key as a user key when sending a notification, but it's not necessarily something you'd want to do. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 16 12:22:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGIyT-0002Kj-D6; Fri, 16 Sep 2005 12:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGIyN-0002Gy-DY for isms@megatron.ietf.org; Fri, 16 Sep 2005 12:22:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27310 for ; Fri, 16 Sep 2005 12:21:56 -0400 (EDT) From: kaushik@cisco.com Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGJ3N-0002g4-V9 for isms@ietf.org; Fri, 16 Sep 2005 12:27:12 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 16 Sep 2005 09:21:48 -0700 X-IronPort-AV: i="3.97,117,1125903600"; d="scan'208"; a="342367384:sNHT41026156" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8GGL753022354; Fri, 16 Sep 2005 09:21:44 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 09:21:44 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Questions for Call home Date: Fri, 16 Sep 2005 09:21:43 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C39E132F@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] Questions for Call home Thread-Index: AcW6nqpQD7U72uncTsWE8Sy6Qd0pXAAOGD/w To: , "Eliot Lear" X-OriginalArrivalTime: 16 Sep 2005 16:21:44.0221 (UTC) FILETIME=[BA5CD4D0:01C5BADA] X-Spam-Score: 0.3 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Juergen, Eliot, I think we need to keep in mind the SNMPv3/USM model when we talk about identity. The role of ISMS is to provide flexible authentication and key management without modifying the notion of identity within USM. From a security perspective the only identity USM deals with is the securityName, i.e. SNMP principal (SNMP engine ID is really not authenticated). What the means is that irrespective of the SNMP engine that initiates the conversation (CH or otherwise), command generators and notification generators MUST authenticate using SNMP securityName( using the SSH user authentication protocol) Regards, kaushik! =20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Friday, September 16, 2005 2:11 AM To: Eliot Lear Cc: isms@ietf.org Subject: Re: [Isms] Questions for Call home On Fri, Sep 16, 2005 at 10:13:28AM +0200, Eliot Lear wrote: > You asked a bunch of questions relating to CH. Please see below: >=20 > > 1) What identities and credentials are being used? >=20 > Borrowing from BEEP terminology for the moment, the initiator and=20 > listener will use any authentication mechanism supported by the=20 > underlying mapping protocol. That is to say, for SSH, the responder=20 > is configured to authenticate to the command generator via an=20 > appropriate SSH mechanism such as a user name and password. The=20 > generator would authenticate via a host key or other mechanism defined with SSH. So you are saying that for CH, the entity with the command generator you have to authenticate the user identity, that is the "agent" logs into the "manager" by sending a user identity and a password. So how does the agent then later on when the "manager" sends a request do the access control decision? As far as I can tell, the "agent" does not really have an authenticated securityName - the only thing the "agent" has is an authenticated host identity. Can you explain how you envision to resolve this? /js --=20 Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 16 13:00:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGJZK-0003Kr-UE; Fri, 16 Sep 2005 13:00:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGJZJ-0003Kl-BG for isms@megatron.ietf.org; Fri, 16 Sep 2005 13:00:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29115 for ; Fri, 16 Sep 2005 13:00:05 -0400 (EDT) From: kaushik@cisco.com Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGJeL-0003hb-5Y for isms@ietf.org; Fri, 16 Sep 2005 13:05:22 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 16 Sep 2005 09:59:58 -0700 X-IronPort-AV: i="3.97,117,1125903600"; d="scan'208"; a="342386166:sNHT51874660" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8GGxQ4x025300; Fri, 16 Sep 2005 09:59:56 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 09:59:51 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Questions for Call home Date: Fri, 16 Sep 2005 09:59:50 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C39E1359@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] Questions for Call home Thread-Index: AcW6nqpQD7U72uncTsWE8Sy6Qd0pXAAOGD/wAAHep1A= To: , "Eliot Lear" X-OriginalArrivalTime: 16 Sep 2005 16:59:51.0025 (UTC) FILETIME=[0D676E10:01C5BAE0] X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org My previous statement had some ambiguity. Here is a second try I think we need to keep in mind RFC3411 when we talk about identity. The role of ISMS is to provide flexible authentication and key management without modifying the notion of identity within RFC3411. From a security perspective the only identity RFC3411 deals with is the securityName, i.e. SNMP principal (SNMP engine ID is really not authenticated). What the means is that irrespective of the SNMP engine that initiates the conversation (CH or otherwise), any command generators and notification generators which generates/sends a message in the conversation MUST authenticate using SNMP securityName (using the SSH user authentication protocol) -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Kaushik Narayan [kaushik@cisco.com] Sent: Friday, September 16, 2005 9:22 AM To: j.schoenwaelder@iu-bremen.de; Eliot Lear Cc: isms@ietf.org Subject: RE: [Isms] Questions for Call home Hi Juergen, Eliot, I think we need to keep in mind the SNMPv3/USM model when we talk about identity. The role of ISMS is to provide flexible authentication and key management without modifying the notion of identity within USM. From a security perspective the only identity USM deals with is the securityName, i.e. SNMP principal (SNMP engine ID is really not authenticated). What the means is that irrespective of the SNMP engine that initiates the conversation (CH or otherwise), command generators and notification generators MUST authenticate using SNMP securityName( using the SSH user authentication protocol) Regards, kaushik! =20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Friday, September 16, 2005 2:11 AM To: Eliot Lear Cc: isms@ietf.org Subject: Re: [Isms] Questions for Call home On Fri, Sep 16, 2005 at 10:13:28AM +0200, Eliot Lear wrote: > You asked a bunch of questions relating to CH. Please see below: >=20 > > 1) What identities and credentials are being used? >=20 > Borrowing from BEEP terminology for the moment, the initiator and=20 > listener will use any authentication mechanism supported by the=20 > underlying mapping protocol. That is to say, for SSH, the responder=20 > is configured to authenticate to the command generator via an=20 > appropriate SSH mechanism such as a user name and password. The=20 > generator would authenticate via a host key or other mechanism defined with SSH. So you are saying that for CH, the entity with the command generator you have to authenticate the user identity, that is the "agent" logs into the "manager" by sending a user identity and a password. So how does the agent then later on when the "manager" sends a request do the access control decision? As far as I can tell, the "agent" does not really have an authenticated securityName - the only thing the "agent" has is an authenticated host identity. Can you explain how you envision to resolve this? /js --=20 Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 16 13:54:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGKQL-0008MU-Rf; Fri, 16 Sep 2005 13:54:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGKQL-0008MP-1Y for isms@megatron.ietf.org; Fri, 16 Sep 2005 13:54:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01303 for ; Fri, 16 Sep 2005 13:54:55 -0400 (EDT) Message-Id: <200509161754.NAA01303@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGKVM-0004xJ-98 for isms@ietf.org; Fri, 16 Sep 2005 14:00:10 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005091617544401400109mee>; Fri, 16 Sep 2005 17:54:44 +0000 From: "David B Harrington" To: , , "'Eliot Lear'" Subject: RE: [Isms] Questions for Call home Date: Fri, 16 Sep 2005 13:54:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW6nqpQD7U72uncTsWE8Sy6Qd0pXAAOGD/wAAHep1AAAck3AA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <618694EF0B657246A4D55A97E38274C39E1359@xmb-sjc-22d.amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I'm not sure I agree with your statement. Your last sentence says "MUST authenticate using SNMP securityName. I believe that is incorrect. It is acceptable to have a mapping from the SNMP securityName to a model-specific identity, and to perform the authentication using the model-specific identity. One way to change your statement would be to say "MUST authenticate SNMP securityName". dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of kaushik@cisco.com > Sent: Friday, September 16, 2005 1:00 PM > To: j.schoenwaelder@iu-bremen.de; Eliot Lear > Cc: isms@ietf.org > Subject: RE: [Isms] Questions for Call home > > > My previous statement had some ambiguity. Here is a second try > > I think we need to keep in mind RFC3411 when we talk about > identity. The > role of ISMS is to provide flexible authentication and key management > without modifying the notion of identity within RFC3411. From > a security > perspective the only identity RFC3411 deals with is the securityName, > i.e. SNMP principal (SNMP engine ID is really not authenticated). What > the means is that irrespective of the SNMP engine that initiates the > conversation (CH or otherwise), any command generators and > notification > generators which generates/sends a message in the conversation MUST > authenticate using SNMP securityName (using the SSH user > authentication > protocol) > > > > > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] > On Behalf Of Kaushik Narayan [kaushik@cisco.com] > Sent: Friday, September 16, 2005 9:22 AM > To: j.schoenwaelder@iu-bremen.de; Eliot Lear > Cc: isms@ietf.org > Subject: RE: [Isms] Questions for Call home > > Hi Juergen, Eliot, > > I think we need to keep in mind the SNMPv3/USM model when we > talk about > identity. The role of ISMS is to provide flexible > authentication and key > management without modifying the notion of identity within USM. From a > security perspective the only identity USM deals with is the > securityName, i.e. SNMP principal (SNMP engine ID is really not > authenticated). What the means is that irrespective of the SNMP engine > that initiates the conversation (CH or otherwise), command generators > and notification generators MUST authenticate using SNMP securityName( > using the SSH user authentication protocol) > > Regards, > kaushik! > > > > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] > On Behalf Of Juergen Schoenwaelder > Sent: Friday, September 16, 2005 2:11 AM > To: Eliot Lear > Cc: isms@ietf.org > Subject: Re: [Isms] Questions for Call home > > On Fri, Sep 16, 2005 at 10:13:28AM +0200, Eliot Lear wrote: > > > You asked a bunch of questions relating to CH. Please see below: > > > > > 1) What identities and credentials are being used? > > > > Borrowing from BEEP terminology for the moment, the initiator and > > listener will use any authentication mechanism supported by the > > underlying mapping protocol. That is to say, for SSH, the > responder > > is configured to authenticate to the command generator via an > > appropriate SSH mechanism such as a user name and password. The > > generator would authenticate via a host key or other > mechanism defined > with SSH. > > So you are saying that for CH, the entity with the command > generator you > have to authenticate the user identity, that is the "agent" logs into > the "manager" by sending a user identity and a password. So > how does the > agent then later on when the "manager" sends a request do the access > control decision? As far as I can tell, the "agent" does not > really have > an authenticated securityName - the only thing the "agent" > has is an authenticated host identity. > > Can you explain how you envision to resolve this? > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, > Germany > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 16 14:05:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGKal-0002jh-My; Fri, 16 Sep 2005 14:05:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGKak-0002il-4N for isms@megatron.ietf.org; Fri, 16 Sep 2005 14:05:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01858 for ; Fri, 16 Sep 2005 14:05:40 -0400 (EDT) From: kaushik@cisco.com Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGKfl-0005FE-Jj for isms@ietf.org; Fri, 16 Sep 2005 14:10:55 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 16 Sep 2005 11:05:26 -0700 X-IronPort-AV: i="3.97,117,1125903600"; d="scan'208"; a="660283488:sNHT31052688" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8GI5L4X010381; Fri, 16 Sep 2005 11:05:23 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 11:05:15 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Questions for Call home Date: Fri, 16 Sep 2005 11:05:13 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C39E13D9@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] Questions for Call home Thread-Index: AcW6nqpQD7U72uncTsWE8Sy6Qd0pXAAOGD/wAAHep1AAAck3AAAAkUxw To: , , "Eliot Lear" X-OriginalArrivalTime: 16 Sep 2005 18:05:15.0350 (UTC) FILETIME=[307BE760:01C5BAE9] X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Dave, I'm not sure I agree with your statement. Your last sentence says "MUST authenticate using SNMP securityName. I believe that is incorrect. It is acceptable to have a mapping from the SNMP securityName to a model-specific identity, and to perform the authentication using the model-specific identity. One way to change your statement would be to say "MUST authenticate SNMP securityName".=20 You are right but I did not intend my statement to preclude mapping of securityName. I think your correction is valid. =20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 16 15:38:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGM2R-0001Ct-2C; Fri, 16 Sep 2005 15:38:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGM2P-0001Cm-SL for isms@megatron.ietf.org; Fri, 16 Sep 2005 15:38:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07580 for ; Fri, 16 Sep 2005 15:38:19 -0400 (EDT) Message-Id: <200509161938.PAA07580@ietf.org> Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGM7S-0007bd-UD for isms@ietf.org; Fri, 16 Sep 2005 15:43:36 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <2005091619380901400ohk73e>; Fri, 16 Sep 2005 19:38:10 +0000 From: "David B Harrington" To: , , "'Eliot Lear'" Subject: RE: [Isms] Questions for Call home Date: Fri, 16 Sep 2005 15:38:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW6nqpQD7U72uncTsWE8Sy6Qd0pXAAOGD/wAAHep1AABHRxQA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <618694EF0B657246A4D55A97E38274C39E1359@xmb-sjc-22d.amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, 1) I have a concern with statements that certain types of applications must authenticate. I don't believe that is an architectural requirement, but more a factor of the way USM works. I believe a new security model could do things differently, and new applications could be written that had different requirements for authentication. 2) It is incorrect to say that "any command generators and notification generators which generates/sends a message in the conversation MUST authenticate" - SNMPv3 also supports noAuthNoPriv. dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of kaushik@cisco.com > Sent: Friday, September 16, 2005 1:00 PM > To: j.schoenwaelder@iu-bremen.de; Eliot Lear > Cc: isms@ietf.org > Subject: RE: [Isms] Questions for Call home > > > My previous statement had some ambiguity. Here is a second try > > I think we need to keep in mind RFC3411 when we talk about > identity. The > role of ISMS is to provide flexible authentication and key management > without modifying the notion of identity within RFC3411. From > a security > perspective the only identity RFC3411 deals with is the securityName, > i.e. SNMP principal (SNMP engine ID is really not authenticated). What > the means is that irrespective of the SNMP engine that initiates the > conversation (CH or otherwise), any command generators and > notification > generators which generates/sends a message in the conversation MUST > authenticate using SNMP securityName (using the SSH user > authentication > protocol) > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 16 16:51:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGNAv-0004SK-0U; Fri, 16 Sep 2005 16:51:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGNAr-0004SA-C1 for isms@megatron.ietf.org; Fri, 16 Sep 2005 16:51:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18999 for ; Fri, 16 Sep 2005 16:51:06 -0400 (EDT) From: kaushik@cisco.com Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGNFw-0003rG-B6 for isms@ietf.org; Fri, 16 Sep 2005 16:56:24 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 16 Sep 2005 13:51:00 -0700 X-IronPort-AV: i="3.97,117,1125903600"; d="scan'208"; a="342463056:sNHT64296234" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8GKoN4t021069; Fri, 16 Sep 2005 13:50:57 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 13:50:54 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Questions for Call home Date: Fri, 16 Sep 2005 13:50:53 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C39E1491@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] Questions for Call home Thread-Index: AcW6nqpQD7U72uncTsWE8Sy6Qd0pXAAOGD/wAAHep1AABHRxQAABuDMw To: , , "Eliot Lear" X-OriginalArrivalTime: 16 Sep 2005 20:50:54.0816 (UTC) FILETIME=[54DE0E00:01C5BB00] X-Spam-Score: 0.3 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, Please find my reply inline. 1) I have a concern with statements that certain types of applications must authenticate. I don't believe that is an architectural requirement, but more a factor of the way USM works. I believe a new security model could do things differently, and new applications could be written that had different requirements for authentication.=20 I think the statement does not suggest that only certain applications MUST authenticate, it describes what identity needs to be authenticated by certain applications since those applications need that identity to be authorized before execution of the operations. It would be applicable to any new SNMP application that would require to authorize operations. 2) It is incorrect to say that "any command generators and notification generators which generates/sends a message in the=20 conversation MUST authenticate" - SNMPv3 also supports noAuthNoPriv. That actually raises a question. Do we plan to support noAuthNoPriv with SSHSM (cipher=3Dnone, authentication method=3Dnone). dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of kaushik@cisco.com > Sent: Friday, September 16, 2005 1:00 PM > To: j.schoenwaelder@iu-bremen.de; Eliot Lear > Cc: isms@ietf.org > Subject: RE: [Isms] Questions for Call home >=20 >=20 > My previous statement had some ambiguity. Here is a second try >=20 > I think we need to keep in mind RFC3411 when we talk about identity.=20 > The role of ISMS is to provide flexible authentication and key management > without modifying the notion of identity within RFC3411. From a=20 > security perspective the only identity RFC3411 deals with is the securityName, > i.e. SNMP principal (SNMP engine ID is really not authenticated). What > the means is that irrespective of the SNMP engine that initiates the=20 > conversation (CH or otherwise), any command generators and=20 > notification generators which generates/sends a message in the=20 > conversation MUST authenticate using SNMP securityName (using the SSH=20 > user authentication > protocol) >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 16 22:41:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGSdv-0007st-54; Fri, 16 Sep 2005 22:41:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGSdt-0007so-L2 for isms@megatron.ietf.org; Fri, 16 Sep 2005 22:41:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05174 for ; Fri, 16 Sep 2005 22:41:26 -0400 (EDT) From: kaushik@cisco.com Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGSiz-00035m-IP for isms@ietf.org; Fri, 16 Sep 2005 22:46:48 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 16 Sep 2005 19:41:18 -0700 X-IronPort-AV: i="3.97,118,1125903600"; d="txt'?scan'208,217"; a="212604435:sNHT60870032" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j8H2eovA026283; Fri, 16 Sep 2005 19:41:15 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 19:41:02 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5BB31.3E425634" Date: Fri, 16 Sep 2005 19:41:01 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C39E15CA@xmb-sjc-22d.amer.cisco.com> X-MS-Has-Attach: yes Thread-Topic: Some text on identity and authentication for SSHSM Thread-Index: AcW7MT2cNJR5DrRjTtGcOhHBe36JPQ== To: , , X-OriginalArrivalTime: 17 Sep 2005 02:41:02.0659 (UTC) FILETIME=[3E848130:01C5BB31] X-Spam-Score: 0.3 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: isms@ietf.org Subject: [Isms] Some text on identity and authentication for SSHSM X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5BB31.3E425634 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C5BB31.3E425634" ------_=_NextPart_002_01C5BB31.3E425634 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave, Juergen, Joe, =20 Please find some text in the attached document pertaining to identity and authentication with SSHSM. =20 regards, kaushik! ------_=_NextPart_002_01C5BB31.3E425634 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi = Dave, Juergen,=20 Joe,
 
Please = find some=20 text in the attached document pertaining to identity and authentication = with=20 SSHSM.
 
regards,
  = kaushik!
------_=_NextPart_002_01C5BB31.3E425634-- ------_=_NextPart_001_01C5BB31.3E425634 Content-Type: text/plain; name="sshsm-identity-auth.txt" Content-Transfer-Encoding: base64 Content-Description: sshsm-identity-auth.txt Content-Disposition: attachment; filename="sshsm-identity-auth.txt" Content-Transfer-Encoding: base64 DQogICBJZGVudGl0aWVzIGFuZCBBdXRoZW50aWNhdGlvbiAgDQoNCiAgIFRoZSBTZWN1cmUgU2hl bGwgUHJvdG9jb2wgcGVyZm9ybXMgYXV0aGVudGljYXRpb24gYXQgdHdvIGxldmVscy4NCiAgIFRo ZSBTU0ggVHJhbnNwb3J0IFByb3RvY29sIFtTU0hUUkFOU10gYXV0aGVudGljYXRlcyB0aGUgc2Vy dmVyIGhvc3QNCiAgIGlkZW50aXR5IGFuZCB0aGUgY2xpZW50IGlzIHN1YnNlcXVlbnRseSBhdXRo ZW50aWNhdGVkIHVzaW5nIHRoZSBTU0ggDQogICBVc2VyIEF1dGhlbnRpY2F0aW9uIFByb3RvY29s IFtTU0hBVVRIXS4gVGhlIGNyZWRlbnRpYWxzIHJlcXVpcmVkIGZvciANCiAgIHNlcnZlciBhdXRo ZW50aWNhdGlvbiBhcmUgYSBob3N0IGtleSBwYWlyLCB0aGUgaG9zdCBrZXlzIE1BWSBub3QgYmUg DQogICByZXF1aXJlZCBpbiBjYXNlIEdTU0FQSSBpcyB1c2VkIGZvciBrZXkgZXhjaGFuZ2UuVGhl IGNsaWVudCBhdXRoZW50aWNhdGlvbiANCiAgIGNhbiB1c2UgZWl0aGVyIHB1YmxpYyBrZXkgb3Ig cGFzc3dvcmQgYmFzZWQgYXV0aGVudGljYXRpb24uDQogIA0KICAgW1JGQzM0MTFdIGRvZXMgbm90 IGhhdmUgYSBub3Rpb24gb2Ygc2VwYXJhdGUgaG9zdCBhbmQgdXNlciANCiAgIGlkZW50aXR5LiBU aGUgdXNlciBpZGVudGl0eSwgaS5lLiBzZWN1cml0eU5hbWUgaXMgdGhlIHByaW1hcnkgaWRlbnRp dHkgKDEqKS4NCiAgIFRoZSB1c2Ugb2YgaG9zdCBpZGVudGl0eSB3aXRoaW4gdGhlIFNTSFNNIHdv dWxkIHByb3ZpZGUgYWRkaXRpb25hbCANCiAgIGF1dGhlbnRpY2F0aW9uIGFuZCB0aGVyZSBpc24n dCBhbnkgZXF1aXZhbGVudCBiaW5kaW5nIHRvIHRoZSBTTk1QdjMgVVNNLiANCiAgIFRoZSB1c2Vy IGlkZW50aXR5IGhvd2V2ZXIgbmVlZHMgdG8gYmUgYm91bmQgdG8gdGhlIHNlY3VyaXR5TmFtZS4N Cg0KICAgVGhlIFNOTVB2MyBhcmNoaXRlY3R1cmUgZG9lcyBub3QgaGF2ZSBkZXNpZ25hdGVkIGNs aWVudCBhbmQgc2VydmVyIA0KICAgZnVuY3Rpb25zIHdpdGggYSBub3Rpb24gb2YgYW4gU05NUCBl bmdpbmUgdGhhdCBjYW4gZWl0aGVyIGluaXRpYXRlDQogICBvciByZWNpZXZlIFNOTVAgcmVxdWVz dHMgYmFzZWQgb24gdGhlIFNOTVAgYXBwbGljYXRpb25zIHJ1bm5pbmcgb24gDQogICB0aGUgU05N UCBlbmdpbmUuIFRoZSBTU0ggVHJhbnNwb3J0IE1hcHBpbmcgU2VjdXJpdHkgTW9kZWwgd2lsbCBo YXZlDQogICB0aGUgZm9sbG93aW5nIGNoYXJhY3RlcmlzdGljcw0KDQogICAxLiBFYWNoIFNOTVAg ZW5naW5lIHRoYXQgdXNlcyB0aGUgU1NIU00gTVVTVCBiZSBjYXBhYmxlIG9mIHBlcmZvcm1pbmcg DQogICAgICB0aGUgcm9sZSBvZiBTU0ggc2VydmVyIGFuZCBTU0ggY2xpZW50IGFuZCBNVVNUIGhh dmUgYXBwcm9wcmlhdGUgDQogICAgICBzZXJ2ZXIgY3JlZGVudGlhbHMsIGkuZS4gaG9zdCBrZXkg cGFpcnMgYXJlIHByZXZlbGFudCBpbiBtb3N0IA0KICAgICAgZGVwbG95bWVudHMgYnV0IG1heSBu b3QgcmVxdWlyZWQgaW4gY2FzZSBHU1NBUEkgaXMgdXNlZCBmb3IgU1NIIGtleQ0KICAgICAgZXhj aGFuZ2UuIFguNTA5IGNlcnRpZmljYXRlcyB3aWxsIGJlIHN1cHBvcnRlZCBpbiB0aGUgbmVhciBm dXR1cmUNCg0KICAgMi4gU1NIU00gd2lsbCBzdXBwb3J0IHB1YmxpYyBrZXkgYXV0aGVudGljYXRp b24gKFguNTA5IGNlcnRzIHdpbGwgYmUgDQogICAgICBzdXBwb3J0ZWQgaW4gdGhlIG5lYXIgZnV0 dXJlIGZvciBTU0ggdXNlciBhdXRoZW50aWNhdGlvbikgYW5kIA0KICAgICAgcGFzc3dvcmQgYmFz ZWQgYXV0aGVudGljYXRpb24gdGhhdCBjb3VsZCBiZSB1c2VkIHRvIHN1cHBvcnQgTG9jYWwgDQog ICAgICBBY2NvdW50cywgUkFESVVTIGFuZCBUQUNBQ1MrIG1lY2hhbmlzbXMuDQoNCiAgIDMuIEhv c3QgYmFzZWQgYXV0aGVudGljYXRpb24gKGhvc3RzLmVxdWl2KSBNVVNUIG5vdCBiZSBzdXBwb3J0 ZWQuDQoNCiAgIDQuIEluIGNhc2UgaG9zdCBrZXkgcGFpcnMsIGVhY2ggU05NUCBlbmdpbmUgbXVz dCBiZSBwcmUtY29uZmlndXJlZCB3aXRoIA0KICAgICAgU1NIIGhvc3QgcHVibGljIGtleXMgb2Yg b3RoZXIgU05NUCBlbmdpbmVzIHRoYXQgaXQgd291bGQgcmVxdWlyZSB0byANCiAgICAgIGNvbW11 bmljYXRlICgyKikgd2l0aC4gDQoNCiAgIDUuIFRoZSB1c2VybmFtZSB1c2VkIGluIHRoZSBTU0gg VXNlciBBdXRoZW50aWNhdGlvbiBQcm90b2NvbCBTSE9VTEQgYmUgDQogICAgICB0aGUgU05NUCBz ZWN1cml0eU5hbWUgYW5kIGluIGluc3RhbmNlcyB0aGF0IGlzIG5vdCB0aGUgY2FzZSwgDQogICAg ICBpbXBsZW1lbnRhdGlvbnMgTVVTVCBiZSB0byBhYmxlIHRvIG1hcCB0aGUgYXV0aGVudGljYXRl ZCBuYW1lICgzKikgdG8gDQogICAgICBzZWN1cml0eU5hbWUuIA0KDQogICAxKiBUaGUgdXNlIG9m IHRoZSBTTk1QIGVuZ2luZSBpbiBrZXkgbG9jYWxpemF0aW9uIGRvZXMgbm90IHJlYWxseSANCiAg ICAgIGNvbnN0aXR1dGUgdXNlIG9mIGhvc3QgaWRlbnRpdHkuDQogICAyKiBTU0ggcHVibGljIGtl eXMgbWlnaHQgYWxyZWFkeSBiZSBjYWNoZWQgb24gd29ya3N0YXRpb25zIHRoYXQgdXNlIFNTSA0K ICAgICAgZm9yIHJlbW90ZSBsb2dpbiBwdXJwb3Nlcy4NCiAgIDMqIFNvbWUgaW1wbGVtZW50YXRp b25zIG1heSBtYXAgaG9zdCBpZGVudGl0eSB0byB0aGUgc2VjdXJpdHlOYW1lLg0KICAgICANCiAg IFB1YmxpYyBLZXkgQXV0aGVudGljYXRpb24NCg0KICAgVGhlIFNTSCBhdXRoZW50aWNhdGlvbiBt ZXRob2QgbmFtZSAicHVibGlja2V5IiB3aWxsIGJlIHVzZWQgdG8gc3VwcG9ydA0KICAgdGhpcyBt ZWNoYW5pc20uIFRoZSB1c2VyJ3MgcHVibGljIGtleSBhbmQgYSBzaWduYXR1cmUgZ2VuZXJhdGVk IHVzaW5nIA0KICAgdGhlIHVzZXIncyBwcml2YXRlIGtleSBpcyBzZW50IHRvIHRoZSBzZXJ2ZXIg dG8gYXV0aGVudGljYXRlIHRoZSB1c2VyLg0KICAgQWx0aG91Z2ggdGhpcyBhdXRoZW50aWNhdGlv biBtZWNoYW5pc20gaXMgbWFuZGF0b3J5IGZvciB0aGUgU1NIIFVzZXINCiAgIEF1dGhlbnRpY2F0 aW9uIHByb3RvY29sLCB0aGUgdXNlIG9mIHRoaXMgbWVjaGFuaXNtcyBmb3IgU1NIU00gd2lsbCBi ZQ0KICAgcmVzdHJpY3RlZCB0byBvcGVyYXRvcnMgdGhhdCB1c2UgcHVibGljIGtleSBhdXRoZW50 aWNhdGlvbiB3aGVuIG1hbmFnaW5nDQogICBuZXR3b3JrcyB2aWEgdGhlIENvbW1hbmQgTGluZSBJ bnRlcmZhY2UgKHVzaW5nIFNTSCByZW1vdGUgbG9naW4pLg0KICAgDQogICBQYXNzd29yZCBiYXNl ZCBhdXRoZW50aWNhdGlvbg0KDQoNCiAgIFRoZSBTU0ggVE1TTSB3aWxsIHN1cHBvcnQgYSB2YXJp ZXR5IG9mIGF1dGhlbnRpY2F0aW9uIHN5c3RlbXMgdmlhIHRoZSANCiAgIFNTSCB1c2VyIGF1dGhl bnRpY2F0aW9uICJwYXNzd29yZCIgbWV0aG9kLiBUaGUgbW9zdCBwcmV2ZWxhbnQgd291bGQNCiAg IGJlIGF1dGhlbnRpY2F0aW9uIHZpYSBSQURJVVMgYW5kIExvY2FsIEFjY291bnRzLiBUaGUgU1NI IGF1dGhlbnRpY2F0aW9uDQogICBwcm90b2NvbCB3aWxsIG5vdCBkaWZmZXJlbnRpYXRlIGJldHdl ZW4gdGhlc2UgdmFyaW91cyBtZWNoYW5zaW1zIGFuZCB3aWxsDQogICBiZWhhdmUgaWRlbnRpY2Fs bHkuIE1vc3QgU1NIIGltcGxlbWVudGF0aW9ucyB1c2UgYSBwbHVnZ2FibGUgDQogICBhdXRoZW50 aWNhdGlvbiBtZWNoYW5pc20gKFBBTSkgZm9yIHRoZSBpbnRlZ3JhdGlvbiBvZiB0aGUgcGFzc3dv cmQNCiAgIGJhc2VkIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCB0byBhIHZhcmlldHkgb2YgYXV0aGVu dGljYXRpb24gDQogICBzeXN0ZW1zLiANCg0KICAgUkFESVVTIEF1dGhlbnRpY2F0aW9uDQoNCiAg IFNTSFNNIFNIT1VMRCB1c2UgUkFESVVTIERpZ2VzdCBmb3IgYXV0aGVudGljYXRpb24gZm9yIHNl Y3VyaXR5IHJlYXNvbnMuIA0KICAgSW1wbGVtZW50YXRpb25zIE1BWSBob3dldmVyIGNob29zZSB0 byB1c2Ugb2YgUkFESVVTIFBBUCB0byBzdXBwb3J0IA0KICAgYWRkaXRpb25hbCBiYWNrZW5kIGF1 dGhlbnRpY2F0aW9uIHN5c3RlbXMgc3VjaCBhcyBBY3RpdmUgRGlyZWN0b3J5IGFuZCANCiAgIFRv a2VuIFNlcnZlcnMuDQoNCiAgIFRoZSBSQURJVVMgc2VydmVyIE1BWSByZXR1cm4gYXV0aG9yaXph dGlvbiBpbmZvcm1hdGlvbiBzdWNoIGFzIGEgR3JvdXBOYW1lDQogICBvciBSb2xlIE5hbWUgb24g c3VjZXNzZnVsIGF1dGhlbnRpY2F0aW9uLiANCiAgDQo= ------_=_NextPart_001_01C5BB31.3E425634 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_001_01C5BB31.3E425634-- From isms-bounces@lists.ietf.org Fri Sep 16 22:53:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGSp4-00022E-7z; Fri, 16 Sep 2005 22:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGSp2-000227-15 for isms@megatron.ietf.org; Fri, 16 Sep 2005 22:53:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05529 for ; Fri, 16 Sep 2005 22:52:57 -0400 (EDT) Message-Id: <200509170252.WAA05529@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGSu9-0003Hz-7D for isms@ietf.org; Fri, 16 Sep 2005 22:58:18 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <20050917025248014000qe0he>; Sat, 17 Sep 2005 02:52:49 +0000 From: "David B Harrington" To: , , Date: Fri, 16 Sep 2005 22:52:51 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW7MT2cNJR5DrRjTtGcOhHBe36JPQAARx6A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <618694EF0B657246A4D55A97E38274C39E15CA@xmb-sjc-22d.amer.cisco.com> X-Spam-Score: 0.4 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: isms@ietf.org Subject: [Isms] RE: Some text on identity and authentication for SSHSM X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1184401171==" Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1184401171== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C1F_01C5BB11.5EAEA870" This is a multi-part message in MIME format. ------=_NextPart_000_0C1F_01C5BB11.5EAEA870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Kaushik, Where in the document is your text meant to go? Please provide the revision and the section numbers so I know where you intend it to go. dbh _____ From: kaushik@cisco.com [mailto:kaushik@cisco.com] Sent: Friday, September 16, 2005 10:41 PM To: dbharrington@comcast.net; j.schoenwaelder@iu-bremen.de; jsalowey@cisco.com Cc: isms@ietf.org Subject: Some text on identity and authentication for SSHSM Hi Dave, Juergen, Joe, Please find some text in the attached document pertaining to identity and authentication with SSHSM. regards, kaushik! ------=_NextPart_000_0C1F_01C5BB11.5EAEA870 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Kaushik,
 
Where in the document is your text meant to=20 go?
Please provide the revision and the = section=20 numbers so I know where you intend it to = go.
 
dbh

From: kaushik@cisco.com=20 [mailto:kaushik@cisco.com]
Sent: Friday, September 16, 2005 = 10:41=20 PM
To: dbharrington@comcast.net; = j.schoenwaelder@iu-bremen.de;=20 jsalowey@cisco.com
Cc: isms@ietf.org
Subject: Some = text on=20 identity and authentication for SSHSM

Hi = Dave, Juergen,=20 Joe,
 
Please find some=20 text in the attached document pertaining to identity and = authentication with=20 SSHSM.
 
regards,
 =20 kaushik!
------=_NextPart_000_0C1F_01C5BB11.5EAEA870-- --===============1184401171== 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 --===============1184401171==-- From isms-bounces@lists.ietf.org Fri Sep 16 23:15:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGTAe-0006So-EG; Fri, 16 Sep 2005 23:15:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGTAc-0006SJ-GJ for isms@megatron.ietf.org; Fri, 16 Sep 2005 23:15:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06417 for ; Fri, 16 Sep 2005 23:15:15 -0400 (EDT) From: kaushik@cisco.com Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGTFj-0003k8-4k for isms@ietf.org; Fri, 16 Sep 2005 23:20:37 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 16 Sep 2005 20:15:07 -0700 X-IronPort-AV: i="3.97,118,1125903600"; d="scan'208,217"; a="342542840:sNHT44012436" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8H3ErKC006340; Fri, 16 Sep 2005 20:14:53 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 20:15:04 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 Sep 2005 20:15:02 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C39E15CE@xmb-sjc-22d.amer.cisco.com> Thread-Topic: Some text on identity and authentication for SSHSM Thread-Index: AcW7MT2cNJR5DrRjTtGcOhHBe36JPQAARx6AAADbicA= To: , , X-OriginalArrivalTime: 17 Sep 2005 03:15:04.0141 (UTC) FILETIME=[FF55EFD0:01C5BB35] X-Spam-Score: 0.6 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: isms@ietf.org Subject: [Isms] RE: Some text on identity and authentication for SSHSM X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1637790311==" Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1637790311== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5BB35.FEFC4A16" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5BB35.FEFC4A16 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi David, =20 I have not gone through the entire text but Section 2.1 seems the most appropriate place for most of the Identity and Authentication.=20 =20 regards, kaushik! ________________________________ From: David B Harrington [mailto:dbharrington@comcast.net]=20 Sent: Friday, September 16, 2005 7:53 PM To: Kaushik Narayan [kaushik@cisco.com]; j.schoenwaelder@iu-bremen.de; Joseph Salowey [jsalowey@cisco.com] Cc: isms@ietf.org Subject: RE: Some text on identity and authentication for SSHSM Hi Kaushik, =20 Where in the document is your text meant to go? Please provide the revision and the section numbers so I know where you intend it to go. =20 dbh ________________________________ From: kaushik@cisco.com [mailto:kaushik@cisco.com]=20 Sent: Friday, September 16, 2005 10:41 PM To: dbharrington@comcast.net; j.schoenwaelder@iu-bremen.de; jsalowey@cisco.com Cc: isms@ietf.org Subject: Some text on identity and authentication for SSHSM =09 =09 Hi Dave, Juergen, Joe, =20 Please find some text in the attached document pertaining to identity and authentication with SSHSM. =20 regards, kaushik! ------_=_NextPart_001_01C5BB35.FEFC4A16 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi David,
 
I have not gone through the entire text but = Section 2.1=20 seems the most appropriate place for most of
the Identity and Authentication. =
 
regards,
  kaushik!

From: David B Harrington=20 [mailto:dbharrington@comcast.net]
Sent: Friday, September 16, = 2005=20 7:53 PM
To: Kaushik Narayan [kaushik@cisco.com];=20 j.schoenwaelder@iu-bremen.de; Joseph Salowey = [jsalowey@cisco.com]
Cc:=20 isms@ietf.org
Subject: RE: Some text on identity and = authentication=20 for SSHSM

Hi Kaushik,
 
Where in the document is your text meant to=20 go?
Please provide the revision and the = section=20 numbers so I know where you intend it to = go.
 
dbh

From: kaushik@cisco.com=20 [mailto:kaushik@cisco.com]
Sent: Friday, September 16, 2005 = 10:41=20 PM
To: dbharrington@comcast.net; = j.schoenwaelder@iu-bremen.de;=20 jsalowey@cisco.com
Cc: isms@ietf.org
Subject: Some = text on=20 identity and authentication for SSHSM

Hi = Dave, Juergen,=20 Joe,
 
Please find some=20 text in the attached document pertaining to identity and = authentication with=20 SSHSM.
 
regards,
 =20 kaushik!
------_=_NextPart_001_01C5BB35.FEFC4A16-- --===============1637790311== 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 --===============1637790311==-- From isms-bounces@lists.ietf.org Sat Sep 17 03:51:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGXTV-0007tE-Ux; Sat, 17 Sep 2005 03:51:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGXTU-0007t9-PI for isms@megatron.ietf.org; Sat, 17 Sep 2005 03:51:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00384 for ; Sat, 17 Sep 2005 03:51:02 -0400 (EDT) Received: from ia837.i.pppool.de ([85.73.168.55] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGXYe-0000xG-J9 for isms@ietf.org; Sat, 17 Sep 2005 03:56:25 -0400 Received: by boskop.local (Postfix, from userid 501) id 2863340041F; Sat, 17 Sep 2005 09:50:41 +0200 (CEST) Date: Sat, 17 Sep 2005 09:50:41 +0200 From: Juergen Schoenwaelder To: kaushik@cisco.com Message-ID: <20050917075041.GA23469@boskop.local> Mail-Followup-To: kaushik@cisco.com, dbharrington@comcast.net, jsalowey@cisco.com, isms@ietf.org References: <618694EF0B657246A4D55A97E38274C39E15CA@xmb-sjc-22d.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <618694EF0B657246A4D55A97E38274C39E15CA@xmb-sjc-22d.amer.cisco.com> User-Agent: Mutt/1.5.10i X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: dbharrington@comcast.net, isms@ietf.org Subject: [Isms] Re: Some text on identity and authentication for SSHSM X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Fri, Sep 16, 2005 at 07:41:01PM -0700, kaushik@cisco.com wrote: > > 1. Each SNMP engine that uses the SSHSM MUST be capable of performing > the role of SSH server and SSH client and MUST have appropriate > server credentials, i.e. host key pairs are prevelant in most > deployments but may not required in case GSSAPI is used for SSH key > exchange. X.509 certificates will be supported in the near future > > 2. SSHSM will support public key authentication (X.509 certs will be > supported in the near future for SSH user authentication) and > password based authentication that could be used to support Local > Accounts, RADIUS and TACACS+ mechanisms. > > 3. Host based authentication (hosts.equiv) MUST not be supported. > > 4. In case host key pairs, each SNMP engine must be pre-configured with > SSH host public keys of other SNMP engines that it would require to > communicate (2*) with. > > 5. The username used in the SSH User Authentication Protocol SHOULD be > the SNMP securityName and in instances that is not the case, > implementations MUST be to able to map the authenticated name (3*) to > securityName. I am not sure what the purpose of this is. RFC 3411 already requires that whatever a security model authenticates must map to a securityName. I am also not sure about the SHOULD. In fact, I have no clue whether you write requirements, applicability text, security considerations or protocol specification. > 1* The use of the SNMP engine in key localization does not really > constitute use of host identity. > 2* SSH public keys might already be cached on workstations that use SSH > for remote login purposes. > 3* Some implementations may map host identity to the securityName. > > Public Key Authentication > > The SSH authentication method name "publickey" will be used to support > this mechanism. The user's public key and a signature generated using > the user's private key is sent to the server to authenticate the user. > Although this authentication mechanism is mandatory for the SSH User > Authentication protocol, the use of this mechanisms for SSHSM will be > restricted to operators that use public key authentication when managing > networks via the Command Line Interface (using SSH remote login). I am only allows to use SSHSM with public keys if I also use them for the CLI? I fail to see the purpose of this CLR. > Password based authentication > > The SSH TMSM will support a variety of authentication systems via the > SSH user authentication "password" method. The most prevelant would > be authentication via RADIUS and Local Accounts. The SSH authentication > protocol will not differentiate between these various mechansims and will > behave identically. Most SSH implementations use a pluggable > authentication mechanism (PAM) for the integration of the password > based authentication method to a variety of authentication > systems. > > RADIUS Authentication > > SSHSM SHOULD use RADIUS Digest for authentication for security reasons. > Implementations MAY however choose to use of RADIUS PAP to support > additional backend authentication systems such as Active Directory and > Token Servers. > > The RADIUS server MAY return authorization information such as a GroupName > or Role Name on sucessful authentication. The last paragraph, if included, should be phrased in terms of generic AAA services. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Sep 17 15:17:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGiBb-0001WG-S9; Sat, 17 Sep 2005 15:17:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGiBa-0001Tx-R4 for isms@megatron.ietf.org; Sat, 17 Sep 2005 15:17:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00260 for ; Sat, 17 Sep 2005 15:17:17 -0400 (EDT) From: kaushik@cisco.com Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGiGr-0006pM-Br for isms@ietf.org; Sat, 17 Sep 2005 15:22:45 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 17 Sep 2005 12:17:07 -0700 X-IronPort-AV: i="3.97,119,1125903600"; d="scan'208"; a="342657051:sNHT46319186" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j8HJH3uk004911; Sat, 17 Sep 2005 12:17:04 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 17 Sep 2005 12:17:03 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 17 Sep 2005 12:17:02 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C39E15FC@xmb-sjc-22d.amer.cisco.com> Thread-Topic: Some text on identity and authentication for SSHSM Thread-Index: AcW7XJBTmbzR77cnT86PBJi8/Qm77AAVHn2Q To: X-OriginalArrivalTime: 17 Sep 2005 19:17:03.0608 (UTC) FILETIME=[62D1A780:01C5BBBC] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: quoted-printable Cc: dbharrington@comcast.net, isms@ietf.org Subject: [Isms] RE: Some text on identity and authentication for SSHSM X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Juergen, Please find my reply inline.=20 -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 Sent: Saturday, September 17, 2005 12:51 AM To: Kaushik Narayan [kaushik@cisco.com] Cc: dbharrington@comcast.net; Joseph Salowey [jsalowey@cisco.com]; isms@ietf.org Subject: Re: Some text on identity and authentication for SSHSM On Fri, Sep 16, 2005 at 07:41:01PM -0700, kaushik@cisco.com wrote: >=20 > 1. Each SNMP engine that uses the SSHSM MUST be capable of performing=20 > the role of SSH server and SSH client and MUST have appropriate=20 > server credentials, i.e. host key pairs are prevelant in most=20 > deployments but may not required in case GSSAPI is used for SSH key > exchange. X.509 certificates will be supported in the near=20 > future >=20 > 2. SSHSM will support public key authentication (X.509 certs will be=20 > supported in the near future for SSH user authentication) and=20 > password based authentication that could be used to support Local=20 > Accounts, RADIUS and TACACS+ mechanisms. >=20 > 3. Host based authentication (hosts.equiv) MUST not be supported. >=20 > 4. In case host key pairs, each SNMP engine must be pre-configured with=20 > SSH host public keys of other SNMP engines that it would require to=20 > communicate (2*) with.=20 >=20 > 5. The username used in the SSH User Authentication Protocol SHOULD be=20 > the SNMP securityName and in instances that is not the case,=20 > implementations MUST be to able to map the authenticated name (3*) to=20 > securityName.=20 I am not sure what the purpose of this is. RFC 3411 already requires that whatever a security model authenticates must map to a securityName. I am also not sure about the SHOULD. In fact, I have no clue whether you write requirements, applicability text, security considerations or protocol specification. The purpose of this text is not to state that RFC3411 allows mapping of an authenticated name to a securityName but to identify the information from the SSH transport that will be mapped to the securityName. There could be a direct mapping of the username in the SSH User Authentication protocol or mapping between the SSH user identity or host identity to the securityName. Do you believe that this is implicit and this text is not required. I intended to specify requirements in this section. > 1* The use of the SNMP engine in key localization does not really=20 > constitute use of host identity. > 2* SSH public keys might already be cached on workstations that use SSH > for remote login purposes. > 3* Some implementations may map host identity to the securityName. > =20 > Public Key Authentication >=20 > The SSH authentication method name "publickey" will be used to support > this mechanism. The user's public key and a signature generated using=20 > the user's private key is sent to the server to authenticate the user. > Although this authentication mechanism is mandatory for the SSH User > Authentication protocol, the use of this mechanisms for SSHSM will be > restricted to operators that use public key authentication when managing > networks via the Command Line Interface (using SSH remote login). I am only allows to use SSHSM with public keys if I also use them for the CLI? I fail to see the purpose of this CLR. I think this text is not very clear. Fundamentally without X.509 certificate support for user authentication you would need identity/public keys to be manually provisioned on SNMP engines (that act SSH servers)to authenticate requests that use the "publickey" method, i.e. agents will need to be provisioned identity/public key in order to authenticate managers that might use publickey method of SSH user authentication. If these keys are not already provisioned to be used by NetConf/CLI (over SSH), then having to provision these keys for use within SNMP actually has the same issues as SNMPv3/USM. The text intends to state that without X.509 support, the "publickey" method of SSH user authentication is not preferred unless it is already in use by other management protocols such as NetConf that use SSH transport. > Password based authentication >=20 > The SSH TMSM will support a variety of authentication systems via the=20 > SSH user authentication "password" method. The most prevelant would > be authentication via RADIUS and Local Accounts. The SSH authentication > protocol will not differentiate between these various mechansims and will > behave identically. Most SSH implementations use a pluggable=20 > authentication mechanism (PAM) for the integration of the password > based authentication method to a variety of authentication=20 > systems.=20 >=20 > RADIUS Authentication >=20 > SSHSM SHOULD use RADIUS Digest for authentication for security reasons.=20 > Implementations MAY however choose to use of RADIUS PAP to support=20 > additional backend authentication systems such as Active Directory and=20 > Token Servers. >=20 > The RADIUS server MAY return authorization information such as a GroupName > or Role Name on sucessful authentication.=20 The last paragraph, if included, should be phrased in terms of generic AAA services. I think that is fair. I will work on updating the text. Regards, kaushik! /js --=20 Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Sep 19 11:37:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNiC-00073z-OT; Mon, 19 Sep 2005 11:37:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNiB-00073t-Dr for isms@megatron.ietf.org; Mon, 19 Sep 2005 11:37:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03523 for ; Mon, 19 Sep 2005 11:37:40 -0400 (EDT) Message-Id: <200509191537.LAA03523@ietf.org> Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHNno-0003uo-Mn for isms@ietf.org; Mon, 19 Sep 2005 11:43:33 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <2005091915373201400omr0ke>; Mon, 19 Sep 2005 15:37:32 +0000 From: "David B Harrington" To: Date: Mon, 19 Sep 2005 11:37:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcW9MBCP46/Jlw4MTQKWisYguY9jXA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] draft-harrington-isms-SecShell-01.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, There is a new revision of the SSH draft available. draft-harrington-isms-SecShell-01.txt David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Sep 19 13:28:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHPQv-0003Dr-L8; Mon, 19 Sep 2005 13:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGRW2-0000AI-5O for isms@megatron.ietf.org; Fri, 16 Sep 2005 21:29:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02074 for ; Fri, 16 Sep 2005 21:29:14 -0400 (EDT) Message-Id: <200509170129.VAA02074@ietf.org> Received: from rwcrmhc13.comcast.net ([216.148.227.118] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGRb5-0001U0-U3 for isms@ietf.org; Fri, 16 Sep 2005 21:34:34 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <2005091701290101500o10dre>; Sat, 17 Sep 2005 01:29:02 +0000 From: "David B Harrington" To: Date: Fri, 16 Sep 2005 21:29:02 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0C10_01C5BB05.A9225FC0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW7Jy+iVur3QSfbSXe9WHZnl6TfxA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 20e59d3ba258dd81a9d821080f33abbc X-Mailman-Approved-At: Mon, 19 Sep 2005 13:28:00 -0400 Cc: Subject: [Isms] draft-harrington-isms-SecShell-01.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0C10_01C5BB05.A9225FC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Here's a new revision of the SSHSM proposal. This includes elements of procedure for outgoing messages, wordsmithing, and more resolved [todos]. David Harrington dbharrington@comcast.net ------=_NextPart_000_0C10_01C5BB05.A9225FC0 Content-Type: text/plain; name="draft-harrington-isms-SecShell-01.txt" Content-Disposition: attachment; filename="draft-harrington-isms-SecShell-01.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Harrington Internet-Draft Effective Software Expires: March 20, 2006 J. Schoenwaelder International University Bremen J. Salowey Cisco Systems September 16, 2005 Secure Shell Security Model for SNMP draft-harrington-isms-SecShell-01.txt 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 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo describes a Security Model for the Simple Network Management Protocol, using the Secure Shell protocol within a Transport Mapping. Harrington, et al. Expires March 20, 2006 [Page 1] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 The Internet-Standard Management Framework . . . . . . . . 6 1.3 The Secure Shell Protocol . . . . . . . . . . . . . . . . 6 1.4 Constraints . . . . . . . . . . . . . . . . . . . . . . . 7 1.5 Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 2. How SSHSM Fits into the TMSM Architecture . . . . . . . . . . 7 2.1 Security Capabilities of this Model . . . . . . . . . . . 8 2.1.1 Threats . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2 Sessions . . . . . . . . . . . . . . . . . . . . . . . 11 2.1.3 Authentication Protocol . . . . . . . . . . . . . . . 11 2.1.4 Privacy Protocol . . . . . . . . . . . . . . . . . . . 12 2.1.5 Protection against Message Replay, Delay and Redirection . . . . . . . . . . . . . . . . . . . . . 12 2.1.6 Security Protocol Requirements . . . . . . . . . . . . 12 2.2 Security Parameter Passing Requirement . . . . . . . . . . 14 2.3 Requirements for Notifications . . . . . . . . . . . . . . 15 2.4 Scenario Diagrams . . . . . . . . . . . . . . . . . . . . 15 2.4.1 Command Generator or Notification Originator . . . . . 15 2.4.2 Command Responder . . . . . . . . . . . . . . . . . . 16 2.5 Abstract Service Interfaces . . . . . . . . . . . . . . . 17 3. RFC 3411 Abstract Service Interfaces . . . . . . . . . . . . . 18 3.1 Public Abstract Service Interfaces . . . . . . . . . . . . 18 3.1.1 Public ASIs for Outgoing Messages . . . . . . . . . . 18 3.1.2 Public ASIs for Incoming Messages . . . . . . . . . . 20 3.2 Private Abstract Service Interfaces . . . . . . . . . . . 21 4. SNMP Messages Using this Security Model . . . . . . . . . . . 22 4.1 SNMPv1 and SNMPv2c Messages Using this Security Model . . 22 4.2 SNMPv3 Messages Using this Security Model . . . . . . . . 23 4.2.1 msgGlobalData . . . . . . . . . . . . . . . . . . . . 25 4.3 Passing Security Parameters . . . . . . . . . . . . . . . 26 4.3.1 Transport Session Parameters . . . . . . . . . . . . . 27 4.3.2 [todo] Using Local Accounts to Authenticate Users . . 28 4.3.3 [todo] Using RADIUS Accounts to Authenticate Users . . 28 4.3.4 securityStateReference for SSHSM . . . . . . . . . . . 28 4.4 MIB Module for SSH Security Model . . . . . . . . . . . . 28 4.5 [todo] Notifications . . . . . . . . . . . . . . . . . . . 28 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 29 5.1 Establishing a Session . . . . . . . . . . . . . . . . . . 29 5.2 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 31 5.3 Generating an Outgoing SNMP Message . . . . . . . . . . . 32 5.4 Sending an Outgoing SNMP Message to the Network . . . . . 34 5.5 [todo] Prepare Data Elements from an Incoming SNMP Message . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.6 Processing an Incoming SNMP Message . . . . . . . . . . . 35 6. MIB module definition . . . . . . . . . . . . . . . . . . . . 37 Harrington, et al. Expires March 20, 2006 [Page 2] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 7. Security Considerations . . . . . . . . . . . . . . . . . . . 40 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 10.1 Normative References . . . . . . . . . . . . . . . . . . . 40 10.2 Informative References . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 42 A. Change Log from the first revision of -00- . . . . . . . . . . 43 Intellectual Property and Copyright Statements . . . . . . . . 44 Harrington, et al. Expires March 20, 2006 [Page 3] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 1. Introduction This memo describes a Security Model for the Simple Network Management Protocol, using the Secure Shell protocol within a Transport Mapping. It is important to understand the SNMP architecture and the terminology of the architecture to understand where the Security Model described in this memo fits into the architecture and interacts with other subsystems within the architecture. The reader is expected to have read and understood the description of the SNMP architecture, as defined in [RFC3411],and the "Transport Mapping Security Model (TMSM) for the Simple Network Management Protocol" architecture extension defined in [TMSM], which enables the use of external "lower layer" protocols to provide message security, tied into the SNMP architecture through the transport mapping subsystem. One such external protocol is the Secure Shell protocol [SSHArch]. This memo describes the Secure Shell Security Model for SNMP, a specific SNMP security model to be used within the SNMP Architecture, to provide authentication, encryption, and integrity checking of SNMP messages. This memo 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 Secure Shell Security Model for SNMP. 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 Security Model for SNMP. These MIB objects should not be referenced in other documents. This allows the Secure Shell Security Model for SNMP 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. 1.1 Motivation Version 3 of the Simple Network Management Protocol (SNMPv3) added security to the previous versions of the protocol. The User Security Model (USM) [RFC3414] was designed to be independent of other existing security infrastructures, to ensure it could function when Harrington, et al. Expires March 20, 2006 [Page 4] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 third party authentication services were not available, such as in a broken network. As a result, USM typically utilizes a separate user and key management infrastructure. Operators have reported that deploying another user and key management infrastructure in order to use SNMPv3 is a reason for not deploying SNMPv3 at this point in time. This memo describes a security model that will make use of the existing and commonly deployed Secure Shell security infrastructure. It is designed to meet the security and operational needs of network administrators, maximize useability 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. The work will address the requirement for the SSH client to authenticate the SSH server, for the SSH server to authenticate the SSH client (the user), and how SNMP can make use of the authenticated identities in authentication and auditing. . The work will include the ability to use any of the user authentication methods described in "SSH Authentication Protocol" [SSHAuth] - public key, password, and host-based. Local accounts may be supported through the use of the public key, host-based or password based mechanisms. The password based mechanism allows for integration with deployed password infrastructure such as AAA servers using the RADIUS protocol [RFC2865]. In the future it should also be able to take advantage of other defined authentication mechanism such as those defined in [gsskeyex] which will allow for user authentication mechanisms which support different security infrastructures and provide security properties. It is desirable to use mechanisms that could unify the approach for administrative security for SNMPv3 and CLI and other management interfaces. The use of security services provided by Secure Shell is the approach commonly used for the CLI, and is the approach being adopted for use with NETCONF [Netconf]. Similar to NETCONF over SSH [NetconfSSH], this memo describes a method for invoking and running the SNMP protocol within a Secure Shell (SSH) session as an SSH subsystem. This memo defines how SNMP can be used within a Secure Shell (SSH) session, using the SSH connection protocol [SSHConnect] over the SSH transport protocol [SSHTrans], using SSH user-auth [SSHAuth]for authentication. There are a number of challenges to be addressed to map Secure Shell authentication method parameters into the SNMP architecture so that Harrington, et al. Expires March 20, 2006 [Page 5] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 SNMP continues to work without any surprises. These are discussed in detail below. Some points requiring further WG research and discussion are identified by [todo] markers in the text. 1.2 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.3 The Secure Shell Protocol SSH is a protocol for secure remote login and other secure network services over an insecure network. It consists of three major components: o The Transport Layer Protocol [[SSHTrans] provides server authentication, confidentiality, and integrity. It may optionally also provide compression. The transport layer will typically be run over a TCP/IP connection, but might also be used on top of any other reliable data stream. o The User Authentication Protocol [SSHAuth] authenticates the client-side user to the server. It runs over the transport layer protocol. o The Connection Protocol [SSHConnect] multiplexes the encrypted tunnel into several logical channels. It runs over the user authentication protocol. The client sends a service request once a secure transport layer connection has been established. A second service request is sent after user authentication is complete. This allows new protocols to be defined and coexist with the protocols listed above. The connection protocol provides channels that can be used for a wide range of purposes. Standard methods are provided for setting up secure interactive shell sessions and for forwarding ("tunneling") arbitrary TCP/IP ports and X11 connections. Harrington, et al. Expires March 20, 2006 [Page 6] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 1.4 Constraints The design of this SNMP Security Model is also influenced by the following constraints: 1. When the requirements of effective management in times of network stress are inconsistent with those of security, the design of this model gives preference to the former. 2. In times of network stress, neither the security protocol nor its underlying security mechanisms should depend upon the ready availability of other network services (e.g., Network Time Protocol (NTP) or AAA protocols). 3. 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. 4. It may not be possible for the security model to determine when the network is under stress. 5. A security mechanism should entail no changes to the basic SNMP network management philosophy. 1.5 Conventions The terms "manager" and "agent" are not used in this document, because in the RFC 3411 architecture, all 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 Generator, Notification Rewsponder, and Proxy Forwarder are used. See "SNMP Applications" [RFC3413] for further information. Throughout this document, the terms "client" and "server" are used to refer to the two ends of the SSH transport connection. The client actively opens the SSH connection, and the server passively listens for the incoming SSH connection. Either entity may act as client or as server, as discussed further below. 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]. 2. How SSHSM Fits into the TMSM Architecture SSH is a security layer which is plugged into the TMSM architecture between the underlying transport layer and the message dispatcher. The SSHSM model will establish an encrypted tunnel between the transport mappings of two SNMP engines. The sending transport mapping security model instance encrypts outgoing messages, and the Harrington, et al. Expires March 20, 2006 [Page 7] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 receiving transport mapping security model instance decrypts the messages. After the transport layer tunnel is established, then SNMP messages can conceptually be sent through the tunnel from one SNMP message dispatcher to another SNMP message dispatcher. Once the tunnel is established, multiple SNMP messages may be able to be passed through the same tunnel. Within an engine, outgoing SNMP messages are passed unencrypted from the message dispatcher to the transport mapping, and incoming messages are passed unencrypted from the transport mapping to the message dispatcher. SSHSM security processing will be called from within the Transport Mapping functionality of an SNMP engine dispatcher to perform the translation of transport security parameters to/from security-model-independent parameters. Some SSHSM security processing will also be performed within a message processing portion of the model, for compatibility with the ASIs between the RFC 3411 Security Subsystem and the Message Processing Subsystem. 2.1 Security Capabilities of this Model 2.1.1 Threats The security protocols used in this memo are considered acceptably secure at the time of writing. However, the procedures allow for new authentication and privacy methods to be specified at a future time if the need arises. The Secure Shell Security Model provides protection against the threats identified by the RFC 3411 architecture [RFC3411]: 1. Message stream modification - Provide for verification that each received SNMP message has not been modified during its transmission through the network. . 2. Information modification - Provide for verification that the contents of each received SNMP message has not been modified during its transmission through the network. Data has not been altered or destroyed in an unauthorized manner, nor have data sequences been altered to an extent greater than can occur non- maliciously 3. Masquerade - Provide for both verification of the identity of the user on whose behalf a received SNMP message claims to have been generated, and the verification of the identity of the MIB owner. For the protocols specified in this memo, it is not possible to assure the specific user that originated a received SNMP message; rather, it is the user on whose behalf the message was originated Harrington, et al. Expires March 20, 2006 [Page 8] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 that is authenticated. SSH provides verification of the identity of the MIB owner through the SSH Transport Protocol server authentication [SSHTrans]. 4. Verification of user identity is important for use with the SNMP access control subsystem, to ensure that only authorized users have access to potentially sensitive data. The SSH user identity will be used to map to an SNMP model-independent securityname for use with SNMP access control. 5. Authenticating the server ensures the authenticity of the SSH server that is associated with the SNMP engine that provides MIB data. Operators or management applications could act upon the data they receive (e.g. raise an alarm for an operator, modify the configuration of the device that sent the notification, modify the configuration of other devices in the network as the result of the notification, and so on) , so it is important to know that the data is authentic. SSH allows for authenticaiton of the SSH server using the SSH public key credentials described in [SSHTrans] and mechanisms such as those described in [gsskeyex]. 6. Disclosure - Provide, when necessary, that the contents of each received SNMP message are protected from disclosure to unauthorized persons.. 7. Replay - Provide for detection of received SNMP messages, which request or contain management information, whose time of generation was not recent. A message whose generation time is outside of a time window is not accepted. Note that message reordering is not dealt with and can occur in normal conditions 2.1.1.1 Data Origin Authentication Issues 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) SSH provides support for encryption and data integrity. While it is technically possible to support noAuthNoPriv and authNoPriv in SSH it is NOT RECOMMENDED by [SSHTrans]. This means that an SSH connection should support authPriv, which is the highest level of security defined in RFC 3411. It is possible for SSH to skip entity authenticaiton of the client through the "none" authentication method to support anonymous clients, however in the this case an implementation MUST still support data integrity within the SSH transport protocol. The security protocols used in [SSHTrans] are considered acceptably secure at the time of writing. However, the procedures allow for new authentication and privacy methods to be specified at a future time if the need arises. Harrington, et al. Expires March 20, 2006 [Page 9] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 authNoPriv may be important to accommodate governmental regulation (e.g. export laws) regarding encryption technologies. [todo] is it important to support anonymous user access to SNMP? Should the transport layer provide what data integrity and encryption algorithms were negotiated to the SSHSM layer? In SNMP, we deliberately avoided this, and settled for an assertion that auth and priv were applied accoridng to the rules of the security model. SSH should also provide the identity of the authenticated parties. From this information it should be possible for the SNMP subsystem to determine if the session is allowed access to the subsystem. 2.1.1.1.1 noAuthPriv SSH provides the "none" userauth method, which is normally rejected by servers and used only to find out what userauth methods are supported. However, it is legal for a server to accept this method, which has the effect of not authenticating the ssh client to the ssh server. Doing this does not compromise authentication of the ssh server to the ssh client, nor does it compromise data confidentiality or data integrity. The RFC 3411 architecture does not permit noAuthPriv. SSHSM should refuse a noAuthPriv session [todo] If we do not allow some of these options, how do we determine the option was used, so we can reject it? How does an SNMP engine reject a session? 2.1.1.1.2 skipping public key verification [todo] Most key exchange algorithms are able to authenticate the SSH server's identity to the client. However, for the common case of DH signed by public keys, this requires the client to know the host's public key a priori and to verify that the correct key is being used. If this step is skipped, you no longer have authentication of the ssh server to the ssh client. You do still get data confidentiality and data integrity protection to whatever server you're talking to, but these are of dubious value when an attacker can insert himself between the client and the real ssh server. Note that some userauth methods may defend against this situation, but many of the common ones (including password and keyboard-interactive) do not, and in fact depend on the fact that the server's identity has been verified (otherwise you may be giving your password to an attacker). 2.1.1.1.3 the 'none' MAC algorithm SSH provides the "none" MAC algorithm, which would allow you to turn Harrington, et al. Expires March 20, 2006 [Page 10] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 off data integrity while maintaining confidentiality. However, if you do this, then an attacker may be able to modify the data in flight, which means you effectively have no authentication. SSH must not be configured using the "none" MAC algorithm for use with the SSHSM security model. 2.1.2 Sessions Sessions are not part of RFC 3411 architecture, but are considered desirable because the cost of authentication can be amortized over potentially many transactions. The Secure Shell security model will utilize sessions, with a single user and security level associated with each session. If an exchange with another engine would require a different security level or would be on behalf of a different user, 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. This document will discuss the impact of sessions on SNMP usage. [todo] 2.1.2.1 Message security versus session security As part of session creation the client and server entities are typically authenticated and authorized access to the session. In addition as part of session establishment cryptographic key material is exchanged and is then used to control access to the session on a message by message basis. Messages that fail the basic data origin authenticaiton/ data integrity checks will be rejected. Entities receiving the messages that do not have the correct encryption keys established during session creation will not be able to read the messgaes. In order for an entity to process messages it must maintain certain state associated with the session. This includes, but is not limited to cryptographic encryption and data integrity keys, entity identities and authorization information associated with the authenticated identites. After a message is received and passes integrity and authentication checks then the state stored in the session is used to provide further authorization for the message. 2.1.3 Authentication Protocol SSHSM should support any user authentication mechanism supported by SSH. The SSH Authentication Protocol document describes three authentication methods - publickey, password, and host-based. All three authentication methods are supported by the Secure Shell Security Model for SNMP. Harrington, et al. Expires March 20, 2006 [Page 11] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 The password authentication mechanism allows for integration with deployed password based infrastructure. It is possible to hand a password to a service such as RADIUS [RFC2865] or Diameter [RFC 3588] for validation. The validation could be done using the user-name and user-password attributes. It is also possible to use a different password validation protcol such as CHAP [RFC1994] or digest authentication [RFC 2617, draft-ietf-radext-digest-auth-04] to integrate with RADIUS. Any of these mechanism leave the password in the clear on the device that is authenticating the password which introduces threats on the authentication infrastructure which is less than ideal. It is possible that new mechanism will be developed using authentication mechanisms defined in [gsskeyex] which will allow for user authentication mechanisms which support different security infrastructures and provide security properties." 2.1.4 Privacy Protocol The Secure Shell Security Model uses the SSH transport layer protocol, which provides strong encryption, server authentication, and integrity protection. 2.1.5 Protection against Message Replay, Delay and Redirection The Secure Shell Security Model uses the SSH transport layer protocol. SSH uses sequence numbers and integrity checks to protect against replay and reordering of messages within a connection. SSH also provides protection against replay of entire sessions. In a properly-implemented DH exchange, both sides will generate new random numbers for each exchange, which means the exchange hash and thus the encryption and integrity keys will be distinct for every session. This would prevent capturing an SNMP message and redirecting it to another SNMP engine. Message delay is not as important an issue with SSH as it is with USM. USM checks the timeliness of messages because it does not provide session protection or message sequence ordering. The only delay that would seem to be possible would be to capture the next sequence numbered packet and hold it to play within the same session later. 2.1.6 Security Protocol Requirements Modifying the Secure Shell protocol, or configuring it in a particular manner, may change its security 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 Harrington, et al. Expires March 20, 2006 [Page 12] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 usages. This document will describe the use of an SSH subsytem for SNMP. It has been a long-standing requirement that SNMP be able to work when the network is unstable, to enable network troubleshooting and repair. The UDP approach has been considered to meet that need well, with an assumption that getting small messages through, even if out of order, is better than gettting no messages through. There has been a long debate about whether UDP actually offers better support than TCP when the underlying IP or lower layers are unstable. There has been recent discussion of whether operators actually use SNMP to troubleshoot and repair unstable networks. This document will include a discussion of the operational expectations of this model for use in troubleshooting a broken network.[todo] This may belong in the TMSM document. There has been discussion of ways SNMP could be extended to better support management/monitoring needs when a network is running just fine. Use of a TCP transport, for example, could enable larger message sizes and more efficient table retrievals. Secure Shell runs over TCP. This document will discuss the expected ramifications of using a TCP transport for SNMP, and the coexistence of UDP and TCP transport for SNMP. [todo] Should this be discussed in the TMSM document? The Secure Shell security model can coexist with the USM security model, the only other currently defined security model. [todo] compare to RFC3584 to see if there are any wrinkles to coexistence with SNMPv1/v2c. 2.1.6.1 Mapping SSH to EngineID In the RFC3411 architecture, there are three use cases for an engineID: snmpEngineID - RFC3411 includes the SNMP-FRAMEWORK-MIB, which defines a snmpEngineID object. An snmpEngineID is the unique and unambiguous identifier of an SNMP engine. Since there is a one- to-one association between SNMP engines and SNMP entities, it also uniquely and unambiguously identifies the SNMP entity within an administrative domain. contextEngineID - Management information resides at an SNMP entity where a Command Responder Application has local access to potentially multiple contexts. This application uses a contextEngineID equal to the snmpEngineID of its associated SNMP engine. securityEngineID - The RFC3411 architecture defines ASIs that include a securityEngineID - the authoritative SNMP entity - which is either the local snmpEngineID or the target snmpEngineID, Harrington, et al. Expires March 20, 2006 [Page 13] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 depending on the type of operation. Since a security model might utilize shared credentials and integrity-checking parameters, and the datastores of the two endpoints could get out of sync, the "authoritative" engineID indicates which end has the values to be used. The securityEngineID is used by USM when performing integrity checking and authentication, to look up values in the USM tables, and to synchronize "clocks". The securityEngineID is not needed by SSHSM, since integrity checking and authentication are handled outside the SNMP engine. [todo] is there still a need for an "authoritative SNMP engine"? Does authoritative have any meaning in a TMSM/SSHSM environment? In SNMPv3, the authoritative engine is usually the engine with the command responder, i.e. the agent; in non-proxy situations, securityEngineID equals contextEngineID. in client-server terms, the authoritative engine is usually the server. So, should the SNMP engine associated with the SSH server be authoritative? Would Infoms change that? Would bidirectional messaging change that? Would call- home change that? Do we need to set the securityEngineID to indicate which side is the SSH server? 2.2 Security Parameter Passing Requirement [SSHSM follows the TMSM approach, in which the security -model specific parameters can be determined from the transport layer by the transport mapping, before the message processing begins. [todo] For outgoing messages, it is necessary to have an MPSP portion of the security model because it is the MPSP that actually creates the WholeMsg from its component parts. In the SSHSM model, the MPSP does not apply encryption, integrity-checking, or authentication. For example, an SNMPv3 message is built without any content in the SecurityParameters field, and the WholeMsg is passed unencrypted back to the Message Processing Model for forwarding to the Transport Mapping. A cache mechanism will be used, into which the TMSP puts information about the security applied to an incoming message, and an MPSP extracts that information from the cache. Given that there may be multiple TM-security caches, a cache ID will need to be passed through an ASI so the MPSP knows which cache of information to consult. [todo] The cache reference could be thought of as an additional parameter in the ASIs between the transport mapping and the messaging security model. The RFC 3411 ASIs would not need to be changed since the Harrington, et al. Expires March 20, 2006 [Page 14] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 SNMPv3 WG expected that additional parameters could be passed for value-add features of specific implementations. This approach does create dependencies between a model-specific TPSP and a corresponding specific MPSP. If a TMSM-model-independent ASI parameter is passed, this approach would be consistent with the securityStateReference cache already being passed around in the ASI. 2.3 Requirements for Notifications [todo] cleanup this section RFC 3430 (SNMP over TCP) suggests that TCP connections are initiated by notification originators in case there is no currently established connection that can be used to send the notification. Following this approach with ssh would require to provision authentication credentials on the agent so that agents can successfully authenticate to a notification receiver. There might be other approaches, like the reuse of manager initiated secure transport connections for notifications. There is some text in Appendix A in RFC 3430 which captures some of these discussions when RFC 3430 was written. 2.4 Scenario Diagrams RFC 3411 section 4.6 provides scenario diagrams to illustrate how an outgoing message is created, and how an incoming message is processed. Both diagrams are incomplete, however.In section 4.61, the diagram doesn't show the ASI for sending an SNMP request to the network or receiving an SNMP response message from the network. In section 4.6.2, the diagram doesn't illustrate the interfaces required to receive an SNMP message from the network, or to send an SNMP message to the network. 2.4.1 Command Generator or Notification Originator This diagram from RFC 3411 4.6.1 shows how a Command Generator or Notification Originator application requests that a PDU be sent, and how the response is returned (asynchronously) to that application. Harrington, et al. Expires March 20, 2006 [Page 15] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 Command Dispatcher Message Security Generator | Processing Model | | Model | | sendPdu | | | |------------------->| | | | | prepareOutgoingMessage | | : |----------------------->| | : | | generateRequestMsg | : | |-------------------->| : | | | : | |<--------------------| : | | | : |<-----------------------| | : | | | : |------------------+ | | : | Send SNMP | | | : | Request Message | | | : | to Network | | | : | v | | : : : : : : : : : : : : : : : : | | | | : | Receive SNMP | | | : | Response Message | | | : | from Network | | | : |<-----------------+ | | : | | | : | prepareDataElements | | : |----------------------->| | : | | processIncomingMsg | : | |-------------------->| : | | | : | |<--------------------| : | | | : |<-----------------------| | | processResponsePdu | | | |<-------------------| | | | | | | 2.4.2 Command Responder This diagram shows how a Command Responder or Notification Receiver application registers for handling a pduType, how a PDU is dispatched to the application after an SNMP message is received, and how the Harrington, et al. Expires March 20, 2006 [Page 16] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 Response is (asynchronously) send back to the network. Command Dispatcher Message Security Responder | Processing Model | | Model | | | | | | registerContextEngineID | | | |------------------------>| | | |<------------------------| | | | | | Receive SNMP | | | : | Message | | | : | from Network | | | : |<-------------+ | | : | | | : |prepareDataElements | | : |------------------->| | : | | processIncomingMsg | : | |------------------->| : | | | : | |<-------------------| : | | | : |<-------------------| | | processPdu | | | |<------------------------| | | | | | | : : : : : : : : | returnResponsePdu | | | |------------------------>| | | : | prepareResponseMsg | | : |------------------->| | : | |generateResponseMsg | : | |------------------->| : | | | : | |<-------------------| : | | | : |<-------------------| | : | | | : |--------------+ | | : | Send SNMP | | | : | Message | | | : | to Network | | | : | v | | 2.5 Abstract Service Interfaces Harrington, et al. Expires March 20, 2006 [Page 17] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 3. RFC 3411 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. The Secure Shell Security Model uses some of these conceptual data flows when communicating with other subsystems, such as the Message Processing Subsystem. These RFC 3411-defined data flows are referred to here as public interfaces. 3.1 Public Abstract Service Interfaces 3.1.1 Public ASIs for Outgoing Messages The IN parameters of the prepareOutgoingMessage() ASI are used to pass information from the dispatcher (application subsystem) to the message processing subsystem. The OUT parameters are used to pass information from the message processing subsystem to the dispatcher and on to the transport mapping: 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 ) The abstract service primitive from a Message Processing Model to a Security Model to generate the components of a Request message is: Harrington, et al. Expires March 20, 2006 [Page 18] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 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 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 ) The abstract service primitive from a Message Processing Model to a Security Model to generate the components of a Response message is: 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 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 ) The abstract data elements passed as parameters in the abstract service primitives are as follows: [todo] check each parameter and determine if it is necessary for SSHSM and whether the description is accurate statusInformation - An indication of whether the encoding and securing of the message was successful. If not it is an indication of the problem. messageProcessingModel - The SNMP version number for the message to be generated. This data is not used by the User-based Security module. Harrington, et al. Expires March 20, 2006 [Page 19] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 globalData - The message header (i.e., its administrative information). This data is not used by the User-based Security module. maxMessageSize - The maximum message size as included in the message. This data is not used by the User-based Security module. securityParameters - These are the security parameters. They will be filled in by the SSH Security module. securityModel - The securityModel in use. Should be SSH Security Model. securityName - identifies a principal to be used for securing an outgoing message. The securityName has a format that is independent of the Security Model. In case of a response this parameter is ignored and the value from the cache is used. securityLevel - The Level of Security from which the SSH Security module determines if the message needs to be protected from disclosure and if the message needs to be authenticated. securityEngineID - The snmpEngineID of the authoritatvie SNMP engine to which a dateRequest message is to be sent. In case of a response it is implied to be the processing SNMP engine's snmpEngineID and so if it is specified, then it is ignored. scopedPDU - The message payload. The data is opaque as far as the SSH Security Model is concerned. securityStateReference - A handle/reference to cachedSecurityData to be used when securing an outgoing Response message. This is the exact same handle/reference as it was generated by the SSH Security module when processing the incoming Request message to which this is the Response message. wholeMsg - The fully encoded SNMP message ready for sending on the wire. wholeMsgLength - The length of the encoded SNMP message (wholeMsg). Upon completion of the process, the SSH Security module returns statusInformation. If the process was successful, the completed message is returned, without the privacy and authentication applied yet. If the process was not successful, then an errorIndication is returned. 3.1.2 Public ASIs for Incoming Messages The abstract service primitive from a Transport Mapping (in the dispatcher) to a Message Processing Model for a received message is:: Harrington, et al. Expires March 20, 2006 [Page 20] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 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 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 ) The abstract service primitive from a Message Processing Model to the Security Subsystem for a received message is:: 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 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 3.2 Private Abstract Service Interfaces A set of abstract service interfaces have been defined within this Harrington, et al. Expires March 20, 2006 [Page 21] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 document to describe the conceptual data flows between the Secure Shell Security Model (SSHSM) and the self-contained transport mapping services.These apply only to the Secure Shell Security Model (SSHSM), and are referred to here as private interfaces. The Secure Shell Security Model provides the following internal primitives to pass data back and forth between the Security Model itself and the SSH authentication service: statusInformation =3D establishSession( IN transportDomain -- transport domain to be used IN transportAddress -- transport address to be used IN securityModel -- Security Model to use IN securityEngineID -- SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested OUT sessionID ) 4. SNMP Messages Using this Security Model The syntax of an SNMP message using this Security Model adheres to the message format defined in the version-specific Message Processing Model document (for example [RFC3412]). At the time of this writing, there are three defined message formats - SNMPv1, SNMPv2c, and SNMPv3. 4.1 SNMPv1 and SNMPv2c Messages Using this Security Model Since message security is provided by a "lower layer", the message does not need to carry message security parameters within the PDU. The securityModel and securityName parameters are determined by the Secure Shell Security Model from the SSH service. SSHSM requires that transport always be authenticated and integrity-checked, and encrypted, so all SSHSM messages are authpriv. Since an incoming SNMPv1 or SNMPv2c message lacks a msgFlags field, the msgFlags is always treated as authPriv. [todo] The communitystring is not used as an authentication mechansism, since user authentication is provided by SSH userauth. The community string is still used to provide context information. Harrington, et al. Expires March 20, 2006 [Page 22] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 The SNMPv1 and SNMPv2c message formats do not contain a contextEngineID, but do contain an IP Address field that can be used to perform proxy. [todo] determine the proxy forwarding mechanism, if any. 4.2 SNMPv3 Messages Using this Security Model RFC 3412 defines two primitives, generateRequestMsg() and processIncomingMsg() which require the specification of an authoritative SNMP entity. [todo] We need to discuss what the meaning of authoritative would be in a TMSM environment, whether the specific services provided in USM security from msgSecurityParameters are needed in TMSM/SSHSM, and how the Message Processing model provides this information to the security model via generateRequestMsg() and processIncomingMsg() primitives. The SNMPv3Message SEQUENCE is defined in [RFC3412]. The following fields are specific to the Secure Shell Security Model: Harrington, et al. Expires March 20, 2006 [Page 23] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::=3D BEGIN SNMPv3Message ::=3D SEQUENCE { -- identify the layout of the SNMPv3Message -- this element is in same position as in SNMPv1 -- and SNMPv2c, allowing recognition -- the value 3 is used for snmpv3 msgVersion INTEGER ( 0 .. 2147483647 ), -- administrative parameters msgGlobalData HeaderData, -- security model-specific parameters -- format defined by Security Model msgSecurityParameters OCTET STRING, msgData ScopedPduData } HeaderData ::=3D SEQUENCE { msgID INTEGER (0..2147483647), msgMaxSize INTEGER (484..2147483647), msgFlags OCTET STRING (SIZE(1)), -- .... ...1 authFlag -- .... ..1. privFlag -- .... .1.. reportableFlag -- Please observe: -- .... ..00 is OK, means noAuthNoPriv -- .... ..01 is OK, means authNoPriv -- .... ..10 reserved, MUST NOT be used. -- .... ..11 is OK, means authPriv msgSecurityModel INTEGER (1..2147483647) } ScopedPduData ::=3D CHOICE { plaintext ScopedPDU, encryptedPDU OCTET STRING -- encrypted scopedPDU value } ScopedPDU ::=3D SEQUENCE { contextEngineID OCTET STRING, contextName OCTET STRING, data ANY -- e.g., PDUs as defined in [RFC3416] } END Harrington, et al. Expires March 20, 2006 [Page 24] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 4.2.1 msgGlobalData SSHSM requires that transport always be authenticated, integrity- checked, and encrypted, so all SSHSM messages are authpriv. The msgFlags MUST always be set to authPriv. msgSecurityModel is set to the IANA-assigned value for the Secure Shell Security Model. See http://www.iana.org/assignments/snmp-number-spaces. 4.2.1.1 msgSecurityParameters Since message security is provided by a "lower layer", and the securityName parameter is always determined from the SSH authentication method, the SNMP message does not need to carry message security parameters within the msgSecurityParameters field. To prevent its being used in a manner that could be damaging, such as for carrying a virus or worm, when used with SSHSM, it is an empty field. [todo] should this be an ASN.1 NULL within the OCTET STRING, or just a zero-length OCTET STRING? The field msgSecurityParameters in SNMPv3 messages has a data type of OCTET STRING. Its value MUST be the BER serialization of the following ASN.1 sequence: SSHSMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::=3D = BEGIN SSHsmSecurityParameters ::=3D SEQUENCE { NULL } END 4.2.1.2 msgFlags [todo] For an outgoing message, msgFlags is the requested security for the message; if a SSHSM cannot provide the requested securityLevel, the request MUST be discarded and SHOULD notify the message processing model that the request failed. [todo: how does this apply in the SSHSM model, especially if the msgFlags MUST always be set to authpriv?] [todo] do we need do discuss the rest of this, or is this applicable to all TMSM models? For an outgoing message, it is acceptable for the SSHSM to provide stronger than requested security. To avoid the need to mess with the Harrington, et al. Expires March 20, 2006 [Page 25] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 ASN.1 encoding, the SNMPv3 message carries the requested msgFlags, not the actual securityLevel applied to the message. If a message format other than SNMPv3 is used, then the new message may carry the more accurate securityLevel in the SNMP message. For an incoming message, the receiving SSHSM knows what must be done to process the message based on the transport layer mechanisms. If the underlying transport security mechanisms for the receiver cannot provide the matching securityLevel, then the message should follow the standard behaviors for the transport security mechanism, or be discarded silently. Part of the responsibility of the SSHSM is to ensure that the actual security provided by the underlying transport layer security mechanisms is configured to meet or exceed the securityLevel required by the msgFlags in the SNMP message. When the MPSP processes the incoming message, it should compare the msgFlags field to the securityLevel actually provided for the message by the transport layer security. If they differ, the MPSP should determine whether the changed securityLevel is acceptable. If not, it should discard the message. 4.3 Passing Security Parameters For each message received, the Security Model caches the state information such that a Response message can be generated using the same security information, even if the Configuration Datastore is altered between the time of the incoming request and the outgoing response. For SSHSM, there are three levels of state that need to be maintained: the session, the message, and the model-independent translations. [todo]ensuring consistent security for responses even if the datastore changes is important for USM because USM handles keychanges; will SSHSM allow keychanges to the SSH local datastore? if not, this cache of message-pair-state may be an unnecessary constraint. is it important to ensure responses use the same security as the request for secureity reasons? tmSessionReference is used to pass model- and mechanism-specific parameters to coordinate the session-related activities of the TMSP and MPSP. The SSHSM has the responsibility for explicitly releasing the tmSessionReference when the session is destroyed. tmStateReference is used to pass model- and mechanism-specific parameters to coordinate the activities of the TMSP and MPSP related to a specific pair of messages. The SSHSM has the responsibility for explicitly releasing the tmStateReference once a response message has Harrington, et al. Expires March 20, 2006 [Page 26] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 been sent, or the data is no longer needed. The MPSP translates select parameters from the tmSessionReference cache into model-independent parameters subsequently passed in the securityStateReference cache to a Message Processing Model. The Message Processing Model has the responsibility for explicitly releasing the securityStateReference if such data is no longer needed. The securityStateReference cached data may be implicitly released via the generation of a response, or explicitly released by using the stateRelease primitive, as described in RFC 3411 section 4.5.1." 4.3.1 Transport Session Parameters [todo] SSHSM will create a session between the TMSM of one SNMP entity and the TMSM of another SNMP entity. The created "tunnel" will provide encryption and data integrity. The SSHSM model MUST provide mutual authentication of the client and server, and MUST authenticate, integrity-check, and encrypt the messages. Upon establishment of a SSH session, the TMSP will cache the state information about the transport parameters. The tmSessionReference will be passed to the corresponding MPSP. [todo] The tmSessionReference cache for use with the SSH Authentication Protocol [SSHAuth]: tmStateReference tmSecurityStateReference tmTransportDomain =3D TCP/IPv4 tmTransportAddress =3D x.x.x.x:y tmSecurityModel - SSHSM tmSecurityLevel =3D "authPriv" tmSessionID =3D Handshake session identifier tmSessionKey =3D Handshake peer certificate tmSessionMasterSecret =3D master secret tmSessionParameters =3D compression method, cipher spec, is- resumable tmSecurityName =3D "dbharrington" tmAuthMechanism =3D "[todo]" tmAuthProtocol =3D "" tmRadiusServer =3D "" tmPrivProtocol =3D "" Additional information will be added to the tmStateReference by the authentication portion of the SSHSM. Harrington, et al. Expires March 20, 2006 [Page 27] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 4.3.1.1 Authenticating Servers and Clients [todo] can we mandate mutual authentication? 4.3.2 [todo] Using Local Accounts to Authenticate Users Upon creation of a SSH session leveraging SSH Local Accounts, the TMSP will cache the session authentication information in the tmSessionReference: tmSecurityName =3D "dbharrington" tmAuthMechanism =3D "public key" tmAuthProtocol =3D LocalAccounts 4.3.3 [todo] Using RADIUS Accounts to Authenticate Users Upon creation of a SSH session leveraging RADIUS Accounts, the TMSP will cache the session authentication information in the tmSessionReference: tmSecurityName is the name used in username field of the RADIUS ACCESS-REQUEST message. tmAuthMechanism =3D "[todo]" tmAuthProtocol =3D RADIUS tmRadiusServer =3D x.x.x.x:y 4.3.4 securityStateReference for SSHSM [todo] messageProcessingModel =3D SNMPv3 securityModel =3D SSHSM securityName =3D tmSecurityName securityLevel =3D msgSecurityLevel 4.4 MIB Module for SSH Security Model Each security model should use its own MIB module, rather than utilizing the USM MIB, to eliminate dependencies on a model that could be replaced some day. See RFC 3411 section 4.1.1. The SSHSM-MIB module needs to provide the mapping from model-specific identity to a model independent securityName, and possibly a mapping to a groupname. [todo] Module needs to be worked out once things become stable... 4.5 [todo] Notifications For notifications, if the cache has been released and then session closed, then the MPSP will request the TMSP to establish a session, Harrington, et al. Expires March 20, 2006 [Page 28] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 populate the cache, and pass the securityStateReference to the MPSP. [todo] We need to determine what state needs to be saved here. 5. Elements of Procedure 5.1 Establishing a Session The Secure Shell Security Model provides the following internal primitive to pass data back and forth between the Security Model itself and the SSH authentication service: statusInformation =3D establishSession( IN transportDomain -- transport domain to be used IN transportAddress -- transport address to be used IN securityModel -- Security Model to use IN securityEngineID -- SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested OUT sessionID ) The following describes the procedure to follow to establish a session between a client and sever to run SNMP over SSH. This process is followed by any SNMP engine establishing a session for subsequent use. In practice, this is done by an application that initiates a transaction, such as a Command Generator or a Notification Originator or a Proxy Forwarder. It is never triggered by an application preparing a response message, such as a Command Responder or Notification Receiver, because securityStatereference will always have session information for a response message The parameters necessary to establish a session are provided by the Secure Shell Security Model to the SSH client code, using the establishSession() ASI. 1) If the securityLevel specifies that the message is to be authenticated, but the SSH implementation does not support an authentication protocol, then the message cannot be sent. An error indication (unsupportedSecurityLevel) is returned to the calling module. 2) If the securityLevel specifies that the message is to be protected from disclosure, but the SSH implementation does not support Harrington, et al. Expires March 20, 2006 [Page 29] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 encryption, then the message cannot be sent. An error indication (unsupportedSecurityLevel) is returned to the calling module. 3) Using destTransportDomain and destTransportAddress, the client will establish an SSH transport connection using the SSH transport protocol, and the client and server will mutually authenticate, and exchange keys for message integrity and encryption. if the attempt to establish a connection is successful, then tmStateReference is created, and the values of destTransportDomain and destTransportAddress are saved. If the attempt to establish a connection is unsuccessful, then an error indication [todo] will be returned, and [todo] processing stops. 4) The provided securityEngineID is used to lookup the associated entry in the Local Configuration Datastore (LCD), and the securityName, securityModel, and securityLevel, information concerning the user at the destination is extracted. This step allows preconfiguration of model-specific user identities mapped to a securityName. Set the username in the SSH_MSG_USERAUTH_REQUEST to the username extracted from the LCD. If information about the user is absent from the LCD, then set the username in the SSH_MSG_USERAUTH_REQUEST to the value of securityName. This allows a deployment without preconfigured mappings between model-specific and model-independent names, but the securityName will need to contain a username recognized by the authentication mechanism. 5)The client will then invoke the "ssh-userauth" service to authenticate the user, as described in the SSH authentication protocol [SSHAuth]. 6) If the authentication is unsuccessful, then the transport connection should be closed, tmStateReference is discarded, the message is discarded, an error indication (unknownSecurityName) is returned to the calling module, and processing stops for this message. 7) Once the user has been successfully authenticated, the client will invoke the "ssh- connection" service, also known as the SSH connection protocol [SSHConnect]. 8) After the ssh-connection service is established, the client will use an SSH_MSG_CHANNEL_OPEN message to open a channel of type "session", providing a selected sender channel number, and a maximum packet size based on maxMessageSize. 9) If successful, this will result in an SSH session. The Harrington, et al. Expires March 20, 2006 [Page 30] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 destTransportDomain nd the destTransportAddress, plus the "recipient channel" and "sender channel" and other relevant data from the SSH_MSG_CHANNEL_OPEN_CONFIRMATION are added to the tmStateReference for subsequent use. 10) Once the SSH session has been established, the SNMP engine will invoke SNMP as an SSH subsystem called "SNMP". Running SNMP as an SSH subsystem avoids the need for the script to recognize shell prompts or skip over extraneous information, such as a system message that is printed at shell start-up. In order to allow SNMP traffic to be easily identified and filtered by firewalls and other network devices, servers associated with SNMP entities using the Secure Shell Security Model MUST default to providing access to the "SNMP" SSH subsystem only when the SSH session is established using the IANA-assigned TCP port (TBD). Servers SHOULD be configurable to allow access to the SNMP SSH subsystem over other ports. [todo] check whether there is a better way to establish a tunnel for SNMP messages. [todo] Should we perform some type of engineID discovery to provide the mapping between transport address, session, and engineID at this point in the session establishment procedure? We have an established channel; can we simply send a GET of snmpEngineID and record the value i the tmStateReference? 11) [todo] the engine will perform an SNMP GET command requesting the value of the remote engine's snmpEngineID object, and create a tmSessionReference cache recording the following information: the remote engine's snmpEngineID the transport address the recipient and sender channels 5.2 Discovery Since snmpEngineID isn't really needed for authentication and integrity checking, it becomes useful primarily for contextEngineID. contextEngineID is useful for proxy, and for a management application to uniquely identify an SNMP entity. Since snmpEngineID is an object in the SNMP-FRAMEWORK-MIB, the mapping between engineID and transport address could be established after a tunnel is established, or could be determined using noAuthNoPriv (with suitable caveats). [todo] Auto-discovery of SNMP devices is an important feature of many NMS platforms. Should we simply use a noAuthNoPriv request, and recommend an associated access control configuration that only makes Harrington, et al. Expires March 20, 2006 [Page 31] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 accessible relatively benign data such as sysOID, sysDescription, and snmpEngineID? Should we standardize this approach for all TMSM models, including a "named policy" for what can be discovered (a policy to be configured within whatever access control system is used)? Alternatively, can we let USM perform discovery so we don't have to attenpt to establish an SSH connection first? USM is the mandatory- to-implement security model, so this could make sense. 5.3 Generating an Outgoing SNMP Message This section describes the procedure followed by the Secure Shell Security Model whenever it generates a message containing a management operation (like a request, a response, a notification, or a report) on behalf of a user. The parameters needed are supplied by the Message Processing Model via the generateRequestMsg() or the generateResponseMsg() ASI 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 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 -- reference to session info ) Harrington, et al. Expires March 20, 2006 [Page 32] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 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 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 -- reference to session info ) verify securityModel =3D sshsmSecurityModel If there is a securityStateReference, extract the tmStateReference information from the cachedSecurityData from the Request message. [todo] With USM, at the point the cachedSecurityData can now be discarded. Since we now have persistent sessions, this is no longer true, but can some of the cached data be discarded, such as message pair information? If there is no securityStateReference, then lookup the session info indexed by {securityEngineID, securityName, securityLevel}, and set tmStateReference. If there is no session info for this index, then create an incomplete tmStateReference indexed by the provided {securityEngineID, securityName, securityLevel}. Store the securityModel and maxMessageSize information. When the TMSP gets the incomplete tmStateReference, it will recognize that it needs to establish a new session, and fill in the rest of the information for subsequent use. fill in securityParameters [todo] a NULL octet string since [todo] we don't need to send securityEngineID, unless it is needed for a discovery mechanism.. [todo] we don't need to send Boots and Time values [todo] we don't need to send a username, since we use the one from SSH authentication [todo] we don't need to call authenticateOutgoingMsg() The wholeMsg is now serialized and then represents the unauthenticated message being prepared. The completed message (wholeMsg) with its length (wholeMsgLength) and securityParameters (a NULL octet string) and tmStateReference is returned to the calling module with the statusInformation set Harrington, et al. Expires March 20, 2006 [Page 33] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 to success. The Message Processing Model then passes information to the disptacher for forwarding to the Transport Mapping. 5.4 Sending an Outgoing SNMP Message to the Network The TMSP portion of the Secure Shell Security Model performs the following tasks: Uses tmStateReference to lookup session information. [todo] verifies that auth and priv can be provided, as requested, and error-out if not. If the session information is incomplete (i.e, has no tmTransportAddress), then call establishSession() using the destTransportDomain and destTransportAddress (the output of the PrepareOutgoingMessage() ASI) and the securityModel, securityEngineID, securityName, securityLevel from the tmStateReference. Store all information in the tmStateReference for subsequent use. An SSH_MSG_CHANNEL_DATA message is sent, indicating the recipient channel and encapsulating the wholeMessage. [todo] According to RFC 3411, section 4.1.1, the application provides the transportDomain and transportAddress to the PDU dispatcher via the sendPDU() primitive. If we permit multiple sessions per transportAddress, then we would need to define how session identifiers get passed from the application to the PDU dispatcher (and then to the MP model). [todo] The SNMP over TCP Transport Mapping document [RFC3430] says that TCP connections can be recreated dynamically or kept for future use and actually leaves all that to the transport mapping. [todo] We might have a MIB module that records the session information for subsequent use by the applications and other subsytems, or it might be passed in the tmStateReference cache. For notifications, I assume the SNMPv3 notification tables would be a place to find the address, but I'm not sure how to identify the presumably-dynamic session identifiers. The MIB module could identify whether the session was initiated by the remote engine or initiated by the current engine, and possibly assigned a purpose (incoming request/response or outgoing notifications). First we need to decide whether to handle notifications and requests in one or two (or more) sessions. Do we use an established session bi- directionally, or do we establish two separate sessions, one for each direction as needed? Harrington, et al. Expires March 20, 2006 [Page 34] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 5.5 [todo] Prepare Data Elements from an Incoming SNMP Message For an incoming message, the TMSP will need to put information from the transport mechanisms used into the tmStateReference so the MPSP can extract the information and add it conceptually to the securityStateReference. 5.6 Processing an Incoming SNMP Message This section describes the procedure followed by an SNMP engine whenever it receives a message containing a management operation on behalf of a user. 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 gets discarded, the message-state information should also be released. Also, an error indication can return an OID and value for an incremented counter and optionally a value for securityLevel, and values for contextEngineID or contextName for the counter. In addition, the securityStateReference data is returned if any such information is available at the point where the error is detected. [todo] this paragraph may no longer be accurate because of persistent session state information. The abstract service primitive from a Message Processing Model to the Security Subsystem for a received message is:: 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 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 1) If the received securityParameters is not the serialization of an OCTET STRING formatted according to the SSHsmSecurityParameters , Harrington, et al. Expires March 20, 2006 [Page 35] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 then the snmpInASNParseErrs counter [RFC3418] is incremented, and an error indication (parseError) is returned to the calling module. [todo] Note that we return without the OID and value of the incremented counter, which may be important if this security model supports generating a Report PDU (which SSHSM doesn't so far), because in this case there is not enough information to generate a Report PDU. [todo] If we actually do not extract anything from securityParameters, do we need to check whether this parses correctly? It apparently parsed well enough to pass the parse test in the messaging model. Could we simply ignore the securityParameters being passed in? The only argument I see for checking to ensure this is empty/null is to ensure somebody isn't using the filed for non-standard purposes, such as passing a virus in the field. 2) The SSHSM queries the associated SSH engine, in an implementation-dependent manner, to determine the transport and security parameters for the received message: a) the transportDomain and transportAddress b) the authentication parameters, including the authenticated username c) the encryption options, d) the integrity-checking options 3) The securityEngineID to be returned to the caller is determined in an implementation-dependent manner, such as by using the transport address to perform a lookup in its Local Configuration Datastore (LCD). If the securityEngineID is unknown, then an SNMP engine may perform discovery to create a new entry in its LCD and continue processing. Note that securityEngineID is required by the SNMPv3 message processing model in RFC 3412 section 7.2 13a) 4) If the information about the message security indicates that the security options do not match the securityLevel requested by the caller, then the SSHsmStatsUnsupportedSecLevels counter is incremented and an error indication (unsupportedSecurityLevel) together with the OID and value of the incremented counter is returned to the calling module. 5) The scopedPDU component is assumed to be in plain text and is the message payload to be returned to the calling module. 7) The maxSizeResponseScopedPDU is calculated. This is the maximum size allowed for a scopedPDU for a possible Response message. Provision is made for a message header that allows the same securityLevel as the received Request. Harrington, et al. Expires March 20, 2006 [Page 36] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 [todo] Is this relevant? Can it be calculated once for the session? Do we need to take into consideration the SSH window size? 10) Information about the value of the SSH username is extracted from the Local Configuration Datastore (LCD) to provide conversion from the SSHSM model-specific username to a model-independent securityName. If no information is available for the username, then the securityName is set to the username used in the SSH-USER-AUTH- REQUEST. [todo] Note that USM at this point would flag an unknownSecurityName error. 11) The security data is cached as cachedSecurityData, so that a possible response to this message can and will use the same authentication and privacy parameters. Information to be saved/ cached is as follows: transportDomain, transportAddress securityEngineID SSH username, auth options [todo] encryption options [todo] Integrity checking options [todo] 12) 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 primitive. 6. MIB module definition SSHSM-MIB DEFINITIONS ::=3D BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB; sshsmMIB MODULE-IDENTITY LAST-UPDATED "200509020000Z" ORGANIZATION "ISMS Working Group" CONTACT-INFO "WG-EMail: isms@lists.ietf.org Subscribe: isms-request@lists.ietf.org Chair: Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 Harrington, et al. Expires March 20, 2006 [Page 37] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 69115 Heidelberg Germany +49 6221 90511-15 quittek@netlab.nec.de Co-editors: David Harrington Effective Software 50 Harding Rd Portsmouth, New Hampshire 03801 USA +1 603-436-8634 ietfdbh@comcast.net Juergen Schoenwaelder International University Bremen Campus Ring 1 28725 Bremen Germany +49 421 200-3587 j.schoenwaelder@iu-bremen.de Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 USA jsalowey@cisco.com " DESCRIPTION "The Secure Shell Security Model MIB Copyright (C) The Internet Society (2005). 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 "200509020000Z" -- 02 September 2005 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 Harrington, et al. Expires March 20, 2006 [Page 38] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 -- ---------------------------------------------------------- -- -- subtrees in the SSHSM-MIB -- ---------------------------------------------------------- -- sshsmNotifications OBJECT IDENTIFIER ::=3D { sshsmMIB 0 } sshsmObjects OBJECT IDENTIFIER ::=3D { sshsmMIB 1 } sshsmConformance OBJECT IDENTIFIER ::=3D { sshsmMIB 2 } -- ------------------------------------------------------------- -- Objects -- ------------------------------------------------------------- -- ------------------------------------------------------------- -- sshsmMIB - Conformance Information -- ------------------------------------------------------------- sshsmGroups OBJECT IDENTIFIER ::=3D { sshsmConformance 1 } sshsmCompliances OBJECT IDENTIFIER ::=3D { sshsmConformance 2 } -- ------------------------------------------------------------- -- Units of conformance -- ------------------------------------------------------------- sshsmGroup OBJECT-GROUP OBJECTS { } STATUS current DESCRIPTION "Secure Shell Security Model objects" ::=3D { sshsmGroups 2 } -- ------------------------------------------------------------- -- Compliance statements -- ------------------------------------------------------------- sshsmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for support of the Secure Shell Security Model" MODULE MANDATORY-GROUPS { } ::=3D { sshsmCompliances 1 } Harrington, et al. Expires March 20, 2006 [Page 39] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 END 7. Security Considerations This document describes a security model that would permit SNMP to utilize SSH security services. [todo] expand as needed. SSHv2 provides PFS for encryption keys. PFS is a major design goal of SSH, and any well-designed keyex algorithm will provide it. [todo] We will probably need to discuss the security implications of password based authentication methods. 8. IANA Considerations IANA is requested to assign: a TCP port number which will be the default port for SNMP over SSH sessions as defined in this document, an SMI number under mib-2, for the MIB module in this document, an SNMP SecurityModel for the Secure Shell Security Model, as documented in the MIB module in this document, 9. Acknowledgments The editors would like to thank Jeffrey Hutzelman and Nicholas Williams for sharing their SSH insights. 10. References 10.1 Normative References [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 SNMP", STD 62, RFC 3412, 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. [RFC3417] Presuhn (Editor), R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, Harrington, et al. Expires March 20, 2006 [Page 40] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 December 2002. [RFC3430] Schoenwaelder, J., "Simple Network Management Protocol (SNMP) over Transmission Control Protocol (TCP) Transport Mapping", RFC 3430, December 2002. [TMSM] Harrington, D. and J. Schoenwaelder, "Transport Mapping Security Model (TMSM) for the Simple Network Management Protocol version 3 (SNMPv3)", draft-schoenw-snmp-tlsm-04.txt (work in progress), August 2005. [SSHArch] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", draft-ietf-secsh-architecture-22 (work in progress), March 2005. [SSHTrans] Lonvick, C., "SSH Transport Layer Protocol", draft-ietf-secsh-transport-24 (work in progress), March 2005. [SSHAuth] Lonvick, C. and T. Ylonen, "SSH Authentication Protocol", draft-ietf-secsh-userauth-27 (work in progress), March 2005. [SSHConnect] Lonvick, C. and T. Ylonen, "SSH Connection Protocol", draft-ietf-secsh-connect-25 (work in progress), March 2005. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [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. Harrington, et al. Expires March 20, 2006 [Page 41] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 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. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [Netconf] Enns, R., "NETCONF Configuration Protocol", ID draft-ietf-netconf-prot-04.txt, October 2004. [NetconfSSH] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure Shell (SSH)", draft-ietf-netconf-ssh-04 (work in progress), April 2005. [gsskeyex] Hutzelman, J., "GSSAPI Authentication and Key Exchange for the Secure Shell Protocol", draft-ietf-secsh-gsskeyex-09 (work in progress), May 2005. Authors' Addresses David Harrington Effective Software Harding Rd Portsmouth NH USA Phone: +1 603 436 8634 Email: dbharrington@comcast.net Juergen Schoenwaelder International University Bremen Campus Ring 1 28725 Bremen Germany Phone: +49 421 200-3587 Email: j.schoenwaelder@iu-bremen.de Harrington, et al. Expires March 20, 2006 [Page 42] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 USA Email: jsalowey@cisco.com Appendix A. Change Log from the first revision of -00- -00-b draft: re-ordered the sections from abstract to concrete. worked on how the SSHSM fitsinto the RFC3411 and TMSM architectures. added goals tot he Motivation section. worked on Security Capabilities based on input from Joe, Nick, and JHutz. Added Joe to the authors list based on contributed text. created Data origin Authentication section, to separate this discussion. expanded "Authentication Protocol" section Updated Message replay section. --00-c draft worked on security information cacheing, including breaking caches into session, message, and model-independent (which we probably want to remerge later) eliminated a lot of TMSM-carryover stuff and modified to be SSHSM- specific. updated references. filled in Elements of Procedure for Outgoing Messages created shell for SSHSM-MIB -01- draft added Processing an Incoming Message updated change log modified masquerade discussion to differentiate server vs user authentication added [todos] for Data origin Authentication Issues section, trying to nail down whether we even need this section. disallow the 'none' MAC algorithm added text to Message secuirty versus session security wordsmithed "authentication protocol" section rewrote "Mapping SSH to EngineID", eliminating most [todos] modified "Establishing a Session" Harrington, et al. Expires March 20, 2006 [Page 43] =0C Internet-Draft Secure Shell Security Model for SNMP September 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Harrington, et al. Expires March 20, 2006 [Page 44] =0C ------=_NextPart_000_0C10_01C5BB05.A9225FC0 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_0C10_01C5BB05.A9225FC0-- From isms-bounces@lists.ietf.org Tue Sep 20 12:45:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHlFi-0006sl-SF; Tue, 20 Sep 2005 12:45:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHlFh-0006sZ-Bo; Tue, 20 Sep 2005 12:45:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14010; Tue, 20 Sep 2005 12:45:50 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHlLW-0002UF-Qz; Tue, 20 Sep 2005 12:51:57 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 20 Sep 2005 09:45:41 -0700 X-IronPort-AV: i="3.97,127,1125903600"; d="scan'208"; a="213320358:sNHT30982086" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j8KGjbVt018301; Tue, 20 Sep 2005 09:45:37 -0700 (PDT) Received: from [144.254.148.216] (dhcp-144-254-148-216.cisco.com [144.254.148.216]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j8KGvoh0023639; Tue, 20 Sep 2005 09:57:51 -0700 Message-ID: <43303CB3.9040203@cisco.com> Date: Tue, 20 Sep 2005 18:45:39 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: isms@ietf.org, IETF Discussion , NANOG list X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=686; t=1127235471; x=1127667671; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:new=20mailing=20list=20on=20call=20home| From:Eliot=20Lear=20| Date:Tue,=2020=20Sep=202005=2018=3A45=3A39=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=QFXqdBoncDvnd+9t5G/CB7W63ioD3yPL84SJKI3BHf0Xf2dgmsken4wVxC7B8voqfIEwM9aW xfKbGi31qZSAje73WhZYzOwBZKbUcFihwDEDv3PncLrvAIQ074vpOAORZmaZrmLKRDiVwGT9CuO S//TFsDo3zrggFDF1QpkmMmg= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] new mailing list on call home X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hello everyone, I'd like to announce the creation of a new mailing list, call-home@ietf.org. The purpose of this list is to discuss firewall "call home" functionality and firewall traversal issues. When I say "call home" I mean the case where connections/communications are initiated by applications that might more traditionally be classed "servers". The latest example is SNMP, and this is the one I will focus my attention on. I am developing a draft as well as a BoF agenda for a Bof I hope to hold at IETF64, but relevant architectural points to the general notion are welcome. If you participated in the previous discussion on ISMS, I encourage you to join call-home. To subscribe, go to the following URL and follow the directions: https://www1.ietf.org/mailman/listinfo/call-home Thanks for your time, Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 20 17:21:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpYg-0000S4-5N; Tue, 20 Sep 2005 17:21:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpYa-0000Rj-EN for isms@megatron.ietf.org; Tue, 20 Sep 2005 17:21:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06312 for ; Tue, 20 Sep 2005 17:21:37 -0400 (EDT) Received: from i84df.i.pppool.de ([85.73.132.223] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHpeT-0003hO-2c for isms@ietf.org; Tue, 20 Sep 2005 17:27:46 -0400 Received: by boskop.local (Postfix, from userid 501) id 371E7403AAD; Tue, 20 Sep 2005 23:21:24 +0200 (CEST) Date: Tue, 20 Sep 2005 23:21:24 +0200 From: Juergen Schoenwaelder To: kaushik@cisco.com Message-ID: <20050920212124.GA1131@boskop.local> Mail-Followup-To: kaushik@cisco.com, dbharrington@comcast.net, jsalowey@cisco.com, isms@ietf.org References: <618694EF0B657246A4D55A97E38274C39E15FC@xmb-sjc-22d.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <618694EF0B657246A4D55A97E38274C39E15FC@xmb-sjc-22d.amer.cisco.com> User-Agent: Mutt/1.5.10i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: dbharrington@comcast.net, isms@ietf.org Subject: [Isms] Re: Some text on identity and authentication for SSHSM X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Sat, Sep 17, 2005 at 12:17:02PM -0700, kaushik@cisco.com wrote: > > I am only allows to use SSHSM with public keys if I also use them for > the CLI? I fail to see the purpose of this CLR. > > > > I think this text is not very clear. Fundamentally without X.509 > certificate support for user authentication you would need > identity/public keys to be manually provisioned on SNMP engines (that > act SSH servers)to authenticate requests that use the "publickey" > method, i.e. agents will need to be provisioned identity/public key in > order to authenticate managers that might use publickey method of SSH > user authentication. If these keys are not already provisioned to be > used by NetConf/CLI (over SSH), then having to provision these keys for > use within SNMP actually has the same issues as SNMPv3/USM. The text > intends to state that without X.509 support, the "publickey" method of > SSH user authentication is not preferred unless it is already in use by > other management protocols such as NetConf that use SSH transport. > > I believe the document should specify how the SSHSM works but not include best current practice usage guidelines or applicability statements. I have the feeling that we currently mix all these things together. There might be operators who find it easier to administrate SSH public keys compared to SNMPv3/USM keys and I believe we should let operators make such decisions. So I am fine with a statement that highlights that SNMP over SSH can leverage keys installed for other management purposes - I dislike statements which say "you should not use SNMP over SSH if you have to install public keys for this purpose and no other management access mechanism. The later sounds like a CLR to me. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Sep 20 17:40:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHprH-0007XC-DD; Tue, 20 Sep 2005 17:40:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHprG-0007X4-AI for isms@megatron.ietf.org; Tue, 20 Sep 2005 17:40:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07670 for ; Tue, 20 Sep 2005 17:40:55 -0400 (EDT) From: kaushik@cisco.com Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHpx8-0004KT-Cm for isms@ietf.org; Tue, 20 Sep 2005 17:47:04 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 20 Sep 2005 14:40:47 -0700 X-IronPort-AV: i="3.97,128,1125903600"; d="scan'208"; a="343680313:sNHT30267912" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8KLea52000623; Tue, 20 Sep 2005 14:40:44 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 14:40:42 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Sep 2005 14:40:41 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3A323FF@xmb-sjc-22d.amer.cisco.com> Thread-Topic: Some text on identity and authentication for SSHSM Thread-Index: AcW+KVXTSD+6hvw3TW2fUNYEzbYD4QAAKvLQ To: X-OriginalArrivalTime: 20 Sep 2005 21:40:42.0547 (UTC) FILETIME=[F358A030:01C5BE2B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: dbharrington@comcast.net, isms@ietf.org Subject: [Isms] RE: Some text on identity and authentication for SSHSM X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Juergen, Please find my reply inline.=20 >=20 > I think this text is not very clear. Fundamentally without X.509=20 > certificate support for user authentication you would need=20 > identity/public keys to be manually provisioned on SNMP engines (that=20 > act SSH servers)to authenticate requests that use the "publickey" > method, i.e. agents will need to be provisioned identity/public key in > order to authenticate managers that might use publickey method of SSH=20 > user authentication. If these keys are not already provisioned to be=20 > used by NetConf/CLI (over SSH), then having to provision these keys=20 > for use within SNMP actually has the same issues as SNMPv3/USM. The=20 > text intends to state that without X.509 support, the "publickey"=20 > method of SSH user authentication is not preferred unless it is=20 > already in use by other management protocols such as NetConf that use SSH transport. >=20 > I believe the document should specify how the SSHSM works but not include best current practice usage guidelines or applicability statements. I have the feeling that we currently mix all these things together. There might be operators who find it easier to administrate SSH public keys compared to SNMPv3/USM keys and I believe we should let operators make such decisions. So I am fine with a statement that highlights that SNMP over SSH can leverage keys installed for other management purposes - I dislike statements which say "you should not use SNMP over SSH if you have to install public keys for this purpose and no other management access mechanism. The later sounds like a CLR to me. That's a fair comment. I will remove that sentence. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Sep 21 21:57:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIGKv-0002Qn-Fi; Wed, 21 Sep 2005 21:57:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIGKt-0002Qi-TA for isms@megatron.ietf.org; Wed, 21 Sep 2005 21:57:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16169 for ; Wed, 21 Sep 2005 21:57:18 -0400 (EDT) Received: from [131.107.167.7] (helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIGR1-00015s-T3 for isms@ietf.org; Wed, 21 Sep 2005 22:03:41 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id ABE03E0049; Wed, 21 Sep 2005 21:57:03 -0400 (EDT) To: isms@ietf.org From: Sam Hartman Date: Wed, 21 Sep 2005 21:57:03 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Isms] Looking for new chair X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, folks. I'm sorry to report that Ken Hornstein has agreed to step down as an ISMS chair. Since taking on that role, his job responsibility has changed and he does not have significant time to spend on the IETF. I continue to believe that Ken would be an excellent chair if he had the time. I hope that at some future point he will be available to chair a working group. I would be interested in private suggestions of potential chairs. Feel free to volunteer yourself or to suggest people I should talk to. I do have some people I'm trying to convince to take the job. Thanks, --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Sep 22 13:45:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIV8M-0005xz-RG; Thu, 22 Sep 2005 13:45:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIV8L-0005xb-SK for isms@megatron.ietf.org; Thu, 22 Sep 2005 13:45:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13468 for ; Thu, 22 Sep 2005 13:45:20 -0400 (EDT) Received: from [131.107.167.7] (helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIVEb-0007jU-W0 for isms@ietf.org; Thu, 22 Sep 2005 13:51:50 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 90D8DE0049; Thu, 22 Sep 2005 13:44:59 -0400 (EDT) To: isms@ietf.org From: Sam Hartman Date: Thu, 22 Sep 2005 13:44:59 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Subject: [Isms] Response/Summary of IETF review on ISMS charter X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi. We had a very productive review of the ISMS charter on the ietf list. Here's my response and action plan going forward on that issue. Based on comments on the list here, comments to the ietf list, numerous phone calls/jabber sessions and in-person discussions I believe everyone will be able to move forward with this proposal. If there are problems let me know and we'll see what we can do. Included in this message: * Review of IETF Discussion * IESG Decision and AD Comments * evaluating Extensibility of ISMS Output Review of IETf Discussion There was significant interest in considering firewall and NAT traversal for SNMP and for broader management applications. Several people pointed out why this is more involved than just specifying extensions to the ISMS ssh draft. Several people said they believed that the actual extensions to the ISMS drafts are simple. There was rough consensus that it would be a bad idea to produce ISMS specifications that did not even enable firewall/nat traversal and then later decide that this traversal was an important extension to the SNMP architecture. However there was also a rough consensus that ISMS need not block on the decisions about whether to implement traversal or about the specific architectural issues. A few people did raise the concern that having two standards come out requiring products to be updated first for ISMS and then later for traversal would be undesirable. However the rough consensus was that these efforts need not block each other. I make no consensus call on whether there is a consensus in the SNMP community to extend SNMP to support firewall and NAT traversal. That's a call I'm not qualified to make and one that needs to be made by the O&M ADs. In addition that decision needs to happen within the O&M area. I didn't see a specific charter text proposal change. There was something reasonably close I believe from David Nelson proposing that we add something about considering call home in the design of ISMS to the charter. While there was support for this consideration expressed both on the ietf list and the isms list, there was not a rough consensus that charter changes are required. Summary of IESG Decision and AD Comments The IESG has approved the ISMS charter with no modifications. The announcement will come out as soon as I find a chair to replace Ken. Chairs and participants should move forward under the new charter. For example it would be reasonable for the chairs to approve documents that meet charter deliverables. However it is important that we consider the firewall and nat traversal issues in our design of the ISMS architecture. In particular we should consider firewall and nat traversal as a possible extension to ISMS. It is desirable that we be able to accommodate such an extension with the protocols we design. Similarly we should follow the discussion of this extension in the O&M area. If the O&M area decides to extend SNMP in this direction and completes the appropriate architectural work, then we will need to support firewall and nat traversal in our protocol. That said, there are two things we must not do. First, we cannot standardize firewall and nat traversal in the ISMS protocol without a normative reference to a specification for how it works in SNMP. It's not a good idea for devices to be saying "manage me," without an SNMP architecture that provides for configuration of this functionality and for well defined semantics. In other words, we can enable traversal as an extension, we can have an extension ready to plug into the document and we can plug in that extension if the SNMP community gives us the architectural framework to reference. we cannot plug in the extension before that happens and we will not wait if we're done and the SNMP community is still working on the issue. Also, if the SNMP community decides that they are not interested in firewall/nat traversal we will spend much less time on it. The other thing we must not do is allow firewall and nat traversal to block our progress. If we get to a situation where we have a rough consensus if we ignore firewall and nat traversal, but we are unable to efficiently form a consensus while considering firewall and nat traversal, then we move on ignoring firewall and nat traversal for that issue. Things do change if the SNMP community formally decides to implement firewall and nat traversal for us. If that happens, then parts of firewall and nat traversal may be blocking issues for us. In addition, some of the people arguing for solving the traversal problem believe that working on the architectural extensions within ISMS might be reasonable. This would require a charter revision, but I would not object to such a charter revision if the right people were following ISMS and if it had sufficient O&M support. I also would not object to doing the work elsewhere. Evaluating Extensibility of ISMS Extensibility of protocols is an important evaluation criteria. When looking at the ISMS output, I will look at how easy it would be to add likely extensions to the protocol. Is there sufficient capability negotiation? Can we add fields, messages or functionality? Are there clear policies for how extensions are managed? I will be surprised if ISMS output meets extensibility goals and could not be extended to support firewall and nat traversal. I would certainly require an explanation from the working group of why this was the case. Sam Hartman Area Director _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Sep 30 21:02:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELVlp-0000nQ-Jd; Fri, 30 Sep 2005 21:02:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELVln-0000nL-Jr for isms@megatron.ietf.org; Fri, 30 Sep 2005 21:02:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01974 for ; Fri, 30 Sep 2005 21:02:30 -0400 (EDT) Message-Id: <200510010102.VAA01974@ietf.org> Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELVtk-0004il-Rk for isms@ietf.org; Fri, 30 Sep 2005 21:10:46 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <2005100101022101400pqjfhe>; Sat, 1 Oct 2005 01:02:21 +0000 From: "David B Harrington" To: Date: Fri, 30 Sep 2005 21:02:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXGI8RDoTfE86JdQFmQwBFf+707WQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] authoritative X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, In SNMPv3, we have the concept of authoritative. We need to discuss what that means for the SSH security model. I am especially interested in hearing from those who helped develop SNMPv3 and the notion of authoritative engines in the first place, and those who fought for the manager being authoritative for Informs (of whom I am one). Obviously everybody is welcome to get in involved, but I'm really trying to understand whether the historical requirement is stll valid, and if you don't know what that historical requirement was, you probably cannot answer the question very well. Once we establish the requirement, we can determine whether SSH meets the requirement, in both normal mode and the proposed callback mode. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms