From isms-bounces@lists.ietf.org Wed Oct 03 13:59:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id8VB-0006z5-RG; Wed, 03 Oct 2007 13:59:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id8VA-0006wz-Ka for isms@ietf.org; Wed, 03 Oct 2007 13:59:16 -0400 Received: from mail.elbrysnetworks.com ([64.140.243.164] helo=gumby.elbrysnetworks.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Id8V0-0005w4-Dt for isms@ietf.org; Wed, 03 Oct 2007 13:59:12 -0400 Received: (qmail 12487 invoked from network); 3 Oct 2007 13:58:25 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 3 Oct 2007 13:58:25 -0400 From: "David B. Nelson" To: References: <20070926201354.GA27245@elstar.local> Subject: RE: [Isms] no wg meeting in vancouver Date: Wed, 3 Oct 2007 13:57:40 -0400 Organization: Elbrys Networks, Inc. Message-ID: <003a01c805e6$e3d84e80$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgAehunErc/3vxVTECtxjx6lrEliQFbFulQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <20070926201354.GA27245@elstar.local> 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 Juergen Schoenwaelder writes... > My current thinking is that the ISMS working group does not need to > meet in Vancouver. Given the lack of in-depth technical issues discussed at the last meeting, I think this is reasonable. > The core ISMS specifications have hopefully been delivered to the IESG > well before the Vancouver meeting. Since the Radius document seems to > be well on its way as well, I do not think that we need a face-to-face > meeting in Vancouver. Perhaps we should initiate a WGLC on the RADIUS document to formally elicit some comments? > I believe we can very well resolve any remaining > issues and the remaining charter items via the mailing list. Very likely. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 18 18:12:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IidbU-0002cJ-Ra; Thu, 18 Oct 2007 18:12:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IidbU-0002bL-1x for isms@ietf.org; Thu, 18 Oct 2007 18:12:32 -0400 Received: from mail.elbrysnetworks.com ([64.140.243.164] helo=gumby.elbrysnetworks.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IidbO-0003V5-PR for isms@ietf.org; Thu, 18 Oct 2007 18:12:32 -0400 Received: (qmail 9095 invoked from network); 18 Oct 2007 18:12:09 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 18 Oct 2007 18:12:09 -0400 From: "David B. Nelson" To: References: <20070926201354.GA27245@elstar.local> <003a01c805e6$e3d84e80$5d1216ac@xpsuperdvd2> Date: Thu, 18 Oct 2007 18:11:21 -0400 Organization: Elbrys Networks, Inc. Message-ID: <005801c811d3$d0dd6100$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgAehunErc/3vxVTECtxjx6lrEliQFbFulQAvsGFhA= In-Reply-To: <003a01c805e6$e3d84e80$5d1216ac@xpsuperdvd2> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Isms] Request for review of Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org David B. Nelson writes... > > The core ISMS specifications have hopefully been delivered to the > > IESG well before the Vancouver meeting. Since the Radius document > > seems to be well on its way as well, I do not think that we need a > > face-to-face meeting in Vancouver. > > Perhaps we should initiate a WGLC on the RADIUS document to formally > elicit some comments? Hello? Following up on my previous post, I'd like to get active review of the ISMS RADIUS Usage document (http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-usage-00.txt), even if we are not ready to formally call for WGLC. The RADEXT document (http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorizat ion-00.txt) that defines the RADIUS attributes used by our draft here ISMS is in WGLC in RADEXT, so it would be good to have some review of our ISMS RADIUS draft before the RADEXT document is sent to the IESG. Thanks! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Oct 24 13:12:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikjly-0005di-LH; Wed, 24 Oct 2007 13:12:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikjly-0005da-4I for isms@ietf.org; Wed, 24 Oct 2007 13:12:02 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikjlr-0006A9-5L for isms@ietf.org; Wed, 24 Oct 2007 13:12:02 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l9OHBQlF001644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Oct 2007 13:11:31 -0400 (EDT) Date: Wed, 24 Oct 2007 13:11:26 -0400 From: Jeffrey Hutzelman To: "David B. Nelson" , isms@ietf.org Subject: RE: [Isms] Re: SSH USERNAME Message-ID: In-Reply-To: <001001c7f6e4$584dab50$6501a8c0@xpsuperdvd2> References: <015e01c7f6d7$ad55ee80$6702a8c0@china.huawei.com> <001001c7f6e4$584dab50$6501a8c0@xpsuperdvd2> Originator-Info: login-token=Mulberry:01Wbx9nMMk8hClB/UdjDqtC/AutMfg8PbGMasBjzw=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Friday, September 14, 2007 11:31:39 AM -0400 "David B. Nelson" wrote: > Does SNMP have a way to know that SSH has performed a "meaningful" > authentication? The answer to that is implementation-specific. An SSH implementation might provide information about the name of the client, what auth methods were used, etc. That could be done via environment variables or via some other mechanism; for example, I could envision an environment in which the interface between SSH and SNMP is richer than a simple file descriptor or two-way pipe, and includes a way to discover things about the connection. But all of that is implementation-specific; the interface between SSH and an application running on top of it is not standardized. > If not, is there a way for the system administrator to configure the > combination of SSH and SNMP such that insufficiently "meaningful" levels > of authentication are not employed with Transport Security Models? I guess that depends on what you consider "meaningful", and to me, that is an operator policy decision. You could certainly configure SSH to allow unauthenticated access via the "none" method. You could also give it a password database backend which accept any username with the password "foo". Whether these are meaningful depends on your environment. Neither of these things would prevent the channel from being encrypted and integrity-protected, though of course one could choose null encryption and/or MAC algorithms. All of these are NOT RECOMMENDED in SSH, but are available for testing and special situations. I don't think we need to say anything in ISMS about this; it is sufficient to assume that if SSH is in use, then messages arriving via an SSH connection were sent by the user whose name SSH reports. The whole point of reusing SSH is to avoid revisiting those issues in SNMP. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Oct 24 20:43:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikqn9-0004gX-D7; Wed, 24 Oct 2007 20:41:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikqn8-0004fp-GR for isms@ietf.org; Wed, 24 Oct 2007 20:41:42 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikqn8-0006Ik-1I for isms@ietf.org; Wed, 24 Oct 2007 20:41:42 -0400 Received: from harrington73653 (unknown[61.48.39.181]) by comcast.net (sccrmhc14) with SMTP id <2007102500413901400kjrume>; Thu, 25 Oct 2007 00:41:40 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'David B. Nelson'" , References: <015e01c7f6d7$ad55ee80$6702a8c0@china.huawei.com><001001c7f6e4$584dab50$6501a8c0@xpsuperdvd2> Subject: RE: [Isms] Re: SSH USERNAME Date: Thu, 25 Oct 2007 08:41:26 +0800 Message-ID: <040201c8169f$c81c2d00$b927303d@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: AcgWYQFUmQcbEM+8Sr280lU6I97GzQAAs+CQ X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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, The SNMPv3 WG deliberately reduced all security capabilities down to auth and priv, without concern for rating the strength of different mechanisms for authentication and encryption. How strong a security mechanism is depends on the environment in which it is being deployed, and the perceived strength of mechanisms can of course change over time as hackers find vulnerabilities in existing mechanisms. The SNMPv3 WG chose not to try to classify all mechanisms according to strength, and chose not to rely on the security area to do so either. It is a deployment decision how to configure the combination of various security mechanisms to provide "meaningful" levels of security service. The SSH Transport Model assumes (and states so) that an operator should not use "none" or other non-meaningful security mechanisms with SSH for securing SNMP, and assumes that all operator-configured support for the SSH-Transport model will provide "meaningful" authentication and encryption. David Harrington dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Thursday, October 25, 2007 1:11 AM > To: David B. Nelson; isms@ietf.org > Cc: Jeffrey Hutzelman > Subject: RE: [Isms] Re: SSH USERNAME > > > > On Friday, September 14, 2007 11:31:39 AM -0400 "David B. Nelson" > wrote: > > > Does SNMP have a way to know that SSH has performed a "meaningful" > > authentication? > > The answer to that is implementation-specific. An SSH > implementation might > provide information about the name of the client, what auth > methods were > used, etc. That could be done via environment variables or > via some other > mechanism; for example, I could envision an environment in which the > interface between SSH and SNMP is richer than a simple file > descriptor or > two-way pipe, and includes a way to discover things about the > connection. > But all of that is implementation-specific; the interface > between SSH and > an application running on top of it is not standardized. > > > > If not, is there a way for the system administrator to configure the > > combination of SSH and SNMP such that insufficiently > "meaningful" levels > > of authentication are not employed with Transport Security Models? > > I guess that depends on what you consider "meaningful", and > to me, that is > an operator policy decision. You could certainly configure > SSH to allow > unauthenticated access via the "none" method. You could also > give it a > password database backend which accept any username with the password > "foo". Whether these are meaningful depends on your > environment. Neither > of these things would prevent the channel from being encrypted and > integrity-protected, though of course one could choose null > encryption > and/or MAC algorithms. All of these are NOT RECOMMENDED in > SSH, but are > available for testing and special situations. > > I don't think we need to say anything in ISMS about this; it > is sufficient > to assume that if SSH is in use, then messages arriving via an SSH > connection were sent by the user whose name SSH reports. The > whole point > of reusing SSH is to avoid revisiting those issues in SNMP. > > -- Jeff > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 25 02:19:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikw2s-00087I-6M; Thu, 25 Oct 2007 02:18:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikw2r-0007zn-AX for isms@ietf.org; Thu, 25 Oct 2007 02:18:17 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikw2h-0000EY-1y for isms@ietf.org; Thu, 25 Oct 2007 02:18:13 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l9P6H2K9026748; Thu, 25 Oct 2007 01:17:02 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 01:17:01 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 08:16:59 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Re: SSH USERNAME Date: Thu, 25 Oct 2007 08:15:55 +0200 Message-ID: In-Reply-To: <040201c8169f$c81c2d00$b927303d@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Re: SSH USERNAME Thread-Index: AcgWYQFUmQcbEM+8Sr280lU6I97GzQAAs+CQABqiIUA= References: <015e01c7f6d7$ad55ee80$6702a8c0@china.huawei.com><001001c7f6e4$584dab50$6501a8c0@xpsuperdvd2> <040201c8169f$c81c2d00$b927303d@china.huawei.com> From: "WIJNEN, Bert \(Bert\)" To: "David Harrington" , "Jeffrey Hutzelman" , "David B. Nelson" , X-OriginalArrivalTime: 25 Oct 2007 06:16:59.0862 (UTC) FILETIME=[A6DCC760:01C816CE] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org I mainly agree with David here. But we do include the securityModel as a parameter (in VACM) for our decisions to grant or deny access to certain MIB views. So at deployment time, operators can take that into account. Bert Wijnen =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Thursday, October 25, 2007 2:41 AM > To: 'Jeffrey Hutzelman'; 'David B. Nelson'; isms@ietf.org > Subject: RE: [Isms] Re: SSH USERNAME >=20 > Hi, >=20 > The SNMPv3 WG deliberately reduced all security capabilities=20 > down to auth and priv, without concern for rating the=20 > strength of different mechanisms for authentication and encryption. >=20 > How strong a security mechanism is depends on the environment=20 > in which it is being deployed, and the perceived strength of=20 > mechanisms can of course change over time as hackers find=20 > vulnerabilities in existing mechanisms.=20 >=20 > The SNMPv3 WG chose not to try to classify all mechanisms=20 > according to strength, and chose not to rely on the security=20 > area to do so either. >=20 > It is a deployment decision how to configure the combination=20 > of various security mechanisms to provide "meaningful" levels=20 > of security service. >=20 > The SSH Transport Model assumes (and states so) that an=20 > operator should not use "none" or other non-meaningful=20 > security mechanisms with SSH for securing SNMP, and assumes=20 > that all operator-configured support for the SSH-Transport=20 > model will provide "meaningful" > authentication and encryption. >=20 > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 > > -----Original Message----- > > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > > Sent: Thursday, October 25, 2007 1:11 AM > > To: David B. Nelson; isms@ietf.org > > Cc: Jeffrey Hutzelman > > Subject: RE: [Isms] Re: SSH USERNAME > >=20 > >=20 > >=20 > > On Friday, September 14, 2007 11:31:39 AM -0400 "David B. Nelson"=20 > > wrote: > >=20 > > > Does SNMP have a way to know that SSH has performed a "meaningful" > > > authentication? > >=20 > > The answer to that is implementation-specific. An SSH=20 > implementation=20 > > might provide information about the name of the client, what auth=20 > > methods were used, etc. That could be done via environment=20 > variables=20 > > or via some other mechanism; for example, I could envision an=20 > > environment in which the >=20 > > interface between SSH and SNMP is richer than a simple file=20 > descriptor=20 > > or two-way pipe, and includes a way to discover things about the=20 > > connection. > > But all of that is implementation-specific; the interface=20 > between SSH=20 > > and an application running on top of it is not standardized. > >=20 > >=20 > > > If not, is there a way for the system administrator to configure > the > > > combination of SSH and SNMP such that insufficiently > > "meaningful" levels > > > of authentication are not employed with Transport Security Models? > >=20 > > I guess that depends on what you consider "meaningful", and to me,=20 > > that is an operator policy decision. You could certainly configure=20 > > SSH to allow unauthenticated access via the "none" method. =20 > You could=20 > > also give it a password database backend which accept any username=20 > > with the > password=20 > > "foo". Whether these are meaningful depends on your environment. =20 > > Neither of these things would prevent the channel from=20 > being encrypted=20 > > and integrity-protected, though of course one could choose null=20 > > encryption and/or MAC algorithms. All of these are NOT=20 > RECOMMENDED in=20 > > SSH, but are available for testing and special situations. > >=20 > > I don't think we need to say anything in ISMS about this; it is=20 > > sufficient to assume that if SSH is in use, then messages=20 > arriving via=20 > > an SSH connection were sent by the user whose name SSH=20 > reports. The=20 > > whole point of reusing SSH is to avoid revisiting those issues in=20 > > SNMP. > >=20 > > -- Jeff > >=20 > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > >=20 >=20 >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 25 11:14:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4Ov-0007xw-L2; Thu, 25 Oct 2007 11:13:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4Ou-0007xf-0v for isms@ietf.org; Thu, 25 Oct 2007 11:13:36 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Il4Ot-0001nw-Pu for isms@ietf.org; Thu, 25 Oct 2007 11:13:35 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa05955; 25 Oct 2007 11:13 EDT Date: Thu, 25 Oct 2007 11:13:16 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: David Harrington Subject: RE: [Isms] Re: SSH USERNAME In-Reply-To: <040201c8169f$c81c2d00$b927303d@china.huawei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Thu, 25 Oct 2007, David Harrington wrote: > The SSH Transport Model assumes (and states so) that an operator > should not use "none" or other non-meaningful security mechanisms with > SSH for securing SNMP, and assumes that all operator-configured > support for the SSH-Transport model will provide "meaningful" > authentication and encryption. And I believe this is sufficient. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms