From isms-bounces@lists.ietf.org Wed Feb 01 14:42:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4NsW-0005xb-Fk; Wed, 01 Feb 2006 14:42:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4NsT-0005ue-KA for isms@megatron.ietf.org; Wed, 01 Feb 2006 14:42:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26967 for ; Wed, 1 Feb 2006 14:41:15 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4O3e-00022r-32 for isms@ietf.org; Wed, 01 Feb 2006 14:54:28 -0500 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 k11Jgg1l026508; Wed, 1 Feb 2006 11:42:42 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id k11JgWBS000494; Wed, 1 Feb 2006 11:42:32 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id k11JgVg7000484; Wed, 1 Feb 2006 11:42:32 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 1 Feb 2006 11:42:31 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Wes Hardaker Subject: Re: [Isms] notifications and SSH authentication In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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, Wes - good summary of the issues and flow. I hope that I'll be able before the interim ISMS meeting to put together a visual of the description that I wrote up a few years back that walks through the logic in using the 5 SNMP admin tables used in delivering notifications. And also to customize the descriptions for ISMS-SSH. On Mon, 30 Jan 2006, Wes Hardaker wrote: > > At the last IETF meeting I mentioned in the meeting that I had heard > rumors of SSH experts stating that using a host-key for authentication > of an initiating session was considered a bad thing and would be > frowned upon. Turns out, fortunately, that I was wrong. Though not > "desired", it is acceptable. Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Feb 06 19:38:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6GsU-0006PY-Op; Mon, 06 Feb 2006 19:38:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6GsT-0006OD-Pd for isms@megatron.ietf.org; Mon, 06 Feb 2006 19:38:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28978 for ; Mon, 6 Feb 2006 19:36:52 -0500 (EST) 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 1F6H4d-0005kS-NX for isms@ietf.org; Mon, 06 Feb 2006 19:51:15 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 06 Feb 2006 16:38:22 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k170cMKT014742 for ; Mon, 6 Feb 2006 16:38:22 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Feb 2006 16:44:57 -0800 Message-ID: <7210B31550AC934A8637D6619739CE690695D5DF@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: Issues AQ1 - AQ4 Thread-Index: AcYrfsulO/6hKXyaQgGq8bWjc9Kq2Q== From: "Salowey, Joe" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Isms] Issues AQ1 - AQ4 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 don't see why it should matter who acts as client and server as long as the entity has the credentials to act in that role. I also think Wes's notification scheme will work.=20 It seems that this really involves authorization. After SSH completes each side has authenticated the party at the other end of the conversation. An entity should be able to determine from the authenticated identity of its peer what it is authorized to send to the peer and what the peer is authorized to send to it. Whether the authenticated identity is a host or a user should not matter in most cases. As long as you have entries in your authorization system for your peer you can determine what the set of authorized interactions are. Where you may have issues is if there are multiple engines running with different authorizations on a host acting as an SSH server, but I think this is a corner case. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Feb 06 19:56:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6H9v-0003v6-KH; Mon, 06 Feb 2006 19:56:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6H9u-0003tf-Eo for isms@megatron.ietf.org; Mon, 06 Feb 2006 19:56:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00163 for ; Mon, 6 Feb 2006 19:54:49 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6HLz-0006Oa-IC for isms@ietf.org; Mon, 06 Feb 2006 20:09:12 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id D1BB04D6F5; Tue, 7 Feb 2006 01:56:12 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 05243-06; Tue, 7 Feb 2006 01:56:11 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) by hermes.iu-bremen.de (Postfix) with ESMTP id 4A5114D3DA; Tue, 7 Feb 2006 01:56:11 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 0A8E55E9275; Tue, 7 Feb 2006 01:56:09 +0100 (CET) Date: Tue, 7 Feb 2006 01:56:09 +0100 From: Juergen Schoenwaelder To: "Salowey, Joe" Subject: Re: [Isms] Issues AQ1 - AQ4 Message-ID: <20060207005609.GA3568@boskop.local> Mail-Followup-To: "Salowey, Joe" , isms@ietf.org References: <7210B31550AC934A8637D6619739CE690695D5DF@e2k-sea-xch2.sea-alpha.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7210B31550AC934A8637D6619739CE690695D5DF@e2k-sea-xch2.sea-alpha.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: 7d33c50f3756db14428398e2bdedd581 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Mon, Feb 06, 2006 at 04:44:57PM -0800, Salowey, Joe wrote: > I don't see why it should matter who acts as client and server as long > as the entity has the credentials to act in that role. I also think > Wes's notification scheme will work. [...] The problem boils down to which secrets you have to provision where and this seems operationally to be an issue. SNMPv3/USM requires to provision user identities and associated keys on all managed boxes and the operator feedback on this approach was quite negative. Many boxes these days have an ssh host key and are capable to out-source ssh user password authentication to AAA servers. We like to reuse that as much as possible/feasible. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Feb 06 20:56:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6I64-00069H-PH; Mon, 06 Feb 2006 20:56:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6I63-000690-0O for isms@megatron.ietf.org; Mon, 06 Feb 2006 20:56:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04972 for ; Mon, 6 Feb 2006 20:55:05 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6IIK-0000SX-Sj for isms@ietf.org; Mon, 06 Feb 2006 21:09:30 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 06 Feb 2006 17:56:37 -0800 X-IronPort-AV: i="4.02,93,1139212800"; d="scan'208"; a="1773986461:sNHT142336218" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k171uXjt003362; Mon, 6 Feb 2006 17:56:34 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Issues AQ1 - AQ4 Date: Mon, 6 Feb 2006 18:03:09 -0800 Message-ID: <7210B31550AC934A8637D6619739CE690695D620@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Isms] Issues AQ1 - AQ4 Thread-Index: AcYrgjs0RDpU0NWgTtCuPlUP8tBqcQAAFusA From: "Salowey, Joe" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org =20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 > Sent: Monday, February 06, 2006 4:56 PM > To: Salowey, Joe > Cc: isms@ietf.org > Subject: Re: [Isms] Issues AQ1 - AQ4 >=20 > On Mon, Feb 06, 2006 at 04:44:57PM -0800, Salowey, Joe wrote: >=20 > > I don't see why it should matter who acts as client and=20 > server as long > > as the entity has the credentials to act in that role. I also think > > Wes's notification scheme will work.=20 >=20 > [...] >=20 > The problem boils down to which secrets you have to provision where > and this seems operationally to be an issue. SNMPv3/USM requires to > provision user identities and associated keys on all managed boxes and > the operator feedback on this approach was quite negative. Many boxes > these days have an ssh host key and are capable to out-source ssh user > password authentication to AAA servers. We like to reuse that as much > as possible/feasible. >=20 [Joe] Yes, I agree. However it seems that we have the credentials to establish mutually authenticated connections in SSH. The problem is mapping the authenticated identity to its authorizations.=20 > /js >=20 > --=20 > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Feb 06 21:46:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6IsB-0006YT-Fj; Mon, 06 Feb 2006 21:46:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Is9-0006Wk-LL for isms@megatron.ietf.org; Mon, 06 Feb 2006 21:46:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08093 for ; Mon, 6 Feb 2006 21:44:40 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6J4K-000283-Oo for isms@ietf.org; Mon, 06 Feb 2006 21:59:05 -0500 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 <0IUA00AZNQJC5B@szxga01-in.huawei.com> for isms@ietf.org; Tue, 07 Feb 2006 10:50:00 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUA00BOKQJA0X@szxga01-in.huawei.com> for isms@ietf.org; Tue, 07 Feb 2006 10:50:00 +0800 (CST) Received: from m19684 ([10.111.12.90]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUA000MGQMU2K@szxml02-in.huawei.com>; Tue, 07 Feb 2006 10:52:06 +0800 (CST) Date: Tue, 07 Feb 2006 10:40:05 +0800 From: Miao Fuyou Subject: RE: [Isms] Issues AQ1 - AQ4 In-reply-to: <7210B31550AC934A8637D6619739CE690695D620@e2k-sea-xch2.sea-alpha.cisco.com> To: "'Salowey, Joe'" , j.schoenwaelder@iu-bremen.de Message-id: <000001c62b8f$cdd6ec50$5a0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 When notification originator initiates a connection as SSH client , it is authenticated by SSH authentication protocol with one of the three methods: public key, password and host-based. It is not good to use password authentication because username/password must be provisioned on managed host. But, it is very possible to apply host-based authentication in this case. Anyway the host already has host key when it works as command responder/SSH server, does it make sense to reuse host key for host-based authention? -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Salowey, Joe Sent: Tuesday, February 07, 2006 10:03 AM To: j.schoenwaelder@iu-bremen.de Cc: isms@ietf.org Subject: RE: [Isms] Issues AQ1 - AQ4 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Monday, February 06, 2006 4:56 PM > To: Salowey, Joe > Cc: isms@ietf.org > Subject: Re: [Isms] Issues AQ1 - AQ4 > > On Mon, Feb 06, 2006 at 04:44:57PM -0800, Salowey, Joe wrote: > > > I don't see why it should matter who acts as client and > server as long > > as the entity has the credentials to act in that role. I also think > > Wes's notification scheme will work. > > [...] > > The problem boils down to which secrets you have to provision where > and this seems operationally to be an issue. SNMPv3/USM requires to > provision user identities and associated keys on all managed boxes and > the operator feedback on this approach was quite negative. Many boxes > these days have an ssh host key and are capable to out-source ssh user > password authentication to AAA servers. We like to reuse that as much > as possible/feasible. > [Joe] Yes, I agree. However it seems that we have the credentials to establish mutually authenticated connections in SSH. The problem is mapping the authenticated identity to its authorizations. > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Feb 06 23:26:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6KRN-0004Lc-CQ; Mon, 06 Feb 2006 23:26:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6KRL-0004Ju-Tt for isms@megatron.ietf.org; Mon, 06 Feb 2006 23:26:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15951 for ; Mon, 6 Feb 2006 23:25:07 -0500 (EST) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6KdX-0005zP-3t for isms@ietf.org; Mon, 06 Feb 2006 23:39:32 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 229A8E0053; Mon, 6 Feb 2006 23:26:47 -0500 (EST) To: isms@ietf.org Subject: Re: [Isms] upcoming interim meeting and high level issue list References: <20060127101708.GA17064@boskop.local> From: Sam Hartman Date: Mon, 06 Feb 2006 23:26:47 -0500 In-Reply-To: <20060127101708.GA17064@boskop.local> (Juergen Schoenwaelder's message of "Fri, 27 Jan 2006 11:17:08 +0100") 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi. I just wanted to confirm that we have the small conference room. There was one scheduling conflict I don't think I will be able to resolve. The room is in use Monday afternoon from 1 to 2. Fortunately we'll be at lunch, so we won't care. Will we need a speaker phone for the room? Is anyone going to want to call in? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 07 03:02:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Nnz-0004KP-2m; Tue, 07 Feb 2006 03:02:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Nnx-0004IJ-DG for isms@megatron.ietf.org; Tue, 07 Feb 2006 03:02:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00828 for ; Tue, 7 Feb 2006 03:00:35 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6O06-00059q-6O for isms@ietf.org; Tue, 07 Feb 2006 03:15:03 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 79DB54D4E7; Tue, 7 Feb 2006 09:01:57 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 24290-06; Tue, 7 Feb 2006 09:01:56 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) by hermes.iu-bremen.de (Postfix) with ESMTP id E1F524D4A8; Tue, 7 Feb 2006 09:01:55 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 99EC45E9372; Tue, 7 Feb 2006 09:01:54 +0100 (CET) Date: Tue, 7 Feb 2006 09:01:54 +0100 From: Juergen Schoenwaelder To: "Salowey, Joe" Subject: Re: [Isms] Issues AQ1 - AQ4 Message-ID: <20060207080154.GB3772@boskop.local> Mail-Followup-To: "Salowey, Joe" , isms@ietf.org References: <7210B31550AC934A8637D6619739CE690695D620@e2k-sea-xch2.sea-alpha.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7210B31550AC934A8637D6619739CE690695D620@e2k-sea-xch2.sea-alpha.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: 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 Mon, Feb 06, 2006 at 06:03:09PM -0800, Salowey, Joe wrote: > [Joe] Yes, I agree. However it seems that we have the credentials to > establish mutually authenticated connections in SSH. The problem is > mapping the authenticated identity to its authorizations. For authorization to work in the SNMP architecture, all we need is a securityName. Typically, this is the authenticated identity or a mapping of it (there were lengthy discussions in the past on this list of the merrits and problems of mapping say an SSH user identity to a role name which is then used as the SNMP securityName - you may want to dig into the archives in case that is of interest). /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 Feb 07 09:25:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Tml-0005Ar-56; Tue, 07 Feb 2006 09:25:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Tmh-00059N-UV for isms@megatron.ietf.org; Tue, 07 Feb 2006 09:25:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29319 for ; Tue, 7 Feb 2006 09:23:44 -0500 (EST) 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 1F6Tyu-0001hp-9g for isms@ietf.org; Tue, 07 Feb 2006 09:38:15 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 39BA611D972; Tue, 7 Feb 2006 06:25:17 -0800 (PST) From: Wes Hardaker To: Sam Hartman Subject: Re: [Isms] upcoming interim meeting and high level issue list Organization: Sparta References: <20060127101708.GA17064@boskop.local> Date: Tue, 07 Feb 2006 06:25:17 -0800 In-Reply-To: (Sam Hartman's message of "Mon, 06 Feb 2006 23:26:47 -0500") 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: d17f825e43c9aed4fd65b7edddddec89 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Mon, 06 Feb 2006 23:26:47 -0500, Sam Hartman said: Sam> Will we need a speaker phone for the room? Is anyone going to want to Sam> call in? If there is the ability, I'd likely try for at least some of the time. I'm not going to be able to make it there physically... -- 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 Feb 07 14:46:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6YnG-00066z-Fa; Tue, 07 Feb 2006 14:46:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6YnD-00066W-HP for isms@megatron.ietf.org; Tue, 07 Feb 2006 14:46:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24433 for ; Tue, 7 Feb 2006 14:44:38 -0500 (EST) 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 1F6YzW-0004hN-M7 for isms@ietf.org; Tue, 07 Feb 2006 14:59:12 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 07 Feb 2006 11:46:09 -0800 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 k17Jk8WH007644; Tue, 7 Feb 2006 11:46:08 -0800 (PST) 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, 7 Feb 2006 11:46:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] upcoming interim meeting and high level issue list Date: Tue, 7 Feb 2006 11:46:04 -0800 Message-ID: <618694EF0B657246A4D55A97E38274C301368D5F@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] upcoming interim meeting and high level issue list Thread-Index: AcYrn1G+IJhFRGvZQtOidU39W+A6LAAeZpsA From: "Kaushik Narayan \(kaushik\)" To: "Sam Hartman" , X-OriginalArrivalTime: 07 Feb 2006 19:46:05.0494 (UTC) FILETIME=[22229D60:01C62C1F] X-Spam-Score: 2.2 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Sam, I will join atleast part of the meeting if a call-in were possible. regards, kaushik! -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Sam Hartman Sent: Monday, February 06, 2006 8:27 PM To: isms@ietf.org Subject: Re: [Isms] upcoming interim meeting and high level issue list Hi. I just wanted to confirm that we have the small conference room. There was one scheduling conflict I don't think I will be able to resolve. The room is in use Monday afternoon from 1 to 2. Fortunately we'll be at lunch, so we won't care. Will we need a speaker phone for the room? Is anyone going to want to call in? _______________________________________________ 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 Feb 09 18:50:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7LYI-000827-V6; Thu, 09 Feb 2006 18:50:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7LY3-0007xv-Pk; Thu, 09 Feb 2006 18:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19117; Thu, 9 Feb 2006 18:48:19 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7Lkw-0007Gj-Ch; Thu, 09 Feb 2006 19:03:22 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F7LY2-0001YG-2C; Thu, 09 Feb 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 09 Feb 2006 18:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-secshell-01.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Secure Shell Security Model for SNMP Author(s) : J. Salowey, D. Harrington Filename : draft-ietf-isms-secshell-01.txt Pages : 58 Date : 2006-2-9 This memo describes a Security Model for the Simple Network Management Protocol, using the Secure Shell protocol within a Transport Mapping. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isms-secshell-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isms-secshell-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-9164103.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-secshell-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-secshell-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-9164103.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@lists.ietf.org Thu Feb 09 19:12:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Lty-0003F7-1A; Thu, 09 Feb 2006 19:12:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Ltw-0003Di-T5 for isms@megatron.ietf.org; Thu, 09 Feb 2006 19:12:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21812 for ; Thu, 9 Feb 2006 19:10:48 -0500 (EST) Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7M6h-0008Op-9q for isms@ietf.org; Thu, 09 Feb 2006 19:25:52 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc14) with SMTP id <20060210001221m1400dg46le>; Fri, 10 Feb 2006 00:12:21 +0000 From: "David B Harrington" To: Subject: FW: [Isms] I-D ACTION:draft-ietf-isms-secshell-01.txt Date: Thu, 9 Feb 2006 19:12:17 -0500 Message-ID: <00a901c62dd6$a79db660$0600a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00AA_01C62DAC.BEC7AE60" X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYt1YNB3shwPlvDSM6z9fvdF4JwKQAAQnGA X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_00AA_01C62DAC.BEC7AE60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, A new revision of the secshell document has been published in preparation for the interim meeting. David Harrington dbharrington@comcast.net -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, February 09, 2006 6:50 PM To: i-d-announce@ietf.org Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-secshell-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Secure Shell Security Model for SNMP Author(s) : J. Salowey, D. Harrington Filename : draft-ietf-isms-secshell-01.txt Pages : 58 Date : 2006-2-9 This memo describes a Security Model for the Simple Network Management Protocol, using the Secure Shell protocol within a Transport Mapping. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isms-secshell-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isms-secshell-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_00AA_01C62DAC.BEC7AE60 Content-Type: Message/External-body; name="ATT00164.dat" Content-Disposition: attachment; filename="ATT00164.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2006-2-9164103.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-secshell-01.txt ------=_NextPart_000_00AA_01C62DAC.BEC7AE60 Content-Type: Message/External-body; name="draft-ietf-isms-secshell-01.txt" Content-Disposition: attachment; filename="draft-ietf-isms-secshell-01.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2006-2-9164103.I-D@ietf.org> ------=_NextPart_000_00AA_01C62DAC.BEC7AE60 Content-Type: text/plain; name="ATT00167.txt" Content-Disposition: attachment; filename="ATT00167.txt" Content-Transfer-Encoding: 7bit _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms ------=_NextPart_000_00AA_01C62DAC.BEC7AE60 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_00AA_01C62DAC.BEC7AE60-- From isms-bounces@lists.ietf.org Sat Feb 11 00:37:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7nS9-0002oM-5l; Sat, 11 Feb 2006 00:37:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7nS5-0002nb-Kr for isms@megatron.ietf.org; Sat, 11 Feb 2006 00:37:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10757 for ; Sat, 11 Feb 2006 00:35:51 -0500 (EST) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7nf3-00025K-Hq for isms@ietf.org; Sat, 11 Feb 2006 00:51:10 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 0F3DCE0053; Sat, 11 Feb 2006 00:37:27 -0500 (EST) To: Wes Hardaker Subject: Re: [Isms] upcoming interim meeting and high level issue list References: <20060127101708.GA17064@boskop.local> From: Sam Hartman Date: Sat, 11 Feb 2006 00:37:27 -0500 In-Reply-To: (Wes Hardaker's message of "Tue, 07 Feb 2006 06:25:17 -0800") 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: 01485d64dfa90b45a74269b3ca9d5574 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 have a speaker phone for the room. I don't have a conference bridge set up at this time though. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Feb 12 08:23:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8HBx-0007aV-3L; Sun, 12 Feb 2006 08:23:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8HBv-0007aQ-KZ for isms@megatron.ietf.org; Sun, 12 Feb 2006 08:23:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16871 for ; Sun, 12 Feb 2006 08:21:18 -0500 (EST) Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8HPL-0002cU-FG for isms@ietf.org; Sun, 12 Feb 2006 08:36:55 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc13) with SMTP id <20060212132253m1300rkinle>; Sun, 12 Feb 2006 13:22:53 +0000 From: "David B Harrington" To: "'Sam Hartman'" , "'Wes Hardaker'" Subject: RE: [Isms] upcoming interim meeting and high level issue list Date: Sun, 12 Feb 2006 08:22:38 -0500 Message-ID: <021001c62fd7$65774ff0$0600a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYuzYfop5d/u3y/RpSVdVj7kHPo6gBBuTIQ In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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, Would it be possible to have realt-ime MP3 recording/replay and jabber available? I don't know the technologies involved in the MP3 recording approach, so I personally don't know what would be involved in doing this. If somebody knows how to do this, and can advise me, I'll bring any equipment I have that might be helpful. I am of the impression that all the participants are important to the discussions, so I'm not sure how we could handle jabber scribing without impacting somebody's ability to participate. For those who are preparing presentations, can you send the presentations to the chairs so they can post the materials for others to access? My presentation is largely a rehash of RFC3411, done on easel paper rather than in powerpoint, so we can post them on the walls for reference. Therefore, I don't have any presentation to send in. But people not present can find most of the diagrams I am using in RFC3411. I'll try to mention where in RFC3411 to look, while I'm presenting. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Sam Hartman > Sent: Saturday, February 11, 2006 12:37 AM > To: Wes Hardaker > Cc: isms@ietf.org > Subject: Re: [Isms] upcoming interim meeting and high level issue list > > I have a speaker phone for the room. I don't have a conference bridge > set up at this time though. > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Feb 12 22:31:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8URN-0006aJ-0k; Sun, 12 Feb 2006 22:31:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8URK-0006aE-Jy for isms@megatron.ietf.org; Sun, 12 Feb 2006 22:31:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07116 for ; Sun, 12 Feb 2006 22:30:06 -0500 (EST) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F8Uer-0007gC-W4 for isms@ietf.org; Sun, 12 Feb 2006 22:45:50 -0500 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa11328; 12 Feb 2006 22:31 EST Date: Sun, 12 Feb 2006 22:31:21 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: To: "Salowey, Joe" Subject: Re: [Isms] Issues AQ1 - AQ4 In-Reply-To: <7210B31550AC934A8637D6619739CE690695D5DF@e2k-sea-xch2.sea-alpha.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org [ Sorry I've been silent for a while. This list seems to alternate between getting no traffic and getting traffic I don't see because my mailer isn't checking the mailbox for some reason. :-( ] On Mon, 6 Feb 2006, Salowey, Joe wrote: > I don't see why it should matter who acts as client and server as long > as the entity has the credentials to act in that role. I also think > Wes's notification scheme will work. So do I. I will note that NG->NR connections should not be on a fixed port allocated by IANA, but on a port specified when the notification is requested (perhaps with an IANA-assigned default/recommended port). This allows more than one user to run a management station on the same IP host. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Feb 13 10:46:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fuH-0003Ys-IW; Mon, 13 Feb 2006 10:46:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fuF-0003YF-J5 for isms@megatron.ietf.org; Mon, 13 Feb 2006 10:46:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02005 for ; Mon, 13 Feb 2006 10:44:42 -0500 (EST) 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 1F8g7s-0004nw-EC for isms@ietf.org; Mon, 13 Feb 2006 11:00:32 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 15C48E0079; Sun, 12 Feb 2006 21:52:20 -0500 (EST) To: Subject: Re: [Isms] upcoming interim meeting and high level issue list References: <021001c62fd7$65774ff0$0600a8c0@DJYXPY41> From: Sam Hartman Date: Sun, 12 Feb 2006 21:52:20 -0500 In-Reply-To: <021001c62fd7$65774ff0$0600a8c0@DJYXPY41> (David B. Harrington's message of "Sun, 12 Feb 2006 08:22:38 -0500") 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.4 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "David" == David B Harrington writes: David> Hi, Would it be possible to have realt-ime MP3 David> recording/replay and jabber available? David> I don't know the technologies involved in the MP3 recording David> approach, so I personally don't know what would be involved David> in doing this. If somebody knows how to do this, and can David> advise me, I'll bring any equipment I have that might be David> helpful. Setting up MP3s will be hard the first time. If people had brought this up earlier I would have attempted it. However I don't think I can pull it together tonight. and I don't want to try to get it working realtime in the meeting. We will have a speaker phone and we will have jabber. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Feb 13 10:46:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fuI-0003Zl-2k; Mon, 13 Feb 2006 10:46:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fuF-0003YK-SK for isms@megatron.ietf.org; Mon, 13 Feb 2006 10:46:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02000 for ; Mon, 13 Feb 2006 10:44:41 -0500 (EST) 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 1F8g7s-0004nu-E4 for isms@ietf.org; Mon, 13 Feb 2006 11:00:32 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 00304E008C; Mon, 13 Feb 2006 09:34:03 -0500 (EST) To: isms@ietf.org From: Sam Hartman Date: Mon, 13 Feb 2006 09:34:03 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Isms] Jabber for meeting 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. If you want to call into the meeting either join the jabber room isms@ietf.xmpp.org or send mail to the mailing list asking for contact info. For a variety of reasons joining the jabber room makes things much easier. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Feb 16 10:52:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9lR9-0000Du-Vx; Thu, 16 Feb 2006 10:52:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9lR9-0000DT-7J for isms@megatron.ietf.org; Thu, 16 Feb 2006 10:52:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06273 for ; Thu, 16 Feb 2006 10:51:06 -0500 (EST) Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9lfO-0002hx-JT for isms@ietf.org; Thu, 16 Feb 2006 11:07:38 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc14) with SMTP id <20060216155244m1400qn2g4e>; Thu, 16 Feb 2006 15:52:44 +0000 From: "David B Harrington" To: Date: Thu, 16 Feb 2006 10:52:40 -0500 Message-ID: <004b01c63311$04ccd070$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYzEQPb5nk1t0z5T/KFYqMVN2ojhA== X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] ISMS Interim summary by dbh 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, Here is my quick summary of the ISMS interim, for those interested. In general, it was an educational and brainstorming exercise rather than directed problem-solving. The chairs will presumably post the official summary and the minutes and the action items. We didn't provide any jabber capability, beyond naming a chat room, but we never picked a jabber scribe. Day One: The agenda called for four 10/15 minute intros to our areas of expertise. We spent about five hours doing the intros and answering questions related to the intros. The afternoon session was primarily about the RADIUS integration and what we needed to include in our request to RADEXT. The group favored an "authorization-only" extension to RADIUS, so authentication can be done using non-RADIUS means, such as Kerberos, and RADIUS can then be consulted for authorization purposes (with the conversation between the RADIUS client and server being something along the lines of "You've authenticated us as the RADIUS client; we've already had this user authenticated; trust us when we assert that he is authenticated. Now just tell us what he can do."). In addition, the group discussed making AAA integration an optional optimization that is used to populate access-control-model tables, in an implementation-dependent manner. This basically addresses issue RQ1. The WG should develop a document that describes such an optimization, using an example of VACM and an authorize-only RADIUS feature to populate the VACM userToGroup table. Day Two: As part of my intro to SNMPv3, I prepared easel pad drawings of the architecture (the block diagrams from 3411) and the scenario diagrams (also directly from rfc 3411) and parameter data flows, and hung these on the walls of the conference room. The parameter dat flows were represented as a spreadsheet of the ASIs and the parameters, which made it fairly easy to understand the data flows of the system. I plan to post this to the WG in a spreadsheet format. Most of the second day was spent walking through the ASI/data flows for command generation/response handling and we started on notiification origination/receipt data flows. This exercise helped to understand what information had to be available when, and, as we tried to determine how to pass data from SSH to SNMP or vice-versa, and what needs to be saved in the tmStateReference cache, and it also helped to bring out some differences in the semantics of terminology (principal, securityName, securityEngineID, etc.). During the afternoon, David Perkins and Wes had a list of specific things they wanted addressed, so we discussed those issues. Regarding other agenda items: We did not "confirm solutions" since we did that at IETF64. We need WG review of the SSHSM -01- document to confirm the solutions discussed at IETF64 and documented in -01-. We did not discuss session establishment and teardown, except incidentally. We discussed notifications to a degree during the walkthroughs, and in DavidP's concerns, but did not have enough time to finish the walkthrough, so really never had that discussion fully. We did not get into callback to any significant degree. 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 Thu Feb 16 10:57:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9lVe-0004yk-5o; Thu, 16 Feb 2006 10:57:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9lVd-0004xS-6z for isms@megatron.ietf.org; Thu, 16 Feb 2006 10:57:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06864 for ; Thu, 16 Feb 2006 10:55:44 -0500 (EST) Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9ljs-0002wM-4k for isms@ietf.org; Thu, 16 Feb 2006 11:12:17 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc14) with SMTP id <20060216155722m1400qk389e>; Thu, 16 Feb 2006 15:57:22 +0000 From: "David B Harrington" To: Date: Thu, 16 Feb 2006 10:57:17 -0500 Message-ID: <004c01c63311$aa0f2e20$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYzEaiyIoXH3xtXQZyaD1wLNiauaw== X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] WG review of the SSHSM -01- document 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 We need WG review of the SSHSM -01- document to confirm the solutions discussed at IETF64 and documented in -01-. It is not an onerous task to do this review, since a simple diff of -00- and -01- is pretty starightforward. It would help immensely to be able to take these issues off the table, so we can focus on the bigger issues identified by the chairs. Please make the time to review the -01- document and indicate your agreement or disagreement with the proposed solutions documented in -01-. Thanks, 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 Feb 20 12:04:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBESA-000698-Gm; Mon, 20 Feb 2006 12:04:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBESA-000693-1B for isms@ietf.org; Mon, 20 Feb 2006 12:04:02 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBES8-0005Mz-Nn for isms@ietf.org; Mon, 20 Feb 2006 12:04:02 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 630DF4D5CE for ; Mon, 20 Feb 2006 18:03:59 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 07482-05; Mon, 20 Feb 2006 18:03:57 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) by hermes.iu-bremen.de (Postfix) with ESMTP id C6DA34D3EB; Mon, 20 Feb 2006 18:03:57 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id C33A3602912; Mon, 20 Feb 2006 18:03:58 +0100 (CET) Date: Mon, 20 Feb 2006 18:03:58 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20060220170358.GA28468@boskop.local> Mail-Followup-To: isms@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Isms] draft meeting schedule at the dallas ietf X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, as of February 18, 2006, the DRAFT Agenda for IETF 65 has slotted the ISMS WG on Wednesday morning. This is, of course, subject to change. WEDNESDAY, March 22 2006 0800-0900 Continental Breakfast - 0900-1130 Morning Session I 2.5 hour APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG INT mipshop MIPv6 Signaling and Handoff Optimization WG RTG idr Inter-Domain Routing WG TSV tsvwg Transport Area Working Group SEC isms Integrated Security Model for SNMP WG /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 Feb 21 03:54:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBTIM-0007mb-A5; Tue, 21 Feb 2006 03:54:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBTIL-0007mT-0Y for isms@ietf.org; Tue, 21 Feb 2006 03:54:53 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBTII-0000x8-VQ for isms@ietf.org; Tue, 21 Feb 2006 03:54:52 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A77274CDFA for ; Tue, 21 Feb 2006 09:54:49 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 07405-07; Tue, 21 Feb 2006 09:54:47 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 05F354BFFC; Tue, 21 Feb 2006 09:54:47 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 54787603752; Tue, 21 Feb 2006 09:54:47 +0100 (CET) Date: Tue, 21 Feb 2006 09:54:46 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20060221085446.GA4761@boskop.local> Mail-Followup-To: isms@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline 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: 8e9fbe727bc2159b431d624c595c1eab Cc: Subject: [Isms] isms interim meeting minutes X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached please find the ISMS interim meeting minutes. The meeting was kind of a synchronization meeting between SSH people and SNMP people and helped to develop a common understanding of the problem space and the potential solution space. Please read the minutes and feel free to comment on any issues. It will be helpful if you send separate messages for each item you want to comment on. The subject line should identify the item you are commenting on. For example, if you want to comment on item g) in section 2.2., please use a subject line which contains "2.2.g)" so we can easily identify and separate the discussion threads. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="isms-interim-minutes.txt" ISMS Interim Meeting Minutes February 13/14 2006, MIT, Cambridge, MA Juergen Schoenwaelder (Scribe and Editor) Attendees: * David Harrington, Huawei [DH] * Sam Hartman, MIT [SH] * Jeffrey Hutzelman, CMU [JH] * David Nelson, Enterasys [DN] * Juergen Quittek, NEC [JQ] * David Perkins, SNMPinfo [DP] * Joe Salowey, Cisco [JA] * Juergen Schoenwaelder, International University Bremen [JS] * Margaret Wasserman, ThingMagic [MW] * Bert Wijnen, Lucent [BW] * Wes Hardacker, Sparta [WH] (via phone) 1. Summary of day #1: 1.1. Kickoff presentations: a) DH explained the core blocks of the SNMP architecture and how the ASIs glue them together. During the discussion, it became clear that in some cases the ASIs do not convey all information actually needed to make implementations work. b) JA explained the layers of the SSH architecture. He pointed out that some newer key-exchange mechanisms such as GSS-API are different from the widely used password and public-key authentication mechanisms in the sense that the claimed user identity might be different from the authenticated identity. c) DP walked through the logic which determines where to sent notifications and with which security parameters. The good news is that the procedure on the left hand side of his page do not need any changes to support SSHSM. All that is needed is to define a step 5d) which explains how to deliver a notification via SSHSM given the transport domain/address of the target, the security model/name/level triple and the context engineID/name pair, and the notification itself. d) DN explained the philosophy behind RADIUS and how RADIUS is typically integrated into applications. He pointed out that RADIUS is a "fascist" protocol - an applications passes a question to a RADIUS server and it provides a positive/negative decision which is to be followed (RADIUS is not a negotiation protocol). Hints are used in Accept-Request messages to tell the server which particular question is asked and the server passes attributes back in an Access-Accept message to be used by the requester. e) RADIUS, as currently defined and deployed, is about service provisioning, based on authenticated identity. It does not have the notion of a set of permissions, ACLs, etc, that are used during a login session to access various resources, as one might expect in a host OS. Of course, such a notion could be added, if required. 1.2. Requirements: a) SH stated that an SSHSM solution must support multiple key-exchange mechanisms to pass IESG review. b) There are legitimate reasons to out-source only authorization to RADIUS while authentication is handled by other mechanisms. A solution should not require that RADIUS authorization is always bound to RADIUS authentication. c) There are two types of notification originating programs - those bundled into an agent trying to do all steps on DP's page and those who short cut the whole left column and jump straight into the right column using information provided in an implementation specific manner. It is important to support both. 1.3. Directions: a) It is believed that the notion of an authoritative engineID is not needed within SSHSM. The authoritative engineID seems to be an USM specific detail, even though it is parsed into a security model as part of the generateRequestMsg() and generateResponseMsg() ASIs and out of a security as part of the processIncomingMsg() ASI. It seems the reason the authoritative engineID is passed out of the security subsystem is because, depending on the operation, the engineID needs to be compared to snmpEngineID (in 3412 7.2 13a). The MPM has knowledge of the Confirmed/Unconfirmed class of the operation, but the security model does not. b) It was agreed that RADIUS integration is not an integral part of SSHSM. SSHSM does not require RADIUS support as mandatory to implement. c) It will help SSHSM tremendously if RADIUS would support an authorize-only mechanism so that authentication exchanges and authorization exchanges can be separated. d) The RADIUS security name to group mapping authorization may be invoked by VACM (unfortunately the SNMP architecture has put the name to group mapping into the ACM rather than abstracting it out of the ACMs) and cause the respective VACM tables to be populated. In this case, there would be a timer which controls the lifetime of the authorization decision. The alternative would be to bind the authorization decision to the lifetime of a session (but this would then work only for session-based security models). e) It remains unclear whether it is desirable to be able to retrieve the contents of the vacmAccessTable via RADIUS or whether the security name to group name mapping is sufficient. Documentation of the best current practices of using VACM would be highly valuable and may help clarify whether regular updates on the vacmAccessTable are indeed needed to meet operational needs. The approach to be taken is to focus on security name to group name mapping as the first step. f) Authorization happens in three cases: (1) invocation of the SSHSM subsystem, (2) SSH identity to security name mapping, (3) security name to group name mapping. [ED: It seems that SSH does not have a notion of an abstract security name which is key-exchange mechanism agnostic which might mean that ISMS has to define for each mechanism how that maps to the SNMP security name and be extensible in this regard.] g) While the engineID is the primary way to identify SNMP engines in the architecture, applications and operators prefer to identity SNMP engines by their transport endpoints and rely on engineID discovery to make SNMPv3 work. SSHSM therefore must support engineID discovery. The snmpUnknownPDUHandlers report which is part of the SNMPv3 message processing does not help since it does not report the "correct" engineID in the response and it may not work in proxy situations (but note that USM discovery also relies on the assumption that the contextEngineID == securityEngineID). 2. Summary of day #2: 2.1. Terminology and Understanding After reviewing the results of the first meeting, we once again worked out common understandings of terminology. The engineID again caused confusion and we ended explaining it using the following model: engine engine engine | | | o <- engineID -> o <- engineID -> o | | | transport transport transport | | | o <- transport address -> o <- transport address -> o | | | +-------------------------+-------------------------+ The security engineID is hop-by-hop and used to bind security information (clock sync, key localization) while the context engineID is end-to-end used to identify the communicating peers across a proxy chain. DH explains that the engine ID has three usages: (1) snmpEngineID = "this" pointer - an ID for itself, so it can determine whether a passed engineID means "me" (2) securityEngineID = authoritative engine (3) contextEngineID = data source Sam talks about SSH and explains that SSH does not have ASIs and allows to use any additional information during the processing. Basically three things happen in SSH: things happen: 1) connect and authenticate the remote system using keyex method (the only input is effectively the hostname and the output is whether we are connected to the right system) 2) client chooses a user name he would like to act as and runs the user authentication process which is again very method specific; output is you are permitted as a user or not; internally there may be internal identities that may or may not be related to the user name (a string) 3) can i be that [...?] Generic identities: (1) reasonable to think clients identify servers by hostnames (ip addresses less likely, as a matter most clients do not include ports but they could very well) (2) servers identify clients by a user name 2.2. Walk through the ASIs for a CG <-> CR communication a) The notion of an SSH hostname may be different from IP addresses, DNS names, ... - so we need to define an SshTDomain and an SshTAddress which carries SSH hostnames. b) An SNMP engine must not allow to use the SSHSM over a non SshTDomain transport. c) There is a mapping between the SNMP security name and the SSH user name via the local data store and it might be the identity mapping. So far, we assume that the mapping happens in the TM portion of the SSHSM. d) The transport on the CR identifies the getpeername() endpoint of the CG, not the listening port of a CG. If the connection breaks during processing, the message is dropped since there is no way to establish a new session from the CR. e) Problem: In the security model, we do not have access to the transport address and thus we have a problem to identify the SSH session to lookup and the SSH user name. The proposed solution is to add an argument to the ASIs, the tmStateReference. (See also the TMSM document.) f) The SSHSM document currently does not explain how access to the SSHSM-TM happens via the tmStateReference. This needs to be explained. g) So far, we assume that the mapping of the SSH user name happens in the TM portion of the SSHSM as part of session establishment. h) There is a need to identify an SSH session, in particular, it is necessary that a response does not eventually go into a newly established session which happens to have the same transport address. In other words, we have to ensure that the response really goes to the same session the request came in. If the correct session has gone, the response message must be dropped. (Note that sessions may also go away if the periodic SSH rekeying fails.) i) Once back in the TM portion of the SSHSM, we use the session info provided by the tmStateReference to send the response (actually ignoring the transport address). j) The command generator will map back the SSH user name to the security name originally provided by the command generator. k) What is the lifetime of the tmStateReference? The session lifetime? Very likely. j) There was quite some discussion how the securityName provided when a CG calls sendPDU() will be cached and how it is pulled out of the cache later while processing the response. The issue is whether an engine that waits for a response (i.e., it hosts a CG) can process an unexpectedly received request by applying the cached securityName of the outstanding request. This clearly would jeopardize security. The specs need to be clear how to prevent this. 2.2. NO -> NR communication (NO establishes SSH session) a) A first attempt to untwist things: | SSH Client | SSH Server ---+-------------------+-------------------- CG | secName->userName \ (not allowed?) ---+-----------------. `------------------- CR | (?) \ userName->secName ---+-------------------+-------------------- NO | | ---+-------------------+-------------------- NR | | ---+-------------------+-------------------- b) It is very possible to have a CR and CG use the same system. How does the SNMP architecture figure out whether a stateReference applies to a given received message? [Homework to the SNMP geeks to figure this out.] c) WH reminds us that we should not be too strict about the architecture (which is just _an_ architecture) since most implementations are not following the architecture anyway and implementors will just make things work. d) WH prototyped SNMP over SSH. WH believes the authenticated engineID is a USM only concept (and the ASIs export it for no good reasons, probably they should instead have told the security subsystem what kind of communication happens so the security subsystem could have determined who is authoritative). e) DP believes that operationally you do not want to put any credentials on the notification originator, at least if the credentials are not localized. f) WH says that agents today do not have knowledge of hostkeys and leap-of-faith does not work for agents. In other words, agents must be properly configured with the relevant host keys. g) Is it not possible to give NOs the public keys they need for them to work? Not all host SSH key-exchange mechanisms use host keys. h) DP does not like this because we put credentials on the network devices. Passwords really are worrying, public keys may be less worrying. Note that the key pairs can and should be agent specific and thus a stolen devices is not as worrying. Still, if keys change, there is the usual key update problem. i) DP designs a table (SshUserTable): | hostName | userName | secName | pubKey | privKey .. +----------+----------+---------+--------+------------ | | | | | +----------+----------+---------+--------+------------ With that, a new step 5d) in his notification writeup will have the information to establish a session. Do we need a separate table for the hostkeys? j) SH suggests to have a table which maps an SSH transport address to a hostkey. k) OK, we have a solution where the NO establishes an SSH connection. Now lets see how we can work out how to send a notification over an already existing SSH connection. l) BW asks whether the configuration needed not puts us back to the beginning - do operators configure this? DNSSEC might be an option but DNSSEC is not widely deployed as of today. What needs to be configured: (a) add known host keys on agents, (b) put user keys on the agents. m) Simplification: There will be an identity mapping between security name and user name. The key pair will be the key that is used by the SSH host. With this approach, the only thing needed to be configured is the known host key. n) WH says to make sure that MIB tables allow for more flexibility. The original plan was to allow different key pairs everywhere, sharing the hostkey is just an optimization. o) WH asks whether it makes sense to introduce different security models for different user authentication mechanisms? The answer was no. p) It was questioned whether it is possible to define a generic SM portion of the TMSM which works with other TMSM? This remains unclear, but it is not unlikely that such a generic SM portion of arbitrary TMSMs may not work once the second TMSM pops up due to false assumption during the design. (This scepticism is to some extend driven by the insight that the SNMPv3 ASIs also prove "interesting" during the whole day.) q) The MIB module should provide a button to generate key pairs so that one can download a new public key from the MIB rather than having to upload a private key. It needs to be worked out how the change over to an updated key pair can work, that is when the old key expires (basically the next re-keying or session end). 2.4. NO -> NR communication (over established CG -> CR session) a) Started off with an interesting discussion about audit logs and the need in such use cases to keep an authenticated security name. This lead to a discussion which role the securityName plays in notifications and how access control is applied in this case. The key issue with the usage of an established session is that the source of the notification is not authenticated, unless one introduces security names such as "audit-from-front-door" and "audit-from-vault-door". b) When sending a message, SNMP authorizes depending on to whom you are sending to. SH does not agree with this approach, but can't explain the issues (two important issues, security and correctness). WH remarks that many notification receivers today do not distinguish how they handle received notifications with different security levels. c) JH proposed a set of rules and modifications to describe which connection I pick and to show that it is correctly authenticated. If I am sending a message, the identity I pick is one that I authenticated. If I pick a mapping, ensure that the protocol mapping on the other side is good. d) Notification case with NO established sessions (previous section) is more difficult because the message flow is similar but the NO likes to ensure that it is sending to a specific principal, which does not work with a hostkey which only proves the identity of the notification receiver server. Solution may require that after SSH startup we ask the NR server to proof that it can act as a particular principal. e) In other words, sending notifications via an existing CG-CR session actually gets the authentication of the receiver right as seen from the existing SNMPv3 architecture and the role of access control on notifications. This was a surprising insight. f) More work is needed to work out how the two scenarios can be made to work in order to provide SNMP authorization semantics in the case of notifications. 2.5 Wrap Up a) The meeting was closed at around 17:30. Sam did a great job in hosting the meeting. b) We made significant progress to understand the problem space and to find a common language between security experts and SNMP experts. Additional followup work is needed to work out the remaining details of the notification handling. 3. Action Items a) [Someone] to write down the RADIUS requirements in order to hand them over to the RADEXT WG. b) [SNMP] to check whether the securityEngineID is used outside of the security model and if so for what purpose. Answer: The securityEngineID is used in RFC 3412 section 7.2 13a) in the MPM. It is also referenced in RFC 3584. c) [DP] to work out the MIB design and to report what is wrong with the current draft. d) [DH] to revise the IDs and to submit new version before the cutoff deadline e) [ALL] name volunteers for the Radius integration document (to take care of a) above). DN volunteered to review the document and/or contribute text. f) [DN] to take the care of the RADIUS aspects of authorize-only. g) [JQ/JS] to send a formal request to RADEXT. h) [JQ/JS] to revise the milestones, at least the Dec 06 one. g) [JH] to proposed a set of rules of modifications to describe which connection I pick and to show that it is correctly authenticated. h) [JQ/JS] to organize an editing meeting at the next IETF (Sunday?) --azLHFNyN32YCQGCU 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 --azLHFNyN32YCQGCU-- From isms-bounces@lists.ietf.org Tue Feb 21 09:37:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBYeF-00012e-8s; Tue, 21 Feb 2006 09:37:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBJ2l-0006Iv-It for isms@ietf.org; Mon, 20 Feb 2006 16:58:07 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBJ2g-0007Ni-G4 for isms@ietf.org; Mon, 20 Feb 2006 16:58:07 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 854E54D0FC; Mon, 20 Feb 2006 22:58:01 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 01340-04; Mon, 20 Feb 2006 22:58:00 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) by hermes.iu-bremen.de (Postfix) with ESMTP id 0A8A24BF3C; Mon, 20 Feb 2006 22:57:57 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id BF93C6031A9; Mon, 20 Feb 2006 22:57:57 +0100 (CET) Date: Mon, 20 Feb 2006 22:57:57 +0100 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Isms] WG review of the SSHSM -01- document Message-ID: <20060220215757.GA29193@boskop.local> Mail-Followup-To: David B Harrington , isms@ietf.org References: <004c01c63311$aa0f2e20$0400a8c0@DJYXPY41> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline In-Reply-To: <004c01c63311$aa0f2e20$0400a8c0@DJYXPY41> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.2 (/) X-Scan-Signature: f7daabc75023870afa8ac625ca327d28 X-Mailman-Approved-At: Tue, 21 Feb 2006 09:37:50 -0500 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 16, 2006 at 10:57:17AM -0500, David B Harrington wrote: > We need WG review of the SSHSM -01- document to confirm the solutions > discussed at IETF64 and documented in -01-. David, I have completed my pass through the document. I have written some inline annotations/comments which you might take a look at while preparing the next revision. Note that some comments have been written before the interim and other after the interim, so they might not be always very consistent. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-ietf-isms-secshell-01-js.txt" Network Working Group D. Harrington Internet-Draft Effective Software Expires: August 12, 2006 J. Salowey Cisco Systems February 8, 2006 Secure Shell Security Model for SNMP draft-ietf-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 August 12, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo describes a Security Model for the Simple Network Management Protocol, using the Secure Shell protocol within a Transport Mapping. Harrington & Salowey Expires August 12, 2006 [Page 1] Internet-Draft Secure Shell Security Model for SNMP February 2006 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 . . . . . . . . . . . . . . . 12 2.1.4. Privacy Protocol . . . . . . . . . . . . . . . . . . . 12 2.1.5. Protection against Message Replay, Delay and Redirection . . . . . . . . . . . . . . . . . . . . . 12 2.1.6. Security Protocol Requirements . . . . . . . . . . . . 13 2.2. Security Parameter Passing Requirement . . . . . . . . . . 15 2.3. Requirements for Notifications . . . . . . . . . . . . . . 15 2.4. Scenario Diagrams . . . . . . . . . . . . . . . . . . . . 16 2.4.1. Command Generator or Notification Originator . . . . . 16 2.4.2. Command Responder . . . . . . . . . . . . . . . . . . 17 3. RFC 3411 Abstract Service Interfaces . . . . . . . . . . . . . 18 3.1. Public Abstract Service Interfaces . . . . . . . . . . . . 19 3.1.1. Public ASIs for Outgoing Messages . . . . . . . . . . 19 3.1.2. Public ASIs for Incoming Messages . . . . . . . . . . 21 3.2. Private Abstract Service Interfaces . . . . . . . . . . . 23 4. SNMP Messages Using this Security Model . . . . . . . . . . . 23 4.1. SNMPv1 and SNMPv2c Messages Using this Security Model . . 23 4.2. SNMPv3 Messages Using this Security Model . . . . . . . . 24 4.2.1. msgGlobalData . . . . . . . . . . . . . . . . . . . . 26 4.3. Passing Security Parameters . . . . . . . . . . . . . . . 27 4.3.1. Transport Session Parameters . . . . . . . . . . . . . 28 4.3.2. [discuss] Using Passwords to Authenticate SNMP Principals . . . . . . . . . . . . . . . . . . . . . . 29 4.3.3. [discuss] Using Public keys to Authenticate SNMP Principals . . . . . . . . . . . . . . . . . . . . . . 29 4.3.4. [discuss] Using Host-based Authentication of SNMP Principals . . . . . . . . . . . . . . . . . . . . . . 30 4.3.5. [discuss] Using RADIUS to Authenticate SNMP Principals . . . . . . . . . . . . . . . . . . . . . . 30 4.3.6. securityStateReference for SSHSM . . . . . . . . . . . 30 4.4. MIB Module for SSH Security Model . . . . . . . . . . . . 31 4.5. [todo] Notifications . . . . . . . . . . . . . . . . . . . 31 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 31 5.1. Establishing a Session . . . . . . . . . . . . . . . . . . 31 5.2. Closing a Session . . . . . . . . . . . . . . . . . . . . 34 5.3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 34 Harrington & Salowey Expires August 12, 2006 [Page 2] Internet-Draft Secure Shell Security Model for SNMP February 2006 5.4. Generating an Outgoing SNMP Message . . . . . . . . . . . 35 5.5. Sending an Outgoing SNMP Message to the Network . . . . . 37 5.6. [todo] Prepare Data Elements from an Incoming SNMP Message . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.7. Processing an Incoming SNMP Message . . . . . . . . . . . 38 6. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 7. Structure of the MIB Module . . . . . . . . . . . . . . . . . 41 8. MIB module definition . . . . . . . . . . . . . . . . . . . . 41 9. Security Considerations . . . . . . . . . . . . . . . . . . . 50 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 12.1. Normative References . . . . . . . . . . . . . . . . . . . 51 12.2. Informative References . . . . . . . . . . . . . . . . . . 52 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 53 A.1. Issues with Resolutions nearing Consensus . . . . . . . . 55 A.2. Closed Issues . . . . . . . . . . . . . . . . . . . . . . 55 Appendix B. Change Log from -00- . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 Intellectual Property and Copyright Statements . . . . . . . . . . 57 Harrington & Salowey Expires August 12, 2006 [Page 3] Internet-Draft Secure Shell Security Model for SNMP February 2006 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 [I-D.schoenw-snmp-tlsm], 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 [RFC4251]. 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 Harrington & Salowey Expires August 12, 2006 [Page 4] Internet-Draft Secure Shell Security Model for SNMP February 2006 existing security infrastructures, to ensure it could function when 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. . ** remove duplicated '.' The work will include the ability to use any of the user authentication methods described in "SSH Authentication Protocol" [RFC4252] - 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]. It should be able to take advantage of other defined authentication mechanism such as those defined in [I-D.ietf-secsh-gsskeyex] and future mechanism such as those that make use of X.509 certificate credentials. This will allow SSHSM to utilize user authentication and key exchange mechanisms which support different security infrastructures and provide different security properties. ** acronym SSHSM not yet defined 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 [I-D.ietf-netconf-prot]. Similar to NETCONF over SSH [I-D.ietf-netconf-ssh], this memo describes a method for invoking and running the SNMP protocol within a Secure Shell (SSH) session as an SSH subsystem. ** acronym CLI not yet defined This memo defines how SNMP can be used within a Secure Shell (SSH) session, using the SSH connection protocol [RFC4254] over the SSH transport protocol [RFC4253], using SSH user-auth [RFC4252]for authentication. Harrington & Salowey Expires August 12, 2006 [Page 5] Internet-Draft Secure Shell Security Model for SNMP February 2006 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. Sections requiring further editing are identified by [todo] markers in the text. Points requiring further WG research and discussion are identified by [discuss] 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 [[RFC4253] 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 [RFC4252] authenticates the client-side user to the server. It runs over the transport layer protocol. o The Connection Protocol [RFC4254] multiplexes the encrypted tunnel into several logical channels. It runs over the transport after succesfully authenticating the user. ** xml2rfc may be able to create better bulleted lists 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 & Salowey Expires August 12, 2006 [Page 6] Internet-Draft Secure Shell Security Model for SNMP February 2006 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, the security protocol and its underlying security mechanisms SHOULD NOT 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. ** this raises the question what the SNMP network management ** philosophy actually is; it is also unclear whether SSHSM ** ever can deliver 1. and 2. 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 Responder, 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. ** unclear what entity refers to in the last sentence; perhaps you ** should say 'SNMP enitty'. 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 Harrington & Salowey Expires August 12, 2006 [Page 7] Internet-Draft Secure Shell Security Model for SNMP February 2006 mapping security model instance encrypts outgoing messages, and the 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; Harrington & Salowey Expires August 12, 2006 [Page 8] Internet-Draft Secure Shell Security Model for SNMP February 2006 rather, it is the user on whose behalf the message was originated that is authenticated. SSH provides verification of the identity of the MIB owner through the SSH Transport Protocol server authentication [RFC4253] 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 [RFC4253] and mechanisms such as those described in [I-D.ietf- secsh-gsskeyex]. ** nit: " , " -> ", " 6. Disclosure - Provide, when necessary, that the contents of each received SNMP message are protected from disclosure to unauthorized persons.. ** nit: remove duplicate dot 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 [RFC4253]. This means that an SSH connection SHOULD provide 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 this case an implementation MUST still support data integrity within the SSH transport protocol. The security protocols used in [RFC4253] 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 & Salowey Expires August 12, 2006 [Page 9] Internet-Draft Secure Shell Security Model for SNMP February 2006 Implementations SHOULD support whatever authentications are provided by SSH. This includes anonymous access; if SSH supports anonymous access, and SSHSM can extract a username, then anonymous access SHOULD be supported. authNoPriv may be important to accommodate governmental regulation (e.g. export laws) regarding encryption technologies. ** "authNoPriv" -> "The authNoPriv security level" 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 according to the rules of the security model. ** Yes, do not phrase this as a question. A message is simply flagged ** with the security level. However, the algorithms used to achieve ** the security level should ideally be accessible via a management ** interface. Is there an SSH MIB? 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? ** Did we not previously agree that we treat an SSH session as ** authPriv and that we allow to ship SNMP messages with a lesser ** security level over such a session? 2.1.1.1.2. skipping public key verification 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). ** "you" style not consistent with the text so far. ** This raises again whether SSHSM should protect against ** mis-configurations and whether this ever can be done reliably. Harrington & Salowey Expires August 12, 2006 [Page 10] Internet-Draft Secure Shell Security Model for SNMP February 2006 2.1.1.1.3. the 'none' MAC algorithm SSH provides 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. SSH must not be configured using the "none" MAC algorithm for use with the SSHSM security model. ** I agree with the conclusion. Did we not agree that all these "what ** if the SSH system is mal-configured" issues should be simply ** mentioned and discussed in the security considerations section? In ** other words, we strongly suggest that certain possible but unusual ** SSH configurations are to be avoided. 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. ** "of RFC 3411 architecture" -> "of the SNMP architecture [RFC3411]" A session is associated with state information that is maintained for its lifetime. This state information allows for the application of various security services. Cryptographic keys established at the beginning of the session and stored in the session state can be used to authenticate and encrypt data that is communicated during the session. The cryptographic protocols used to establish keys for a session ensure that fresh new session keys are generated for each session. Since each session uses new session keys messages cannot be replayed from one session to another. In addition sequence information can be maintained in the session which can be used to prevent the replay and reordering of messages within a session. This document will discuss the impact of sessions on SNMP usage. [discuss] #3: we need some text contributed to discuss the implications of sessions on SNMP. ** The first question is whether sessions are specific to this TMSM or ** a general concept of TMSMs. This answers where the relevant text ** should go. Lets collect ideas what needs in this text: ** ** a) discussion of session establishment overhead ** b) discussion of session maintenance overhead (already in 2.1.2.1) ** c) outline apps profiles that will suffer from sessions ** d) outline apps profiles that will benefit from sessions 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 ** "authenticaiton/" -> "authentication /" Harrington & Salowey Expires August 12, 2006 [Page 11] Internet-Draft Secure Shell Security Model for SNMP February 2006 to read the messages. 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, 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. This includes the three authentication methods described in the SSH Authentication Protocol document - publickey, password, and host- based. 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 [RFC3588] 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 or Diameter. 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. GSSKeyex [I-D.ietf-secsh-gsskeyex] provides a framework for the addition of user authentication mechanisms which support different security infrastructures and provide different security properties. Additional authentication mechanisms, such as one that supports X.509 certificates, may be added to SSH in the future. 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 Harrington & Salowey Expires August 12, 2006 [Page 12] Internet-Draft Secure Shell Security Model for SNMP February 2006 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 delay the transmission of all packets from a particular point in a session since SSH protects the ordering of packets. 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 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 includes a discussion of the operational expectations of this model for use in troubleshooting a broken network.[discuss] #4: Should the SSHSM document include a discussion of the operational expectations of this model for use in troubleshooting a broken network, or can this be covered in the TMSM document? ** I think it is fair to say something. Perhaps along the lines that ** SSHSM will likely not work in conditions where access to the CLI ** has stopped working and that in situations where SNMP access has to ** work when the CLI has stopped working, the use of USM should be ** considered instead of SSHSM. 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. [discuss] #5: Should the SSHSM document include a discussion of ways SNMP could be extended to better support management/monitoring needs when a network is running just fine, or can this be covered in the TMSM document, or in an applicability document? ** I think we are leaving the scope of this document if we start ** discussing how to improve SNMP once you have less strict message ** size constraints. If at all, we might suggest that applications ** utilizing SSHSM may want to take advantage of the increased message ** sizes (where are they defined?) by sending larger requests and ** utilizing existing SNMP operations (e.g. getbulk) effectively. Harrington & Salowey Expires August 12, 2006 [Page 13] Internet-Draft Secure Shell Security Model for SNMP February 2006 The Secure Shell security model can coexist with the USM security model, the only other currently defined security model. [discuss] #6: Are there are any wrinkles to coexistence with SNMPv1/v2c/USM? 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, 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. [discuss] #7: 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? ** Ideally, we can do away with securityEngineID. The only thing where ** we have to check would be proxy situations where an SSHSM happens ** within a proxy chain. Do we really have to deal with proxies? This ** always hurst me so much... ;-) Harrington & Salowey Expires August 12, 2006 [Page 14] Internet-Draft Secure Shell Security Model for SNMP February 2006 2.2. Security Parameter Passing Requirement SSHSM follows the TMSM approach, in which the security-model has two separate areas of security procoessing - the TMSP performs transport- mapping-related security processing, and the MPSP performs security processing within the security model subsystem of the messaging model (MPSP). specific parameters for an incoming message can be determined from the transport layer by the transport mapping security procoessing (TMSP), before the message processing begins, and for outgping messages, the security-model-specific parameters are gathered by the messaging-security-processing (MPSP) and passed with the outgoing message to the transport mapping. ** "(MPSP). specific" -> ". Specific" ** Even with this change, the style looks a bit odd since acronyms are ** explained after talking about them. For outgoing messages, the MPSP portion of the security model creates the WholeMsg from its component parts. In the SSHSM model, an SNMPv3 message is built without any content in the SecurityParameters field of the message, and the WholeMsg is passed unencrypted back to the Message Processing Model for forwarding to the Transport Mapping. The MPSP takes input provided by the SNMP application, converts that information into suitable security parameters for SSHSM, and passes these in a cache referenced by tmStateReference to the TMSP (via the dispatcher). The TMSP establishes sessions as needed and passes messages to the SSH subsystem for processing. For incoming messages, the TMSP accepts (decrypted) messages from the SSH subsystem, and records the transport-related information and the security-related information, including authenticated identity, in a cache referenced by tmStateReference, and passes the WholeMsg and the tmStateReference to the MPSP (via the dispatcher). The cache reference could be thought of as an additional parameter in the ASIs between the transport mapping and the messaging security model. 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 SSH connections may be initiated by command generators or by notification originators. Command generators are frequently operated by a human, but notification originators frequently are unmanned automated processes. As a result, it will be necessary to provision authentication credentials on the SNMP engine containing the notification originator so it can successfully authenticate to an engine containing a notification receiver. Harrington & Salowey Expires August 12, 2006 [Page 15] Internet-Draft Secure Shell Security Model for SNMP February 2006 [discuss] #9: Can an existing R/R session be reused for notifications? ** I hope so. In fact, I like to a procedure where a CG can connect to ** a CR and configure the NO to send notifications to the NR over the ** same SSH session used by the CG and CR. (A subscription if you ** want.) The only issue I see is that the target configuration ** should] be marked dynamic so that there is an automatic cleanup if ** the session goes away (can be session bound or soft state / timer ** based. A timer solution would allow me to use this also for other ** non-session based security models). There is some text in Appendix A in RFC 3430 [RFC3430]which captured 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. ** ".In" -> ". In" ** "4.61" -> "4.6.1" 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 & Salowey Expires August 12, 2006 [Page 16] Internet-Draft Secure Shell Security Model for SNMP February 2006 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 Response is (asynchronously) send back to the network. Harrington & Salowey Expires August 12, 2006 [Page 17] Internet-Draft Secure Shell Security Model for SNMP February 2006 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 | | 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 Harrington & Salowey Expires August 12, 2006 [Page 18] Internet-Draft Secure Shell Security Model for SNMP February 2006 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 = -- 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 & Salowey Expires August 12, 2006 [Page 19] Internet-Draft Secure Shell Security Model for SNMP February 2006 statusInformation = -- 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 = -- 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 & Salowey Expires August 12, 2006 [Page 20] Internet-Draft Secure Shell Security Model for SNMP February 2006 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 hsecurityStateReference as 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. ** I skipped over this. But this list really needs to be nicer ** formatted and carefully checked. 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 & Salowey Expires August 12, 2006 [Page 21] Internet-Draft Secure Shell Security Model for SNMP February 2006 result = -- 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 = -- 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 Harrington & Salowey Expires August 12, 2006 [Page 22] Internet-Draft Secure Shell Security Model for SNMP February 2006 3.2. Private Abstract Service Interfaces A set of abstract service interfaces have been defined within this 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 = 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 ) ** Why is the securityEngineID needed? ** Do we need a private ASI for closing a session? 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. 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. ** "authpriv" -> "authPriv" The communitystring is not used as an authentication mechansism, ** "communitystring" -> "community string" ** Is it politically correct to explain how historic protocols work ** with SSHSM? Harrington & Salowey Expires August 12, 2006 [Page 23] Internet-Draft Secure Shell Security Model for SNMP February 2006 since user authentication is provided by SSH userauth. The community string is still used to provide context information. ** I think we should say clearly that the community string is not ** touched and just shipped opaquely. It is common that people use ** public@context to refer to a specific context and I would prefer to ** not mess around with that. However, you are saying that with SSHSM, ** the access control is based on the user identity and not on the ** community string anymore. OK, why is it then useful to have all ** this? Is SSHSM not a new security model and thus it requires to ** have SNMPv3/SSHSM in place to use it? In fact, doing SNMPv3/SSHSM ** for SNMPv1 legacy apps should be simple to do since you have to ** deal with the new transport and everything else is rather simple ** (no discovery, clock synchronization, ...). 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, and where implemented by the agent, the snmpEngineID at the IP address can be learned by querying the device with a GET request. ** I think this document should just define SNMPv3/SSHSM and not spell ** out SNMPv1/SNMP2c to SNMPv3/SSHSM transition. I believe this ** transition is important to make easy during the design, but we ** should not write things down here (or rather explain this in a ** separate memo once we know implementations better). 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. [discuss] #10: which securityparameters must be supported for the SSHSM model, and why? Which services provided in USM are needed in TMSM/SSHSM? How does the Message Processing model provides this information to the security model via generateRequestMsg() and processIncomingMsg() primitives? ** Did we not conclude that we do not need any security specific ** information in the messages? The SNMPv3Message SEQUENCE is defined in [RFC3412]. The following fields are specific to the Secure Shell Security Model: Harrington & Salowey Expires August 12, 2006 [Page 24] Internet-Draft Secure Shell Security Model for SNMP February 2006 SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN SNMPv3Message ::= 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 ::= 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 ::= CHOICE { plaintext ScopedPDU, encryptedPDU OCTET STRING -- encrypted scopedPDU value } ScopedPDU ::= SEQUENCE { contextEngineID OCTET STRING, contextName OCTET STRING, data ANY -- e.g., PDUs as defined in [RFC3416] } END Harrington & Salowey Expires August 12, 2006 [Page 25] Internet-Draft Secure Shell Security Model for SNMP February 2006 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] #11: If we eliminate all msgSecurityParameters, should the msgSecurityParameters field in the SNMPv3 message simply be a zero-length OCTET STRING, or should it be an ASN.1 NULL? 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 ::= BEGIN SSHsmSecurityParameters ::= SEQUENCE { OCTET STRING } END ** Is it stated somewhere that msgSecurityParameters must contain ** valid ASN1/BER serialization? If yes, we should define the ** SSHsmSecurityParameters to be an ASN.1 NULL. Otherwise, we might ** indeed go with at zero-length msgSecurityParameters field. I think ** RFC 3412 section 6.6 actually allows for a zero-length OCTET ** STRING. 4.2.1.2. msgFlags 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. [discuss: #12: how does SSHSM determine whether SSH can provide the security services requested in msgFlags? ] [discuss] There were discussions about whether it was acceptable for a transport-mapping-model to provide stronger security than requested. Does this need to be discussed in the SSHSM document, or should we discuss this in the TMSM document? when sending a message into an environment where encryption is not legal, how do we ensure Harrington & Salowey Expires August 12, 2006 [Page 26] Internet-Draft Secure Shell Security Model for SNMP February 2006 that encryption is not provided? ** I think most of the discuss above can be dropped since the text ** below mostly has the answer. 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 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. ** Is it realistic to check from the SNMP stack what the SSH did? I ** mean, we should be careful to not require something that makes ** implementations impossible (without cheating). 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. ** Question: Assume an SNMP engine receives a request and the SSH ** connection goes away before the response can be returned, will it ** be fine to just drop the response? (I hope so.) tmStateReference is used to pass model- and mechanism-specific parameters to coordinate the session-related activities and specific message pair processing between the TMSP and MPSP. The SSHSM has the responsibility for explicitly releasing the complete tmStateReference when the session is destroyed. The SSHSM has the responsibility for releasing the message-specific parameters in the tmStateReference once a response message has been sent, or the data is no longer needed. ** "tmStateReference" -> "The tmStateReference" The MPSP translates select parameters from the tmStateReference cache into model-independent parameters subsequently passed in the securityStateReference cache to a Message Processing Model. The Harrington & Salowey Expires August 12, 2006 [Page 27] Internet-Draft Secure Shell Security Model for SNMP February 2006 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." SSH does not require that a session be maintained nor that it be closed when the keys associated with the host or client associated with the session are changed. Some SSH implementations may close an existing session if the keys associated with the session change. For SSHSM, if the session is closed between the time a Request is received and a Response message is being prepared, then the Response should be discarded. ** I think we concluded that changed keys will cause the SSH session ** to go away when the next rekeying happens. (At least this is what I ** understood.) So perhaps this should be rephrased to make things ** clearer. 4.3.1. Transport Session Parameters SSHSM will create a session between the TMSM of one SNMP entity and the TMSM of another SNMP entity. The created SSH "tunnel" MUST provide authentication of the client and server, and MUST integrity- check and encrypt the messages. Upon establishment of an SSH session, the TMSP will cache the transport parameters in the tmStateReference for subsequent usage. This information should be stored in a local datastore. The tmStateReference cache for use with the SSH Authentication Protocol [RFC4252] will include the following transport-related information: [discuss] #15: What data needs to be stored in the tmStateReference, and how does SSHSM get the information from SSH, for the various authentication and transport options? tmSessionID = a unique local identifier tmTransportDomain = TCP/IPv4 tmTransportAddress = x.x.x.x:y tmSecurityModel - SSHSM tmSecurityLevel = "authPriv" tmPrivProtocol = from the SSH session parameters tmSSHKeyExchangeProtocol for authenticating the server ** I think we agreed that we have to introduce a new TDomain (perhaps ** even two for IPv4/IP6?) which somehow refers to hostnames. I am ** actually not sure since somehow this also needs to resolve to a ** transport endpoint. Additional information will be added to the tmStateReference by the authentication portion of the SSHSM. [discuss] #16B: Passing a securityname might be useful for passing as a hint to RADIUS or other authorization mechanism to indicate which identity we want to use when doing access control, and RADIUS,etc. can tell us whether the username being authenticated is allowed to be mapped to that authorization/accounting identity. Should we provide Harrington & Salowey Expires August 12, 2006 [Page 28] Internet-Draft Secure Shell Security Model for SNMP February 2006 securityname when establishing a session, so the authentication machanisms can use it as a hint? ** I would say that the SSH user name belongs into this state as it is ** difficult to access it from upper layers. Whether we want a mapping ** here which is more elaborate than identity mapping, I am not sure ** yet. 4.3.1.1. Authenticating Servers and Clients tmSecurityName = the user name authenticated by SSH I think we better call it user name in the context of SSH to avoid confusion. tmSecurityName is the name that has been successfully authenticated by SSH, from the user name field of the SSH_MSG_USERAUTH_REQUEST message. How this data is extracted from the SSH environment to put into the SNMP environment is implementation-dependent. [todo] #18: I currently have multiple sections, one for each known auth mechanism. We need to discuss the parameters that need to be cached for each. Once we are complete, I will collapse this into one section. 4.3.2. [discuss] Using Passwords to Authenticate SNMP Principals Upon creation of a SSH session, the TMSP will cache the session authentication information in the tmStateReference: tmUserName is the name extracted from the user name field of the SSH_MSG_USERAUTH_REQUEST message, after authentication has completed successfully. tmSecurityName is the name extracted from the user name field of the SSH_MSG_USERAUTH_REQUEST message, after authentication has completed successfully. ** what is the difference between tmUserName and tmSecurityName? tmAuthMechanism = "password" tmAuthProtocol = "password" tmSecurityLevel = appropriate choice from SnmpSecurityLevel tmAuthzData = "[todo] authorization data obtained during the exchange" 4.3.3. [discuss] Using Public keys to Authenticate SNMP Principals Upon creation of a SSH session, the TMSP will cache the session authentication information in the tmStateReference: tmSecurityName is the name extracted from the user name field of the SSH_MSG_USERAUTH_REQUEST message tmAuthMechanism = "publickey" tmAuthProtocol = public key algorithm name tmSecurityLevel = appropriate choice from SnmpSecurityLevel tmAuthzData = "[todo] authorization data obtained during the exchange" Harrington & Salowey Expires August 12, 2006 [Page 29] Internet-Draft Secure Shell Security Model for SNMP February 2006 4.3.4. [discuss] Using Host-based Authentication of SNMP Principals Upon creation of a SSH session, the TMSP will cache the session authentication information in the tmStateReference: tmSecurityName is the name used in user name field of the SSH_MSG_USERAUTH_REQUEST message tmAuthMechanism = "hostbased" tmAuthProtocol = public key algorithm for host key tmSecurityLevel = appropriate choice from SnmpSecurityLevel tmAuthzData = "[todo] authorization data obtained during the exchange" 4.3.5. [discuss] Using RADIUS to Authenticate SNMP Principals In general, if RADIUS is being used by an ssh implementation, here is how it works. The SSH implementation will use password auth (or keyboard interactive) over the wire between the client and server. The server will turn this into a RADIUS authentication request. The server may later get RADIUS authorization information ( for example, to confirm that the session is allowed at the current time). SSHSM SHOULD use RADIUS Digest for authentication for security reasons. Implementations MAY however choose to use RADIUS PAP to support additional backend authentication systems such as Active Directory and Token Servers. Upon creation of a SSH session, the TMSP will cache the session authentication information in the tmStateReference: tmSecurityName is the name used in username field of the RADIUS ACCESS-REQUEST message. tmAuthMechanism = "" tmAuthProtocol = RADIUS tmRadiusServer = x.x.x.x:y tmSecurityLevel = appropriate choice from SnmpSecurityLevel tmAuthzData = "[todo] authorization data obtained during the exchange" ** I think 4.3.5 should go away and be moved into the RADIUS document. ** From the SSHSM perspective, the question whether RADIUS is involved ** or not for authentication should be irrelevant. 4.3.6. securityStateReference for SSHSM The parameters associated with an incoming request message to be applied to the outgoing response. messageProcessingModel = SNMPv3 securityModel = SSHSM sessionID = tmSessionID ** I think we agreed in Boston that the sessionID belongs into the ** tmStateReference as well so that we can ensure messages really go ** to the right session. Harrington & Salowey Expires August 12, 2006 [Page 30] Internet-Draft Secure Shell Security Model for SNMP February 2006 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. [todo] the mapping from model-specific identity to a model independent securityName for storage in an LCD is implementation- dependent. This is Implementation-dependent, both in the case of extracting tmSecurityname from SSH for an incoming message, and for providing an LCD mapping. [todo] Module needs to be worked out once things become stable... 4.5. [todo] Notifications For notifications, if no session has yet been created, or the session has been closed, then the TMSP will establish a session and populate the cache for subsequent usage. [discuss] #21: we need to determine what data should be persistent and stored in the LCD for notification purposes. 5. Elements of Procedure 5.1. Establishing a Session The Secure Shell Security Model provides the following primitive to pass data back and forth between the Transport Mapping portion of the Security Model and the SSH service: statusInformation = establishSession( IN destTransportDomain -- transport domain to be used IN destTransportAddress -- 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 IN subsystem OUT sessionID ) Harrington & Salowey Expires August 12, 2006 [Page 31] Internet-Draft Secure Shell Security Model for SNMP February 2006 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 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 transportDomain and transportAddress are saved. If the attempt to establish a connection is unsuccessful, then an error indication [todo] will be returned, and [todo] processing stops. [discuss] #22: There are a significant number of security problems associated with mapping to a transport address which may need to be discussed in the security considerations section. 4) The provided securityEngineID and securityName and securityLevel are used to lookup the associated entry in the Local Configuration Datastore (LCD), and the model-specific information concerning the principal at the destination is extracted. This step allows preconfiguration of model-specific principals mapped to the engine/ name/level, for example, for sending notifications using host-only authentication. Set the username in the SSH_MSG_USERAUTH_REQUEST to the username extracted from the LCD. Harrington & Salowey Expires August 12, 2006 [Page 32] Internet-Draft Secure Shell Security Model for SNMP February 2006 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 [RFC4252]. 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 [RFC4254]. 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. ** We need to define somewhere what the max message size is that needs ** to be supported over the SSH transport. RFC 3430 says in 2.2 that ** implementations have to support 8192 octets... 9) If successful, this will result in an SSH session. The 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) 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. Once the SSH session has been established, the SNMP engine will invoke SNMP as an SSH subsystem, as indicated in the "subsystem" parameter. 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. Harrington & Salowey Expires August 12, 2006 [Page 33] Internet-Draft Secure Shell Security Model for SNMP February 2006 [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 in the tmStateReference? ** The problem is that the agent won't respond to a GET if you do not ** have the proper engineID. So I think we need a discovery procedure ** which is based on reports. 11) [todo] the engine will perform an SNMP GET command requesting the value of the remote engine's snmpEngineID object, and create a tmStateReference cache recording the following information: the remote engine's snmpEngineID the transport address the recipient and sender channels 5.2. Closing a Session The Secure Shell Security Model provides the following primitive to pass data back and forth between the Security Model and the SSH service: statusInformation = closeSession( IN sessionID ) The following describes the procedure to follow to close a session between a client and sever to run SNMP over SSH. This process is followed by any SNMP engine closing the corresponding SNMP session. The Secure Shell Security Model identifies which session should be closed to the SSH client code, using the closeSession() ASI. [discuss] #23: We need to discuss the circumstances under which a session should be closed, and how an SNMP engine should determine if, and respond if the SSH session is closed by other means. ** I think will be determined in an implementation specific manner ** when session will be closed, to allow some session caching. Only ** during failure situations, we can be precise when to close the ** connection (e.g. after an ASN1/BER parse error) 5.3. 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). Harrington & Salowey Expires August 12, 2006 [Page 34] Internet-Draft Secure Shell Security Model for SNMP February 2006 [discuss] #24: How should we enable auto-discovery? 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)? 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. ** I think the answer is SNMPv1. This is how discovery in general ** happens these days. I think the goals of user authentication and ** discovery do not match well. I think DP wanted anonymous access for ** exactly these reasons and it was kind of rejected or at least not ** loved much. ** We surely need to provide for engineID discovery since SNMPv3 needs ** a contextEngineID to work and most systems to not keep track of ** these identifiers since they rely on USM discovery. General SNMP ** discovery I think is not our problem to solve. 5.4. 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 = -- 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 & Salowey Expires August 12, 2006 [Page 35] Internet-Draft Secure Shell Security Model for SNMP February 2006 statusInformation = -- 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 ) 1) verify securityModel = sshsmSecurityModel determine whether we need to use the SSH subsystem for Request/ Responses ("SNMP"), or for Notifications ("SNMPNotification") or Reports. [discuss] #34 - how do we determine this? [discuss] #35 - which subsystem is used for Reports? ** Reports are a reaction to a previously received message and thus ** they go wherever the previous message triggering the report came ** from. 2) If there is a securityStateReference, extract the tmStateReference information from the cachedSecurityData from the Request message. At this point, the cachedSecurityData can now be discarded. [todo] clarify which data can be discarded. 2b) [todo] #13 - If the message is a Response, and a session never existed or has been closed, or the Request/Response subsystem never existed or was closed, then discard the message, and generate a Report 3) If there is no securityStateReference, then lookup the session info indexed by {securityEngineID, securityName, securityLevel, subsystem}, and set tmStateReference. [todo] insert check for msgflags versus session/transport characterstics here, and in the transport-mapping portion. ** Where does the subsystem come from? Do we really want to use the ** securityEngineID here? 4) 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. ** See above: we really use the securityEngineID? 5) fill in securityParameters with a NULL octet string. [todo] we don't need to send securityEngineID, unless it is needed for a discovery mechanism.. Harrington & Salowey Expires August 12, 2006 [Page 36] Internet-Draft Secure Shell Security Model for SNMP February 2006 [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() ** Not sure what a NULL octet string is. Are you saying it is an OCTET ** STRING which contains the serialization of the ASN.1 NULL value? 6) The wholeMsg is now serialized and then represents the unauthenticated message being prepared. 7) 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. ** See above on "NULL octet string". The Message Processing Model then passes information to the disptacher for forwarding to the Transport Mapping. 5.5. Sending an Outgoing SNMP Message to the Network The TMSP portion of the Secure Shell Security Model performs the following tasks: 8) Uses tmStateReference to lookup session information. 9) [todo] verifies that auth and priv can be provided, as requested, and error-out if not. [todo] insert check for msgflags versus session/transport characterstics here. 10) 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. [discuss] #25: Where is the best place to call establishSession()? Note that the whole message is completely put together within the message-processing portion of the security model, in the hopes that a session will be able to be established when the message gets to the transport mapping portion of the architecture. It is done this way because the RFC3411 arcitecture doesn't pass the transport addressing info into the security model via messaging model. It would seem a much more efficient approach to verify that the session can be established, while still in the security model portion of the messaging model. If we don't establish the session until we get to the transport mapping, we've done a lot of work for nothing. And thus far, there is no place to record failed attempts to establish a session, so an engine doesn't learn to not try to open a session. In an environment where the SNMP engine might be a daemon used by multiple applications, an attacker could use this to cause a denial of service attack at the NMS. This would likely occur on the NMS side. I don't know if there's any way to cause it to happen on the agent side. I Harrington & Salowey Expires August 12, 2006 [Page 37] Internet-Draft Secure Shell Security Model for SNMP February 2006 suppose a rogue agent with callhome functionality might be able to cause a denial of service for an NMS by repeatedly requesting callhome and then refusing the connections.. ** While I share your concerns of doing the actual session setup late, ** I believe nobody is going to implement the architecture in such a ** way. Regarding statistics: We should probably provide some counters ** to track failed session establishments, especially if we allow ** traditional SNMP agents to establish sessions. 11) An SSH_MSG_CHANNEL_DATA message is sent, indicating the recipient channel and encapsulating the wholeMessage. [discuss] #26: 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). ** tmStateReference. [discuss] #27: 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. Do we need to discuss these issues? Where? in the security considerations? ** Do you think this is a security concern? I guess we also need a ** section "Implementation Considerations" where we point out things ** like keeping a cache of open connections, doing session ** establishment early and to save processing if session establishment ** fails, ... [discuss] #28: For notification tables, how do we predefine the dynamic session identifiers? 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). ** We can't answer this in detail before we know how notifications ** really work. 5.6. [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.7. 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, and if state information is available when a session is closed, the session state Harrington & Salowey Expires August 12, 2006 [Page 38] Internet-Draft Secure Shell Security Model for SNMP February 2006 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. ** persistent session state information?? The abstract service primitive from a Message Processing Model to the Security Subsystem for a received message is:: statusInformation = -- 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 , then the snmpInASNParseErrs counter [RFC3418] is incremented, and an error indication (parseError) is returned to the calling module. 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. [discuss] #29: do we need to support reports? This was important for USM, but much less so for SSHSM, since we don't need to synchronize clocks and report other USM-specific issues, and we may not need it for discovery either. ** I think we need reports for contextEngineID discovery, even though ** this has nothing to do with security, but it is a common use of USM ** engineID discovery. [todo] check whether this field parses correctly and report errors through Reports 2) The SSHSM queries the associated SSH engine, in an implementation- dependent manner, to determine the transport and security parameters for the received message: Harrington & Salowey Expires August 12, 2006 [Page 39] Internet-Draft Secure Shell Security Model for SNMP February 2006 a) the transportDomain and transportAddress b) tmSecurityName - an identifier for the authenticated entity c) whether authentication is on or off, d) whether encryption is on or off, e) integrity-checking options [todo] we only need the authentication options and the encryption and integrity-checking options, to verify that SSH is providing the expected services, and didn't use "none" for any of these services. If we can simply assume those services have always been provided adequately without checking, then we only need the tmSecurityName from SSH; all traffic can be assumed to be authPriv, and we know the securityModel. I think this is inadequate, since some environments may be legally prevented from using encryption, and SSH isn't going to tell SNMP whether it met the requirements specified in msgFlags; only the SNMP security model can compare what SSH says was provided with what the SNMP application requested. ** How do you determine what is good enough encryption? Some of my ** routers ship with DES as the only encryption algorithm for SSH and ** SSH clients complain largely about it since DES is not considered ** secure by these clients. Perhaps the TM subsystem should simply ** never accept sessions that do not provide "good enough encryption"? ** The point is that the user password potentially traveling over the ** connection likely has already been revealed when we check this ** condition in the SNMP engine and so it is kind of too late. 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. [discuss] #31: Is maxSizeResponseScopedPDU relevant? Can it be calculated once for the session? Do we need to take into consideration the SSH window size? ** I think the maxSizeResponseScopedPDU is still relevant, but it ** might be constant for the lifetime of a session since the msg ** header portions now seem to be rather static. I don't think we ** should take into account the SSH window size since this will make ** implementations really harder to do (how do I pull out such ** information from the SSH engine?) 10) Information about the value of tmSecurityName is extracted from the Local Configuration Datastore (LCD) to provide conversion from the SSH authentication-method-specific tmSecurityName to a model- Harrington & Salowey Expires August 12, 2006 [Page 40] Internet-Draft Secure Shell Security Model for SNMP February 2006 independent securityName. If no information is available for the username in the LCD, then the securityName is set to the username associated with the session. Note that USM at this point would return an unknownSecurityName error to the caller, because USM didn't automatically assign a securityname from the model-specific parameters. The message should never reach us if the "user" didn't pass client authentication during session establishment, so tmSecurityname should always be present in the session information. ** I think this depends on whether we have a user name to security ** name mapping which is not the identity mapping or not. If we ** provide such a mapping, then we need to deal with cases where the ** mapping does not work. 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: [todo] copy from the "Passing Security Parameters" section above. transportDomain, transportAddress securityEngineID SSH username, auth options encryption options Integrity checking options 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. Overview 7. Structure of the MIB Module 8. MIB module definition [discuss] #33: does the mib need to be writable, so sessions can be preconfigured, such as for callhome, or would it be populated at creation time by the underlying instrumentation. ** I think it needs to be writable. [todo] do we want a separate writable table that can be configured with a SSH username to SNMP securityname mapping? I currently have both user name and securityname in the session table, but since this is dynamically created, I don't see how anybody could configure the username to securityname mappings in the session table using SNMP. The elements of procedure have been written to use the SSH username directly if there is no securityname mapping configured. Of course, RADIUS might be able to pass a securityname to go with the username Harrington & Salowey Expires August 12, 2006 [Page 41] Internet-Draft Secure Shell Security Model for SNMP February 2006 (Cf: RADIUS MAY return a different username in the ACCESS-ACCEPT message than was used in the ACCESS-REQUEST message, for purposes of accounting.) SSHSM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, mib-2, Counter32, Integer32 FROM SNMPv2-SMI TestAndIncr, AutonomousType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF snmpAuthProtocols, snmpPrivProtocols, SnmpAdminString, SnmpSecurityLevel, SnmpEngineID FROM SNMP-FRAMEWORK-MIB TransportAddress, TransportAddressType FROM TRANSPORT-ADDRESS-MIB ; ** We might need to define TDomain values somewhere. sshsmMIB MODULE-IDENTITY LAST-UPDATED "200509020000Z" ORGANIZATION "ISMS Working Group" CONTACT-INFO "WG-EMail: isms@lists.ietf.org Subscribe: isms-request@lists.ietf.org Chairs: Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany +49 6221 90511-15 quittek@netlab.nec.de Juergen Schoenwaelder International University Bremen Campus Ring 1 28725 Bremen Germany +49 421 200-3587 j.schoenwaelder@iu-bremen.de Co-editors: David Harrington Effective Software Harrington & Salowey Expires August 12, 2006 [Page 42] Internet-Draft Secure Shell Security Model for SNMP February 2006 50 Harding Rd Portsmouth, New Hampshire 03801 USA +1 603-436-8634 ietfdbh@comcast.net 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 " ::= { mib-2 xxxx } -- RFC Ed.: replace xxxx with IANA-assigned number and -- remove this note -- ---------------------------------------------------------- -- -- subtrees in the SSHSM-MIB -- ---------------------------------------------------------- -- sshsmNotifications OBJECT IDENTIFIER ::= { sshsmMIB 0 } sshsmObjects OBJECT IDENTIFIER ::= { sshsmMIB 1 } sshsmConformance OBJECT IDENTIFIER ::= { sshsmMIB 2 } -- ------------------------------------------------------------- -- Objects -- ------------------------------------------------------------- -- Identification of Authentication and Privacy Protocols -- [todo] I think these are not protocols, but mechanisms, and it -- may be inappropriate to list them here Harrington & Salowey Expires August 12, 2006 [Page 43] Internet-Draft Secure Shell Security Model for SNMP February 2006 sshsmPasswordAuthProtocol OBJECT-IDENTITY STATUS current DESCRIPTION "The Secure Shell Password Authentication Method" REFERENCE "RFC 4252" ::= { snmpAuthProtocols 4 } sshsmPublickeyAuthProtocol OBJECT-IDENTITY STATUS current DESCRIPTION "The Secure Shell Public Key Authentication Method" REFERENCE "RFC 4252" ::= { snmpAuthProtocols 5 } sshsmHostbasedAuthProtocol OBJECT-IDENTITY STATUS current DESCRIPTION "The Secure Shell Host-based Authentication Method" REFERENCE "RFC 4252" ::= { snmpAuthProtocols 6 } sshsmRADIUSAuthProtocol OBJECT-IDENTITY STATUS current DESCRIPTION "The RADIUS Authentication Method" REFERENCE "RFC 2865" ::= { snmpAuthProtocols 7 } ** I don't consider RADIUS a special authentication method. It is ** password authentication just with a fancier backend. sshsmAESPrivProtocol OBJECT-IDENTITY STATUS current DESCRIPTION "The AES Encryption Protocol." ::= { snmpPrivProtocols 5 } ** Is AES the only officially required to support SSH encryption ** mechanisms? It seems RFC 4344 has much more to offer. BTW, is it ** useful to export all this information in an SSHSM MIB module? Some ** of the stuff seems generic SSH... -- Statistics for the Secure Shell Security Model sshsmStats OBJECT IDENTIFIER ::= { sshsmObjects 1 } -- [todo] do we need any of these? or other stats? sshsmStatsUnsupportedSecLevels OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because they requested a securityLevel that was unknown to the SNMP engine Harrington & Salowey Expires August 12, 2006 [Page 44] Internet-Draft Secure Shell Security Model for SNMP February 2006 or otherwise unavailable. [todo] we should never hit any of these because they should never be sent by the remote SNMP engine if an appropriate session does not exist. We also do not know what was requested by the remote session. " ::= { sshsmStats 1 } sshsmStatsUnknownUserNames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because they referenced a user that was not known to the SNMP engine. discuss] In SSHSM, we do no preconfiguration, so we don't know any users. If authentication is based on principals defined in the SSH authentication, if the user is not known, they cannot be authenticated, so they wouldn't reach the SNMP engine (assuming we don't permit noAuthNoPriv over SSH. " ::= { sshsmStats 3 } sshsmStatsUnknownEngineIDs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because they referenced an snmpEngineID that was not known to the SNMP engine. [todo] We don't use the engineID during authentication, encryption, or integrity checking, so there is never an error condition related to unknown securityEngineID. (But check the SNMPv3 dependency on knowing the securityEngineID.) " ::= { sshsmStats 4 } -- The sshsmSession Group sshsmSession OBJECT IDENTIFIER ::= { sshsmObjects 2 } Harrington & Salowey Expires August 12, 2006 [Page 45] Internet-Draft Secure Shell Security Model for SNMP February 2006 sshsmSessionSpinLock OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "An advisory lock used to allow several cooperating Command Generator Applications to coordinate their use of facilities to create sessions in the usmUserTable. " ::= { sshsmSession 1 } sshsmSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF SshsmSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of currently available sessions configured in the SNMP engine's Local Configuration Datastore (LCD). Sessions are created as needed, and do not persist across network management system reboots. " ::= { sshsmSession 2 } sshsmSessionEntry OBJECT-TYPE SYNTAX SshsmSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A session configured in the SNMP engine's Local Configuration Datastore (LCD) for the Secure Shell Security Model. " INDEX { sshsmSessionID } ::= { sshsmSessionTable 1 } SshsmSessionEntry ::= SEQUENCE { sshsmSessionID Integer32, sshsmSessionTransport TransportAddressType, sshsmSessionAddress TransportAddress, sshsmSessionUserName SnmpAdminString, sshsmSessionSecurityName SnmpAdminString, sshsmSessionSecurityLevel SnmpSecurityLevel, sshsmSessionAuthProtocol AutonomousType, sshsmSessionPrivProtocol AutonomousType, sshsmSessionEngineID SnmpEngineID } Harrington & Salowey Expires August 12, 2006 [Page 46] Internet-Draft Secure Shell Security Model for SNMP February 2006 sshsmSessionID OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-unique identifier for a session. " ::= { sshsmSessionEntry 1 } sshsmSessionTransport OBJECT-TYPE SYNTAX TransportAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The transport domain associated with this session. " ::= { sshsmSessionEntry 2 } sshsmSessionAddress OBJECT-TYPE SYNTAX TransportAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The transport address associated with this session. " ::= { sshsmSessionEntry 3 } sshsmSessionUserName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A human readable string representing the principal in Security Model dependent format, such as the the user name used in the SSH-USERAUTH-REQUEST message for a successful authentication. " ::= { sshsmSessionEntry 4 } sshsmSessionSecurityName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A human readable string representing the principal in Security Model independent format. The default transformation of the Secure Shell Security Model dependent security ID to the securityName and vice versa is the identity function so that the securityName is the same as the SSH user name. Harrington & Salowey Expires August 12, 2006 [Page 47] Internet-Draft Secure Shell Security Model for SNMP February 2006 " ::= { sshsmSessionEntry 5 } sshsmSessionSecurityLevel OBJECT-TYPE SYNTAX SnmpSecurityLevel MAX-ACCESS read-only STATUS current DESCRIPTION "The Level of Security at which SNMP messages can be sent using this session, in particular, one of: noAuthNoPriv - without authentication and without privacy, authNoPriv - with authentication but without privacy, authPriv - with authentication and with privacy. " DEFVAL { authPriv } ::= { sshsmSessionEntry 6 } sshsmSessionAuthProtocol OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of authentication protocol used by the SSH session associated with this SSHSM session. " ::= { sshsmSessionEntry 7 } sshsmSessionPrivProtocol OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of encryption protocol used by the SSH session associated with this SSHSM session. " ::= { sshsmSessionEntry 8 } ** The auth protocol and the priv protocol in use may be difficult to ** extract from the SSH implementation... sshsmSessionEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current DESCRIPTION "The administratively-unique identifier for the remote SNMP engine associated with this session. " ::= { sshsmSessionEntry 9 } -- ------------------------------------------------------------- Harrington & Salowey Expires August 12, 2006 [Page 48] Internet-Draft Secure Shell Security Model for SNMP February 2006 -- sshsmMIB - Conformance Information -- ------------------------------------------------------------- sshsmGroups OBJECT IDENTIFIER ::= { sshsmConformance 1 } sshsmCompliances OBJECT IDENTIFIER ::= { sshsmConformance 2 } -- ------------------------------------------------------------- -- Units of conformance -- ------------------------------------------------------------- sshsmGroup OBJECT-GROUP OBJECTS { sshsmStatsUnsupportedSecLevels, sshsmStatsUnknownUserNames, sshsmStatsUnknownEngineIDs, sshsmSessionTransport, sshsmSessionAddress, sshsmSessionUserName, sshsmSessionSecurityName, sshsmSessionSecurityLevel, sshsmSessionAuthProtocol, sshsmSessionPrivProtocol, sshsmSessionEngineID, sshsmSessionPrivProtocol, sshsmSessionSpinLock } STATUS current DESCRIPTION "A collection of objects for maintaining session information of an SNMP engine which implements the SNMP Secure Shell Security Model. " ::= { sshsmGroups 2 } -- ------------------------------------------------------------- -- Compliance statements -- ------------------------------------------------------------- sshsmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines that support the SSHSM-MIB" MODULE MANDATORY-GROUPS { sshsmGroup } ::= { sshsmCompliances 1 } END Harrington & Salowey Expires August 12, 2006 [Page 49] Internet-Draft Secure Shell Security Model for SNMP February 2006 9. Security Considerations This document describes a security model that would permit SNMP to utilize SSH security services. [todo] expand as needed. SSHSM relies on SSH mutual authentication, binding of keys, confidentiality and integrity. Any authentication method that meets the requirements of the SSH architecture will provide the properties of mutual authentication and binding of keys. While SSH does support turning off confidentiality and integrity, they SHOULD NOT be turned off when used with SSHSM. SSHv2 provides PFS for encryption keys. PFS is a major design goal of SSH, and any well-designed keyex algorithm will provide it. ** Say what PFS stands for. [todo] We will probably need to discuss the security implications of password based authentication methods. SSHSM has no way to verify that server authentication was performed, to learn the host's public key in advance, or verify that the correct key is being used. SSHSM simply trusts that these are properly handled by the implementer and deployer. ** I would naively assume that SSH aborts if host authentication fails. ** Perhaps we should explain what needs to be deployed for SSHSM to work. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o [todo] There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o [todo] SNMP versions prior to SNMPv3 did not include adequate security. Harrington & Salowey Expires August 12, 2006 [Page 50] Internet-Draft Secure Shell Security Model for SNMP February 2006 Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 10. IANA Considerations IANA is requested to assign: 1. a TCP port number which will be the default port for SNMP over SSH sessions as defined in this document, 2. an SMI number under mib-2, for the MIB module in this document, 3. an SnmpSecurityModel for the Secure Shell Security Model, as documented in the MIB module in this document, 4. An SSH connection protocol subsystem name for the SNMP subsystem defined in this document. 11. Acknowledgements The editors would like to thank Jeffrey Hutzelman and Nicholas Williams for sharing their SSH insights. 12. References 12.1. Normative References [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. Harrington & Salowey Expires August 12, 2006 [Page 51] Internet-Draft Secure Shell Security Model for SNMP February 2006 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3430] Schoenwaelder, J., "Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping", RFC 3430, December 2002. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006. [I-D.schoenw-snmp-tlsm] Harrington, D. and J. Schoenwaelder, "Transport Mapping Security Model (TMSM) for the Simple Network Management Protocol version 3 (SNMPv3)", draft-schoenw-snmp-tlsm-02 (work in progress), May 2005. 12.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Harrington & Salowey Expires August 12, 2006 [Page 52] Internet-Draft Secure Shell Security Model for SNMP February 2006 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. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [I-D.ietf-netconf-prot] Enns, R., "NETCONF Configuration Protocol", draft-ietf-netconf-prot-10 (work in progress), December 2005. [I-D.ietf-netconf-ssh] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure Shell (SSH)", draft-ietf-netconf-ssh-05 (work in progress), October 2005. [I-D.ietf-secsh-gsskeyex] Hutzelman, J., "GSSAPI Authentication and Key Exchange for the Secure Shell Protocol", draft-ietf-secsh-gsskeyex-10 (work in progress), August 2005. Appendix A. Open Issues We need to reach consensus on some issues. I numbered the [discuss] markers in the text for easy correlation to the issue discussions. *** When discussing these issues, please use the provided # in the subject line, and please limit the message to one topic at a time. *** Here is the current list of issues from the SSHSM document where we need to reach consensus. #3: we need some text contributed to discuss the implications of sessions on SNMP. #4: Should the SSHSM document include a discussion of the operational expectations of this model for use in troubleshooting a broken network, or can this be covered in the TMSM document? (Either way, we could use some contributed text on the topic) #5: Should the SSHSM document include a discussion of ways SNMP could be extended to better support management/monitoring needs when a network is running just fine, or can this be covered in the TMSM document, or in an applicability document? Harrington & Salowey Expires August 12, 2006 [Page 53] Internet-Draft Secure Shell Security Model for SNMP February 2006 #6: Are there are any wrinkles to coexistence with SNMPv1/v2c/USM? #7: is there still a need for an "authoritative SNMP engine"? #9: Can an existing R/R session be reused for notifications? #10: a) which securityparameters must be supported for the SSHSM model? b) Which services provided in USM are needed in TMSM/SSHSM? C) How does the Message Processing model provide this information to the security model via generateRequestMsg() and processIncomingMsg() primitives? #12: a) how does SSHSM determine whether SSH can provide the security services requested in msgFlags? B) There were discussions about whether it was acceptable for a transport- mapping-model to provide stronger security than requested. Does this need to be discussed in the SSHSM document, or should we discuss this in the TMSM document? c) when sending a message into an environment where encryption is not legal, how do we ensure that encryption is not provided? #15: What data needs to be stored in the tmStateReference, and how does SSHSM get the information from SSH, for the various authentication and transport options? #16 B) passing a securityname might be useful for passing as a hint to RADIUS or other authorization mechanism to indicate which identity we want to use when doing access control, and RADIUS,etc. can tell us whether the username being authenticated is allowed to be mapped to that authorization/accounting identity. Should we provide securityname when establishing a session, so the authentication machanisms can use it as a hint? #17: I believe somebody suggested we require mutual authentication. I'm not sure I understand the edits. #21: we need to determine what data should be persistent and stored in the LCD for notification purposes. #22: Joe: There are a significant number of security problems associated with mapping to a transport address which may need to be discussed in the security considerations section. #23: We need to discuss the circumstances under which a session should be closed, and how an SNMP engine should determine if, and respond if the SSH session is closed by other means #24: How should we enable auto-discovery? #25: Where is the best place to call establishSession()? See the "Sending an Outgoing Message to the Network" section for more details on this issue. #26: 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). Harrington & Salowey Expires August 12, 2006 [Page 54] Internet-Draft Secure Shell Security Model for SNMP February 2006 #27: 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. Do we need to discuss these issues? Where? in the security considerations? #28: For notification tables, how do we predefine the dynamic session identifiers? #31: Is maxSizeResponseScopedPDU relevant? Can it be calculated once for the session? Do we need to take into consideration the SSH window size? #33: does the mib need to be writable, so sessions can be preconfigured, such as for callhome, or would it be populated at creation time by the underlying instrumentation, and not writable by SNMP? [discuss] #34 - how do we determine whether a PDU contains a Request /Responseor a Notification? [discuss] #35 - which subsystem is used for Reports? A.1. Issues with Resolutions nearing Consensus A.2. Closed Issues #1: is it important to support anonymous user access to SNMP? Resolution: We should support whatever authorizations are provided by SSH; if SSH supports anonymous access, and SSHSM can extract a username, then it should be supported. #2: a) is server authentication a requirement that SNMP will require of the client? b) how can we verify that server authentication was performed, or do we take simply trust the SSH client layer to perform such authentication? c) for the common case of DH signed by public keys, how does the client learn the host's public key in advance, and verify that the correct key is being used? #8: Do we need a mapping between the SSH key (or other SSH engine identifier) and SNMP engineID? What happens if an agent "spoofs" another engineID, and an NMS perfoms a SET of sensitive parameters to the agent? Resolution: we do not need to address this for local SSH and local snmpEngineID, unless smebody can show a use case requirement. There is likely to be a need to map, in an implementation-dependent manner, the remote engineIDs with the associated SSH host (mapping of engineID/transport address/host key). #11: If we eliminate all msgSecurityParameters, should the msgSecurityParameters field in the SNMPv3 message simply be a zero- length OCTET STRING, or should it be an ASN.1 NULL? #13: will SSHSM be impacted by keychanges to the SSH local datastore? Harrington & Salowey Expires August 12, 2006 [Page 55] Internet-Draft Secure Shell Security Model for SNMP February 2006 Resolution: if the session is closed whe the Response is being prepared, discard the Response. #14: MUST the SSHSM model provide mutual authentication of the client and server, and MUST it authenticate, integrity-check, and encrypt the messages? Resolution: yes. #16: The SSH server doesn't necessarily authorize the name carried in the SSH_MSG_USERAUTH_REQUEST message, but may return a different name or list of names that are authorized to be used given the authentication of the provided username. Resolution: this is mistaken; the username from the SSH_MSG_USERAUTH_REQUEST SHOULD be used. A) What should be the source of the SSHSM mechanism-specific username for mapping to securityname? Resolution: the username from the SSH_MSG_USERAUTH_REQUEST SHOULD be used. #18: I currently have multiple sections, one for each known auth mechanism. We need to discuss the parameters that need to be cached for each, and determine whether we can collapse this into one section. a) Using Passwords to Authenticate SNMP Principals B) Using Public keys to Authenticate SNMP Principals C) Using Host-based Authentication of SNMP Principals D) Using RADIUS to Authenticate SNMP Principals Resolution: I will collapse this later, after we have verified we have considered all current/likely scenarios. #19: RADIUS is just an instance of the password authentication protocol. The details of RADIUS are within the SSH layer. I don't think it is a good idea to expose this outside of SSH. Resolution: If possible, the details of RADIUS should not be exposed in SSHSM. There may be an issue with receiving authorization without exposing the details. #20: How do we get the mapping from model-specific identity to a model independent securityName?. Resolution: Implementation- dependent, both in the case of extracting tmSecurityname from SSH for an incoming message, and for providing an LCD mapping. #29: do we need to support reports? For what purpose? Yes, reports are used from application processing. #30: If we actually do not extract anything from securityParameters, do we need to check whether this field 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. If we do check it, do we need to report it through Reports? Resolution: yes; it won't Harrington & Salowey Expires August 12, 2006 [Page 56] Internet-Draft Secure Shell Security Model for SNMP February 2006 hurt to check it. #32: For an incoming message (Processing an Incoming Message section 10), is using a default securityName mapping the right thing to do? Resolution: Yes, it is the right thing to do. Appendix B. Change Log from -00- -00- initial draft as ISMS work product: updated references to SecSH RFCs Modified text related to issues# 1, 2, 8, 11, 13, 14, 16, 18, 19, 20, 29, 30, and 32. updated security considerations removed Juergen Schoenwaelder from authors, at his request ran the mib module through smilint Authors' Addresses David Harrington Effective Software Harding Rd Portsmouth NH USA Phone: +1 603 436 8634 EMail: dbharrington@comcast.net Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 USA EMail: jsalowey@cisco.com Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an Harrington & Salowey Expires August 12, 2006 [Page 57] Internet-Draft Secure Shell Security Model for SNMP February 2006 "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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Harrington & Salowey Expires August 12, 2006 [Page 58] --ZPt4rx8FFjLCG7dd 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 --ZPt4rx8FFjLCG7dd-- From isms-bounces@lists.ietf.org Tue Feb 21 10:59:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBZv4-0008QA-2b; Tue, 21 Feb 2006 10:59:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBZv3-0008Pz-MP for isms@ietf.org; Tue, 21 Feb 2006 10:59:17 -0500 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 1FBZv3-0001Um-AH for isms@ietf.org; Tue, 21 Feb 2006 10:59:17 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 21 Feb 2006 07:59:16 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1LFxEgY009912; Tue, 21 Feb 2006 07:59:15 -0800 (PST) Received: from [144.254.23.103] (dhcp-data-vlan10-23-103.cisco.com [144.254.23.103]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k1LG1uO5016770; Tue, 21 Feb 2006 08:01:58 -0800 Message-ID: <43FB38CF.8000404@cisco.com> Date: Tue, 21 Feb 2006 16:59:11 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: David B Harrington , isms@ietf.org Subject: Re: [Isms] WG review of the SSHSM -01- document References: <004c01c63311$aa0f2e20$0400a8c0@DJYXPY41> <20060220215757.GA29193@boskop.local> In-Reply-To: <20060220215757.GA29193@boskop.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=4241; t=1140537719; x=1140969919; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Isms]=20WG=20review=20of=20the=20SSHSM=20-01-=20document |To:David=20B=20Harrington=20,=20=20isms@ietf.org; X=v=3Dmtcc.com=3B=20h=3DM+QASUTXBmBvEzhHSHXuyUx5U1g=3D; b=HoBpAjitgOb+jGRU2xv4azSrueZWJ9kuuQjecqwVApOLTFBbsg2sAZHM7nxLHS8DkM3q8Few +EMWfvOFSVuQuJbwSEpk8mcXGcxSGSCbYuYRAM8yhCTkcTYlnFMJ9xxrF5Zru2GVqd/zoZifgTX LeAbntqrEiqvcykdQKGlOGpg=; 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: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Juergen: > ** Is it realistic to check from the SNMP stack what the SSH did? I > ** mean, we should be careful to not require something that makes > ** implementations impossible (without cheating). > I'd tend to agree. At some point or another SNMP stack has to trust that the SSH stack. SSH also has no concept of the security levels that SSH uses. There could be a mapping, but that would require a defined interface between the two, requiring modification of SSH. In the simple UNIX case you could envision SSH setting an environment variable for this purpose. > 5. Elements of Procedure > > 5.1. Establishing a Session > > The Secure Shell Security Model provides the following primitive to > pass data back and forth between the Transport Mapping portion of the > Security Model and the SSH service: > > > statusInformation = > establishSession( > IN destTransportDomain -- transport domain to be used > IN destTransportAddress -- 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 > IN subsystem > OUT sessionID > ) > > > > > > > Harrington & Salowey Expires August 12, 2006 [Page 31] > > Internet-Draft Secure Shell Security Model for SNMP February 2006 > > > 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 > This being the case there will never be a way - should an application lose connectivity - for it to reconnect. This eliminates any reasonable implementation of Call Home in the future. > 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 to > establish a connection is successful, then tmStateReference is > created, and the values of transportDomain and transportAddress are > saved. If the attempt to establish a connection is unsuccessful, > then an error indication [todo] will be returned, and [todo] > processing stops. > > [discuss] #22: There are a significant number of security problems > associated with mapping to a transport address which may need to be > discussed in the security considerations section. > Somewhere around here some private state in SSHSM must be maintained to deal with the problem mentioned in 5.4 comments. Specifically, like any reasonable protocol exponential backoff on attempts MUST be employed. For NOs in particular, epsilon delay must also be added. more comments when able. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Feb 23 13:13:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCKyJ-0003Lx-Hf; Thu, 23 Feb 2006 13:13:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCKy0-0003Gd-Af for isms@ietf.org; Thu, 23 Feb 2006 13:13:28 -0500 Received: from ns1.cpanel.btnaccess.com ([205.177.121.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCKxz-0007Te-0w for isms@ietf.org; Thu, 23 Feb 2006 13:13:28 -0500 Received: from [65.213.193.135] (helo=ISODELL001) by ns1.cpanel.btnaccess.com with esmtp (Exim 4.52) id 1FCKxx-00027c-HV for isms@ietf.org; Thu, 23 Feb 2006 13:13:25 -0500 From: "Robert Holliday" To: Date: Thu, 23 Feb 2006 13:13:26 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcY4pNdRl7WlGn8lTviYu+8OZuBUaA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.8 (+) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: Subject: [Isms] Registration for Network Security 2006 Now Open 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="===============1809393699==" Errors-To: isms-bounces@lists.ietf.org Message-Id: This is a multi-part message in MIME format. --===============1809393699== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C6387A.EEA5D9D0" This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C6387A.EEA5D9D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit International Conference on Network Security 2006 Registration Open!!! Reston Virginia, April 17-19 Early Registration Benefits Now Available The conference offers cutting edge discussion and presentations on the contemporary issues in network security and critical information infrastructure. Technical Program: http://www.isocore.com/networksecurity2006/program.htm Discounts still available for early registration. Registration: http://www.isocore.com/networksecurity2006/onlineregis.htm Hotel space is limited but currently available and reservation can be made on-line. Hotel Reservations: http://www.isocore.com/networksecurity2006/hotel.htm To obtain special rates for student or group please contact Robert Holliday at rholliday@isocore.com. www.networksecurity2006.com ------=_NextPart_000_000C_01C6387A.EEA5D9D0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

International Conference on Network Security 2006

 

Registration = Open!!!

 

Reston Virginia, April = 17-19

Early Registration Benefits = Now Available

 

The conference offers cutting edge discussion and presentations on the contemporary issues in network security and = critical information infrastructure. 

 

Technical = Program: http://www.isocore.com/netwo= rksecurity2006/program.htm

 

Discounts still available for early = registration.

 

Registration: http://www.isocore.com/netwo= rksecurity2006/onlineregis.htm

 

Hotel space is limited but currently available and reservation can be made on-line.

 

Hotel = Reservations: http://www.isocore.com/netwo= rksecurity2006/hotel.htm

 

To obtain special rates for student or group please = contact Robert Holliday at rholliday@isocore.com.

 

www.networksecurity2006.com<= /span>

 

------=_NextPart_000_000C_01C6387A.EEA5D9D0-- --===============1809393699== 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 --===============1809393699==-- From isms-bounces@lists.ietf.org Mon Feb 27 15:15:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDomR-0006tD-0k; Mon, 27 Feb 2006 15:15:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDomQ-0006t5-5A for isms@ietf.org; Mon, 27 Feb 2006 15:15:38 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDomO-00006g-Nk for isms@ietf.org; Mon, 27 Feb 2006 15:15:38 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 76BF24D797 for ; Mon, 27 Feb 2006 21:15:35 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 00450-10; Mon, 27 Feb 2006 21:15:33 +0100 (CET) Received: from boskop.local (unknown [10.222.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 9802B4D3D9; Mon, 27 Feb 2006 21:15:33 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 04B18615945; Mon, 27 Feb 2006 21:15:30 +0100 (CET) Date: Mon, 27 Feb 2006 21:15:30 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20060227201530.GE5695@boskop.local> Mail-Followup-To: isms@ietf.org, Vladislav Marinov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: c0bedb65cce30976f0bf60a0a39edea4 Cc: Vladislav Marinov Subject: [Isms] ssh transport domain and transport address definitions X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, during the interim, we agreed that we need new TDomain/TAddress definitions for SNMP over SSH. The security experts like to make a distinction between SSH hostnames (the name that gets authenticated) and DNS names or IPv4/IPv6 addresses. In the SNMP world, we are used to deal with full transport addresses (IP address plus port number) in the SNMP over UDP / SNMP over TCP transport mappings. So it remains a bit unclear to me how the SSH TDomain/TAddress definitions actually would look like. a) [the opaque solution] snmpSSHDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over SSH transport domain. The corresponding transport address is of type SnmpSSHAddress." ::= { snmpDomains X } SnmpSSHAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents an SSH hostname." SYNTAX OCTET STRING (SIZE (255)) b) [the "SMI lacks unions" solution, but we reuse TRANSPORT-ADDRESS-MIB] snmpSSHDNSDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over SSH transport domain. The corresponding transport address is of type TransportAddressDns." ::= { snmpDomains X } snmpSSHIPv4Domain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over SSH transport domain. The corresponding transport address is of type TransportAddressIPv4." ::= { snmpDomains Y } snmpSSHIPv6Domain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over SSH transport domain. The corresponding transport address is of type TransportAddressIPv6." ::= { snmpDomains Z } -- perhaps even more needed to handle zone indices? c) [the "SMI lacks unions" solution, we prefer to be independent] -- basically b) above except that we import TC definitions by copy -- rather than reference Comments? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Feb 27 18:01:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDrN7-0002Oq-P7; Mon, 27 Feb 2006 18:01:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDrN6-0002DE-2C for isms@ietf.org; Mon, 27 Feb 2006 18:01:40 -0500 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDrN4-0005Ja-N7 for isms@ietf.org; Mon, 27 Feb 2006 18:01:40 -0500 Received: from djyxpy41 (c-24-128-66-70.hsd1.nh.comcast.net[24.128.66.70]) by comcast.net (rwcrmhc12) with SMTP id <20060227230137m12001i812e>; Mon, 27 Feb 2006 23:01:37 +0000 From: "David B Harrington" To: , Subject: RE: [Isms] ssh transport domain and transport address definitions Date: Mon, 27 Feb 2006 18:01:31 -0500 Message-ID: <01b201c63bf1$c0cbd9e0$0200a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20060227201530.GE5695@boskop.local> Thread-Index: AcY72pN9+llnDhQFQbinLeE7R9wr4wAFm9CA X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: 'Vladislav Marinov' 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: , Errors-To: isms-bounces@lists.ietf.org Hi, I consdier you the expert on transportdomains. I was about to write you and ask hoe to do this, but here's my first pass: TransportAddressSSH ::= TEXTUAL-CONVENTION DISPLAY-HINT "1a" STATUS current DESCRIPTION "Represents a hostname followed by a colon ':' (ASCII character 0x3A) and a port number in ASCII. The name SHOULD be fully qualified whenever possible. Values of this textual convention are not directly useable as transport-layer addressing information, and require runtime resolution. As such, applications that write them must be prepared for handling errors if such values are not supported, or cannot be resolved (if resolution occurs at the time of the management operation). The DESCRIPTION clause of TransportAddress objects that may have TransportAddressSSH values must fully describe how (and when) such names are to be resolved to IP addresses and vice versa. This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair. When this textual convention is used as a syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the OBJECT-TYPE declaration MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers." SYNTAX OCTET STRING (SIZE (1..255)) transportDomainSSH OBJECT-IDENTITY STATUS current DESCRIPTION "The SSH transport domain using fully qualified domain names. The corresponding transport address is of type TransportAddressSSH." ::= { transportDomains xxxx } -- RFC Ed.: replace xxxx with IANA-assigned number and -- remove this note An dI wasn't sure how we handle adding a new tranportType. Dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Monday, February 27, 2006 3:16 PM > To: isms@ietf.org > Cc: Vladislav Marinov > Subject: [Isms] ssh transport domain and transport address definitions > > Hi, > > during the interim, we agreed that we need new TDomain/TAddress > definitions for SNMP over SSH. The security experts like to make a > distinction between SSH hostnames (the name that gets authenticated) > and DNS names or IPv4/IPv6 addresses. In the SNMP world, we are used > to deal with full transport addresses (IP address plus port number) in > the SNMP over UDP / SNMP over TCP transport mappings. So it remains a > bit unclear to me how the SSH TDomain/TAddress definitions actually > would look like. > > a) [the opaque solution] > > snmpSSHDomain OBJECT-IDENTITY > STATUS current > DESCRIPTION > "The SNMP over SSH transport domain. > The corresponding transport address is of type > SnmpSSHAddress." > ::= { snmpDomains X } > > SnmpSSHAddress ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "Represents an SSH hostname." > SYNTAX OCTET STRING (SIZE (255)) > > b) [the "SMI lacks unions" solution, but we reuse > TRANSPORT-ADDRESS-MIB] > > snmpSSHDNSDomain OBJECT-IDENTITY > STATUS current > DESCRIPTION > "The SNMP over SSH transport domain. > The corresponding transport address is of type > TransportAddressDns." > ::= { snmpDomains X } > > snmpSSHIPv4Domain OBJECT-IDENTITY > STATUS current > DESCRIPTION > "The SNMP over SSH transport domain. > The corresponding transport address is of type > TransportAddressIPv4." > ::= { snmpDomains Y } > > snmpSSHIPv6Domain OBJECT-IDENTITY > STATUS current > DESCRIPTION > "The SNMP over SSH transport domain. > The corresponding transport address is of type > TransportAddressIPv6." > ::= { snmpDomains Z } > > -- perhaps even more needed to handle zone indices? > > c) [the "SMI lacks unions" solution, we prefer to be independent] > > -- basically b) above except that we import TC definitions by copy > -- rather than reference > > Comments? > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Feb 27 18:34:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDrtE-0000aN-4j; Mon, 27 Feb 2006 18:34:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDrtD-0000aF-Db for isms@ietf.org; Mon, 27 Feb 2006 18:34:51 -0500 Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDrtC-00073L-6l for isms@ietf.org; Mon, 27 Feb 2006 18:34:51 -0500 Received: from h-68-166-37-228.snvacaid.dynamic.covad.net ([68.166.37.228] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FDrtB-0002kc-00 for isms@ietf.org; Mon, 27 Feb 2006 18:34:49 -0500 Message-ID: <000c01c63bf6$a1b62420$6401a8c0@oemcomputer> From: "Randy Presuhn" To: References: <01b201c63bf1$c0cbd9e0$0200a8c0@DJYXPY41> Subject: Re: [Isms] ssh transport domain and transport address definitions Date: Mon, 27 Feb 2006 15:36:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: ; > Cc: "'Vladislav Marinov'" > Sent: Monday, February 27, 2006 3:01 PM > Subject: RE: [Isms] ssh transport domain and transport address definitions ... > TransportAddressSSH ::= TEXTUAL-CONVENTION > DISPLAY-HINT "1a" > STATUS current > DESCRIPTION > "Represents a hostname followed by a colon ':' > (ASCII character 0x3A) and a port number in ASCII. > The name SHOULD be fully qualified whenever possible. ... Presumably we mean "decimal port number". Do we need to say anything about IDN handling? Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 28 18:04:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEDtj-0005eX-IA; Tue, 28 Feb 2006 18:04:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEDte-0005WN-I9 for isms@ietf.org; Tue, 28 Feb 2006 18:04:46 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEDm8-0003md-Ha for isms@ietf.org; Tue, 28 Feb 2006 17:57:01 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 706474D871; Tue, 28 Feb 2006 23:56:59 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 12155-02; Tue, 28 Feb 2006 23:56:57 +0100 (CET) Received: from boskop.local (unknown [10.222.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id A895F4D7FF; Tue, 28 Feb 2006 23:56:57 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 4EEEA61668A; Tue, 28 Feb 2006 23:56:55 +0100 (CET) Date: Tue, 28 Feb 2006 23:56:54 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Subject: Re: [Isms] ssh transport domain and transport address definitions Message-ID: <20060228225654.GA8138@boskop.local> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <01b201c63bf1$c0cbd9e0$0200a8c0@DJYXPY41> <000c01c63bf6$a1b62420$6401a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000c01c63bf6$a1b62420$6401a8c0@oemcomputer> 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: bb8f917bb6b8da28fc948aeffb74aa17 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Mon, Feb 27, 2006 at 03:36:27PM -0800, Randy Presuhn wrote: > Hi - > > > From: "David B Harrington" > > To: ; > > Cc: "'Vladislav Marinov'" > > Sent: Monday, February 27, 2006 3:01 PM > > Subject: RE: [Isms] ssh transport domain and transport address definitions > ... > > TransportAddressSSH ::= TEXTUAL-CONVENTION > > DISPLAY-HINT "1a" > > STATUS current > > DESCRIPTION > > "Represents a hostname followed by a colon ':' > > (ASCII character 0x3A) and a port number in ASCII. > > The name SHOULD be fully qualified whenever possible. > ... > > Presumably we mean "decimal port number". yes > Do we need to say anything about IDN handling? I assume that the value of the TC is a good old plain hostname (which might contain an encoded IDN). In other words, I would expect management frontends to do any IDN processing and that on the SNMP level we only deal with ordinary lookups. Do you agree? If not, why not? /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 Feb 28 18:17:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEE5w-0004be-0Z; Tue, 28 Feb 2006 18:17:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEE5u-0004bQ-JB for isms@ietf.org; Tue, 28 Feb 2006 18:17:26 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEE5t-0004QR-1s for isms@ietf.org; Tue, 28 Feb 2006 18:17:26 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 521C94D3C2; Wed, 1 Mar 2006 00:17:24 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14047-04; Wed, 1 Mar 2006 00:17:23 +0100 (CET) Received: from boskop.local (unknown [10.222.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id C77864D3BE; Wed, 1 Mar 2006 00:17:22 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 66FAE6166AE; Wed, 1 Mar 2006 00:17:20 +0100 (CET) Date: Wed, 1 Mar 2006 00:17:20 +0100 From: Juergen Schoenwaelder To: Dave Harrington Subject: Re: [Isms] ssh transport domain and transport address definitions Message-ID: <20060228231720.GB8138@boskop.local> Mail-Followup-To: Dave Harrington , isms@ietf.org References: <01b201c63bf1$c0cbd9e0$0200a8c0@DJYXPY41> <000c01c63bf6$a1b62420$6401a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000c01c63bf6$a1b62420$6401a8c0@oemcomputer> 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: 32b73d73e8047ed17386f9799119ce43 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Dave Harrington wrote: > I consdier you the expert on transportdomains. Dave, I did not receive your message directly so I grabbed it from the mailing list archive. The snmp transport domains are a bit special... The TransportAddress TC family (and the InetAddress TC family) is designed to be just a discriminated union. The TransportAddress is the union of several specific formats for IPv4/IPv6 addresses with and without zone indexes as well as DNS names. The TransportDomain just serves as a discriminator so that an application can cast a TransprotAddress in a (TransportDomain, TransportAddress) pair down to the TC indicated by the TransportDomain value. The SNMP TDomain TC, however, associates additional semantics with the TDomain value. In particular, transport domains for TMSMs indicate which secure transport is being used. Since SNMP only supports (TDomain/TAddress) to identify SNMP transport endpoints, we either a) define separate snmpSSHTDomain values for all relevant formats for IPv4/IPv6 transport addresses with and without zone indexes as well as DNS names (and we repeat that exercise for every new TMSM), or we b) define a single snmpSSHTDoman value and encode the transport endpoint into an OCTET STRING value which must be analyzed by implementations to figure out whether it contains a DNS name, or an IPv6 address with a zone identifier and port number or ... Both options have pros and cons and I am not really sure which path to take. > I was about to write you and ask hoe to do this, but here's my first > pass: > > TransportAddressSSH ::= TEXTUAL-CONVENTION > DISPLAY-HINT "1a" > STATUS current > DESCRIPTION > "Represents a hostname followed by a colon ':' > (ASCII character 0x3A) and a port number in ASCII. > The name SHOULD be fully qualified whenever possible. [...] > SYNTAX OCTET STRING (SIZE (1..255)) This would pretty much require that boxes have DNS names when you use SSH. I know environments where routers/switches do not have DNS names. And SSH clients generally seem to work just find with IP addresses in case there is no hostname. So I believe we should support the option to use plain IP addresses (plus port numbers). > transportDomainSSH OBJECT-IDENTITY > STATUS current > DESCRIPTION > "The SSH transport domain using fully qualified domain > names. The corresponding transport address is of type > TransportAddressSSH." > ::= { transportDomains xxxx } >-- RFC Ed.: replace xxxx with IANA-assigned number and >-- remove this note I believe this belongs below snmpDomains. > An dI wasn't sure how we handle adding a new tranportType. We should not mess around with TransportAddressType (in case this is what you mean). /js Note that we seem to have done a bad job explaining which TDomain value one is going to use for things not directly covered by RFC 3417. If I look at the NET-SNMP code base (5.1.4.pre3), I see: UDP/IPv6 1.3.6.1.4.1.8072.3.3.4 TCP/IPv4 1.3.6.1.3.91.1.1 TCP/IPv6 1.3.6.1.4.1.8072.3.3.5 I think this should be (according to RFC 3417 and RFC 3430): UDP/IPv6 1.3.6.1.2.1.100.1.2 TCP/IPv4 1.3.6.1.2.1.100.1.5 TCP/IPv6 1.3.6.1.2.1.100.1.6 Other implementors might want to check which value they assume/support. -- 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 Feb 28 19:05:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEEqH-0004y8-6V; Tue, 28 Feb 2006 19:05:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEEqG-0004xn-9Q for isms@ietf.org; Tue, 28 Feb 2006 19:05:20 -0500 Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEEqF-0008D4-0S for isms@ietf.org; Tue, 28 Feb 2006 19:05:20 -0500 Received: from h-64-105-34-111.snvacaid.dynamic.covad.net ([64.105.34.111] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FEEqD-0002ku-00 for isms@ietf.org; Tue, 28 Feb 2006 19:05:18 -0500 Message-ID: <000401c63cc4$189f7dc0$6401a8c0@oemcomputer> From: "Randy Presuhn" To: References: <01b201c63bf1$c0cbd9e0$0200a8c0@DJYXPY41> <000c01c63bf6$a1b62420$6401a8c0@oemcomputer> <20060228225654.GA8138@boskop.local> Subject: Re: [Isms] ssh transport domain and transport address definitions Date: Tue, 28 Feb 2006 16:07:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Tuesday, February 28, 2006 2:56 PM > Subject: Re: [Isms] ssh transport domain and transport address definitions ... > > Presumably we mean "decimal port number". > > yes It probably wouldn't hurt to say so, then. > > Do we need to say anything about IDN handling? > > I assume that the value of the TC is a good old plain hostname (which > might contain an encoded IDN). In other words, I would expect > management frontends to do any IDN processing and that on the SNMP > level we only deal with ordinary lookups. Do you agree? If not, why > not? ... As long as it's explicit, I'll be happy. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 28 19:12:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEEwo-0007Zx-Tf; Tue, 28 Feb 2006 19:12:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEEwn-0007Yy-IT for isms@ietf.org; Tue, 28 Feb 2006 19:12:05 -0500 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEEwm-0000N0-9p for isms@ietf.org; Tue, 28 Feb 2006 19:12:05 -0500 Received: from djyxpy41 (c-24-128-66-70.hsd1.nh.comcast.net[24.128.66.70]) by comcast.net (rwcrmhc13) with SMTP id <20060301001202m13002o2use>; Wed, 1 Mar 2006 00:12:03 +0000 From: "David B Harrington" To: "'Randy Presuhn'" , Subject: RE: [Isms] ssh transport domain and transport address definitions Date: Tue, 28 Feb 2006 19:11:57 -0500 Message-ID: <04f501c63cc4$c203bfc0$0200a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <000401c63cc4$189f7dc0$6401a8c0@oemcomputer> Thread-Index: AcY8w9U19k2rasRUSBybOsmv/QPX7wAAK/+g X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Comments inline. > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Tuesday, February 28, 2006 7:07 PM > To: isms@ietf.org > Subject: Re: [Isms] ssh transport domain and transport > address definitions > > Hi - > > > From: "Juergen Schoenwaelder" > > To: "Randy Presuhn" > > Cc: > > Sent: Tuesday, February 28, 2006 2:56 PM > > Subject: Re: [Isms] ssh transport domain and transport > address definitions > ... > > > Presumably we mean "decimal port number". > > > > yes > > It probably wouldn't hurt to say so, then. Fixed. > > > > Do we need to say anything about IDN handling? > > > > I assume that the value of the TC is a good old plain > hostname (which > > might contain an encoded IDN). In other words, I would expect > > management frontends to do any IDN processing and that on the SNMP > > level we only deal with ordinary lookups. Do you agree? If not, why > > not? > ... > > As long as it's explicit, I'll be happy. Please send wordsmithed text. > > Randy > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 28 19:20:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEF5F-0002Q2-3x; Tue, 28 Feb 2006 19:20:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEF5E-0002Px-Lq for isms@ietf.org; Tue, 28 Feb 2006 19:20:48 -0500 Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEF5D-0000yI-FP for isms@ietf.org; Tue, 28 Feb 2006 19:20:48 -0500 Received: from h-64-105-34-111.snvacaid.dynamic.covad.net ([64.105.34.111] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FEF5C-00020I-00 for isms@ietf.org; Tue, 28 Feb 2006 19:20:46 -0500 Message-ID: <000601c63cc6$42b6b860$6401a8c0@oemcomputer> From: "Randy Presuhn" To: References: <04f501c63cc4$c203bfc0$0200a8c0@DJYXPY41> Subject: Re: [Isms] ssh transport domain and transport address definitions Date: Tue, 28 Feb 2006 16:22:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: "'Randy Presuhn'" ; > Sent: Tuesday, February 28, 2006 4:11 PM > Subject: RE: [Isms] ssh transport domain and transport address definitions ... > Please send wordsmithed text. ... When the value is a hostname, it is encoded in ASCII using the IDNA protocol [RFC3490]. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms