From isms-bounces@lists.ietf.org Wed Jun 01 00:18:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdKgQ-0000r3-UY; Wed, 01 Jun 2005 00:18:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdKgP-0000qy-Eh for isms@megatron.ietf.org; Wed, 01 Jun 2005 00:18:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25552 for ; Wed, 1 Jun 2005 00:18:18 -0400 (EDT) Received: from ib431.i.pppool.de ([85.73.180.49] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdL08-0001Vx-SN for isms@ietf.org; Wed, 01 Jun 2005 00:38:46 -0400 Received: by boskop.local (Postfix, from userid 501) id 77E0630C6D8; Wed, 1 Jun 2005 06:18:02 +0200 (CEST) Date: Wed, 1 Jun 2005 06:18:00 +0200 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt Message-ID: <20050601041800.GD27627@boskop.local> Mail-Followup-To: David B Harrington , 'Sam Hartman' , isms@ietf.org References: <200506010342.XAA23104@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506010342.XAA23104@ietf.org> User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 'Sam Hartman' , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Tue, May 31, 2005 at 11:42:25PM -0400, David B Harrington wrote: > Netconf punted on the notification channel because not all their > "transports" could handle such a thing. SNMP obviously requires > notification capabilities, so we'd need to determine how that could be > done with SSH, as with any other possible transport layer security > protocols. The original netconf approach was to use basically one transport layer connection to multiplex different channels over it, some carrying netconf 1.0 interactions and others carrying notifications and whatever you might invent in the future. The biggest technical problem with this (and notifications in general) was as far as I recall the SOAP/HTTP mapping (plus some concerns how independent the channels really are when the underlying transport is TCP rather than SCTP). RFC 3430 (SNMP over TCP) suggests that TCP connections are initiated by notification originators in case there is no currently established connection that can be used to send the notification. Following this approach with ssh would require to provision authentication credentials on the agent so that agents can successfully authenticate to a notification receiver. There might be other approaches, like the reuse of manager initiated secure transport connections for notifications. There is some text in Appendix A in RFC 3430 which captures some of these discussions when RFC 3430 was written. /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 Wed Jun 01 11:38:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdVIr-0006xr-J2; Wed, 01 Jun 2005 11:38:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdVIp-0006xh-Uf for isms@megatron.ietf.org; Wed, 01 Jun 2005 11:38:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27219 for ; Wed, 1 Jun 2005 11:38:41 -0400 (EDT) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdVcg-0001oX-GN for isms@ietf.org; Wed, 01 Jun 2005 11:59:14 -0400 Received: from pc6 (1Cust95.tnt102.lnd4.gbr.da.uu.net [213.116.52.95]) by ranger.systems.pipex.net (Postfix) with SMTP id 8B529E0003DF; Wed, 1 Jun 2005 16:38:29 +0100 (BST) Message-ID: <03d801c566b6$f281c8c0$0601a8c0@pc6> From: "Tom Petch" To: , "'Sam Hartman'" References: <20050601034233.F3147E00008F@zone.systems.pipex.net> Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt Date: Wed, 1 Jun 2005 16:11:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "David B Harrington" To: "'Sam Hartman'" Cc: "'Tom Petch'" ; Sent: Wednesday, June 01, 2005 5:42 AM Subject: RE: [Isms] draft-schoenw-snmp-tlsm-02.txt > Hi Sam, > > I would use SSH as it was designed to be used. > > I am not very knowledgeable about the SSH suite, but I would expect to > use the SSH transport layer, and the SSH authentication protocol. > Me too (wry smile:-] What I would like, because I do not yet have the technical skills to do it myself, is a comparison of SSH and TLS as they might be used by isms. Starting with Sam's 'Thoughts on Encapsulation', I do see SSH (architecture, connection?, transport, userauth) as the alternative to TLS if we use a reliable transport and it has several non-technical reasons in its favour. I suspect that both TLS and SSH will have technical issues making them a less than good fit for isms so we may end up, as with the architecture, with a finely balanced decision to make sometime in the next three months. PS I am familiar with the Netconf over SSH I-D but find it too limited to be illuminating; it doesn't tackle the SSH issues. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 01 13:00:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdWaL-0004rm-6m; Wed, 01 Jun 2005 13:00:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdWaI-0004qX-VN for isms@megatron.ietf.org; Wed, 01 Jun 2005 13:00:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04731 for ; Wed, 1 Jun 2005 13:00:47 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdWu9-00062h-7D for isms@ietf.org; Wed, 01 Jun 2005 13:21:22 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA29515; Wed, 1 Jun 2005 12:00:32 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j51H0Vn18627; Wed, 1 Jun 2005 10:00:31 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 10:00:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] draft-schoenw-snmp-tlsm-02.txt Date: Wed, 1 Jun 2005 10:00:11 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC300@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] draft-schoenw-snmp-tlsm-02.txt Thread-Index: AcVmU3mZ/JRKBvhCSTWcXJz4AuyOMgAdaAuA From: "Fleischman, Eric" To: "Sam Hartman" , X-OriginalArrivalTime: 01 Jun 2005 17:00:29.0252 (UTC) FILETIME=[69FD2840:01C566CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 I am confused by this exchange. I trust that the group is not confusing SSL with SSH (i.e., the Secure Sockets Layer is the ancestor of and equivilent of (e.g., SSLv3.1) the Transport Layer Security (TLS) standard). SSL/TLS operate at the transport layer. Secure Shell (SSH) operates at the application layer. Both protocols SSL/TLS and SSH are frequently used to provide a secure session to application layer protocols. For example, SSL/TLS is well known for securing HTTP and SSH for securing FTP, though both have many other uses. I assume that you know this, but I'm just verifying that this is so since I am perhaps misreading the exchange below as showing confusion on this point. Now when you speak of SSH, do you mean SSHv1 or SSHv2? My own personal belief is that SSHv2 has superior security attributes over SSHv1 and thus I would prefer us using SSHv2 if we choose to use SSH at all for ISMS. In any case, the view from my knot-hole is that if we leverage either SSH or SSL/TLS, I'd like ISMS to benefit from both its authentication and privacy provisions. In fact, I'd like to see authentication occur at two layers (which is the normal way these session transports are usually used): at the transport/session layer (using either SSH or SSL/TLS, well, actually, my own preference is DTLS) and at the application layer, perhaps using USM but preferably using a variant to SNMP that leverages existing authentication systems, preferably Kerberos and/or PKI, but optionally also server-based authentication approachs such as Radius, Diameter, COPS Servers or TACACS+. -----Original Message----- From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 >I think it doesn't matter so much what we call tls=20 >or ssh. Tom's question still stands: how do you see=20 >ssh interacting with your protocol? >Are you expecting to use the ssh authentication=20 >protocol without the ssh transport? I don't think=20 >that's within the scope of that protocol. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 01 16:34:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdZvL-0006v9-TB; Wed, 01 Jun 2005 16:34:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdZvK-0006qQ-Eh for isms@megatron.ietf.org; Wed, 01 Jun 2005 16:34:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06882 for ; Wed, 1 Jun 2005 16:34:43 -0400 (EDT) Message-Id: <200506012034.QAA06882@ietf.org> Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdaFC-0004z8-N4 for isms@ietf.org; Wed, 01 Jun 2005 16:55:20 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <2005060120343601400dp5qhe>; Wed, 1 Jun 2005 20:34:36 +0000 From: "David B Harrington" To: Subject: RE: [Isms] draft-schoenw-snmp-tlsm-02.txt Date: Wed, 1 Jun 2005 16:34:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <474EEBD229DF754FB83D256004D021080EC300@XCH-NW-6V1.nw.nos.boeing.com> Thread-Index: AcVmU3mZ/JRKBvhCSTWcXJz4AuyOMgAdaAuAAAbbldA= X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: 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, Comments inline > -----Original Message----- > From: Fleischman, Eric [mailto:eric.fleischman@boeing.com] > I trust that the group is not > confusing > SSL with SSH Nope. > SSL/TLS operate at the transport layer. Secure Shell (SSH) > operates at the application layer. I think the answer is really immaterial to our needs, but at what layer would you say the SSH Transport Layer Protocol operates? http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-secsh-tra nsport-24.txt says "The SSH transport layer is a secure low level transport protocol." I agree that other aspects operate at the application layer. Ultimately, I don't think it makes much difference, since SNMP in the TMSM approach would operate above all the SSH functionality that SNMP would likely use. > Now when you speak of SSH, do you mean SSHv1 or SSHv2? Personally, I mean the work of the IETF SecSH WG - "the protocol being defined in this set of documents is version 2.0" > In any case, the view from my knot-hole is that if we leverage either > SSH or SSL/TLS, I'd like ISMS to benefit from both its authentication > and privacy provisions. Agreed. > In fact, I'd like to see > authentication occur at > two layers (which is the normal way these session transports > are usually > used): at the transport/session layer (using either SSH or SSL/TLS, > well, actually, my own preference is DTLS) and at the > application layer, > perhaps using USM but preferably using a variant to SNMP that > leverages > existing authentication systems, preferably Kerberos and/or PKI, but > optionally also server-based authentication approachs such as Radius, > Diameter, COPS Servers or TACACS+. I think there might be benefits of having an SNMP-level authentication to supplement the transport layer authentication, but I have concerns that this puts us back to square one having to do another level of key distribution. If we decide to distribute keys to the SNMP engine for SNMP-level authentication, then I don't see a lot of benefit from also tying the transport layer authentication into SNMP. The transport layer security can be provided independent of SNMP. As always, another security model could be developed to provide the hook from SNMP to RADIUS or Kerberos that you want, and operators who want double authentication at the SNMP level could deploy both a transport-layer security model tied into to SNMP, and a second SNMP-level authentication model, but I think most operators won't require double authentication, and I think double authentication is not the goal of this WG. 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 Wed Jun 01 17:08:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdaRr-0007CT-F8; Wed, 01 Jun 2005 17:08:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdaRo-0007CL-PZ for isms@megatron.ietf.org; Wed, 01 Jun 2005 17:08:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08798 for ; Wed, 1 Jun 2005 17:08:18 -0400 (EDT) Received: from stratton-three-sixty-nine.mit.edu ([18.187.6.114] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddalh-0006mU-HU for isms@ietf.org; Wed, 01 Jun 2005 17:28:54 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 592F4E0063; Wed, 1 Jun 2005 17:08:09 -0400 (EDT) To: David B Harrington Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt References: <200506010342.XAA23104@ietf.org> <20050601041800.GD27627@boskop.local> From: Sam Hartman Date: Wed, 01 Jun 2005 17:08:09 -0400 In-Reply-To: <20050601041800.GD27627@boskop.local> (Juergen Schoenwaelder's message of "Wed, 1 Jun 2005 06:18:00 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 suspect in many environments agents capable of accepting commands using ssh for authentication will have sufficient credentials to do outbound authentication. This is because host keys are also useful for ssh userauth. What I'm less clear about is whether people will typically be able to authorize these credentials to generate notifications. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 01 18:08:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdbNe-0004gl-BL; Wed, 01 Jun 2005 18:08:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdbNc-0004dp-4q for isms@megatron.ietf.org; Wed, 01 Jun 2005 18:08:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13546 for ; Wed, 1 Jun 2005 18:08:01 -0400 (EDT) Received: from i9a28.i.pppool.de ([85.73.154.40] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdbhV-0001Ui-3q for isms@ietf.org; Wed, 01 Jun 2005 18:28:38 -0400 Received: by boskop.local (Postfix, from userid 501) id B37B230CC8E; Wed, 1 Jun 2005 19:11:47 +0200 (CEST) Date: Wed, 1 Jun 2005 19:11:47 +0200 From: Juergen Schoenwaelder To: "Fleischman, Eric" Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt Message-ID: <20050601171147.GD29036@boskop.local> Mail-Followup-To: "Fleischman, Eric" , Sam Hartman , dbharrington@comcast.net, isms@ietf.org References: <474EEBD229DF754FB83D256004D021080EC300@XCH-NW-6V1.nw.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <474EEBD229DF754FB83D256004D021080EC300@XCH-NW-6V1.nw.nos.boeing.com> User-Agent: Mutt/1.5.8i X-Spam-Score: 0.7 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: dbharrington@comcast.net, Sam Hartman , 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 Wed, Jun 01, 2005 at 10:00:11AM -0700, Fleischman, Eric wrote: > [...] SSL/TLS operate at the transport layer. Secure Shell (SSH) > operates at the application layer. I do not necessarily agree to this distinction nor do I believe such a distinction is in any way useful. The real question is indeed what is authenticated where by which mechanism and how to leverage this (if we want to leverage this). And finding answers to this question requires to dive into concrete details since there is no abstract architectural answer here as far as I can tell. And we really need security experts who know TLS, SSH, SASL, you name it inside out to sit together with SNMP folks to figure out the details. Any volunteers? Can the chairs help to organize this? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 01 18:51:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddc3x-0004Mi-CX; Wed, 01 Jun 2005 18:51:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddc3v-0004LW-GM for isms@megatron.ietf.org; Wed, 01 Jun 2005 18:51:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17558 for ; Wed, 1 Jun 2005 18:51:44 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdcNn-0003aC-Ki for isms@ietf.org; Wed, 01 Jun 2005 19:12:22 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA29632; Wed, 1 Jun 2005 15:51:22 -0700 (PDT) Received: from XCH-NWBH-10.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j51MpLp03844; Wed, 1 Jun 2005 17:51:21 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Jun 2005 15:51:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] draft-schoenw-snmp-tlsm-02.txt Date: Wed, 1 Jun 2005 15:50:29 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC306@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] draft-schoenw-snmp-tlsm-02.txt Thread-Index: AcVm93qs1Wi5UxrES9Obuj/XAWN0oAAAnKKw From: "Fleischman, Eric" To: X-OriginalArrivalTime: 01 Jun 2005 22:51:11.0727 (UTC) FILETIME=[684807F0:01C566FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: quoted-printable Cc: dbharrington@comcast.net, Sam Hartman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Well, Juergen, since you directly sent this request to me, I will give you a tentative answer. However, a more complete (and adequate) answer will require digging, including knowing specifically how we intend to use these protocols, a topic that is not exactly clear to me at this moment. Regardless, this email contains a terse summary of SSH and then another terse summary for TLS. It is written from a perspective of router security though end system uses are also touched on. The following is a terse summary I wrote about SSH back in 2002: Although many computers and SSH implementations currently support RSA (digital certificate)-based authentication for SSH accesses today, routers currently only support account-password based authentication according to the Cisco documentation.=20 Within select Cisco System products (i.e., 7200, 75000, 12000 series only), SSH is configured by configuring a host name and domain name on the router. This is done via the hostname and ip domain-name IOS commands. Then an RSA key-pair needs to be generated and either local or AAA authentication needs to be enabled. If AAA authentication is being used, then it must be disabled on the console port. If local account-password authentication is being used, then it should be enabled via the username command. Finally, optional SSH parameters need to be configured. These optional parameters modify the default connection behavior. This includes the timeout value for the SSH negotiation phase and the number of authentication retries which are permitted. SSH is automatically enabled on these Cisco products when the RSA key-pair is generated and disabled when the RSA key pair is deleted. The command crypto key generate rsa generates the RSA key pair and enables SSH. Commercial versions of SSH using X.509-based PKI certificates are available from http://www.ssh.fi/products/.=20 Linux (and other Unix)-based systems require that the end user generate a RSA asymmetric key pair in order to authenticate himself or herself to a secure shell by using the ssh-keygen command. The resulting public key (i.e., the key contained within the resulting .pub file) needs to be added into the ~/.ssh/authorized_keys file on the Linux O/S. All keys listed in that file are subsequently allowed access to the secure shell of that Linux instance (i.e., either Red or Black) if the user correctly types the pass phrase associated with that key during login. The Internet Engineering Task Force (IETF) has recently begun working on updating and standardizing SSH, including the Secure Copy (SCP). Information about their work is found at http://www.ietf.org/html.charters/secsh-charter.html, including pointers to the many internet-draft documents they are currently working on. The current implementation of SSH is SSHv1. The IETF is currently defining (and standardizing) SSHv2.=20 The RSA public keys of the managers using SSH within Linux applications will be extracted from their PKI Identity Certificates and loaded onto the ~/.ssh/authorized.key file in the normal Unix manner. These managers will be required to have their entire public key pair (i.e., both public and private keys) on the client system from which they will access their Linux (SSH) accounts). They also will need to have established a password on their Linux (SSH) account(s) in order to access the stored public key on the JTR.=20 The following is a terse summary I wrote about TLS back in 2002: The Transport Layer Security (TLS) standard is used to secure applications running over TCP. This is a formal standardization of the SSLv3 protocol that was created by Netscape and widely used for web (HTTP) security. TLS is currently widely used to secure applications that use the TCP transport, including LDAP and HTTP. TLS is defined in RFC 2246 (see http://www.ietf.org/rfc/rfc2246.txt). It provides privacy and integrity to TCP traffic. TLS is described within Section 1 of RFC 2246 as follows: "The primary goal of the TLS Protocol is to provide privacy and data integrity between two communicating applications. The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. At the lowest level, layered on top of some reliable transport protocol (e.g., TCP), is the TLS Record Protocol. The TLS Record Protocol provides connection security that has two basic properties: * The connection is private. Symmetric cryptography is used for data encryption (e.g., DES, RC4, etc.) The keys for this symmetric encryption are generated uniquely for each connection and are based on a secret negotiated by another protocol (such as the TLS Handshake Protocol). The Record Protocol can also be used without encryption. * The connection is reliable. Message transport includes a message integrity check using a keyed MAC (i.e., HMAC). Secure hash functions (e.g., SHA, MD5, etc.) are used for MAC computations. The Record Protocol can operate without a MAC, but is generally only used in this mode while another protocol is using the Record Protocol as a transport for negotiating security parameters." Among the functions supported by TLS is the TLS Handshake Protocol, which uses the TLS Cipher Suite parameter to indicate which key exchange alternative is to be used. Five different alternatives are available: three different Diffie-Hellman protocol variants, the RSA key exchange (which encrypts the secret key with the receivers RSA public key), and Fortessa. The key exchange enables the client and the server to define a shared secret key for the session. That shared symmetric key is subsequently used for conventional encryption of SSL payloads (i.e., privacy) and to sign a keyed message authentication code (HMAC) for integrity protection during the remainder of the session. The client and server may each optionally also formally establish each other's identity during the handshake protocol using X.509v3-compliant PKI certificates (i.e., asymmetric (public key) cryptography (e.g., RSA, DSS)). This latter authentication can be made optional, but is generally required for at least one of the peers. This means that TLS is designed to work with X.509 version 3-compliant (PKI) digital certificates, such as PKI. Devices (e.g., servers) can also have PKI digital certificates assigned to them. The specific mechanism by which the latter is done is operating system (and sometimes application) specific. Changing topics, I was impressed by Eric Rescorla's book "SSL and TLS", published by Addison Wesley in 2001. Eric also co-authored the DTLS ID. Eric has contributed to this WG. He could doublessly answer any technical questions we could ask him. I have also been impressed by two O'Reilly books about SSH: SSH the Secure Shell by Janiel Barrett and Richard Silverman and OpenSSL by John Viega, Matt Messier, and Pravir Chandra. Although they haven't yet contributed to our WG, perhaps we could appeal to them for insight as well? --Eric -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 Sent: Wednesday, June 01, 2005 10:12 AM To: Fleischman, Eric Cc: Sam Hartman; dbharrington@comcast.net; isms@ietf.org Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt On Wed, Jun 01, 2005 at 10:00:11AM -0700, Fleischman, Eric wrote: > [...] SSL/TLS operate at the transport layer. Secure Shell (SSH)=20 > operates at the application layer. I do not necessarily agree to this distinction nor do I believe such a distinction is in any way useful. The real question is indeed what is authenticated where by which mechanism and how to leverage this (if we want to leverage this). And finding answers to this question requires to dive into concrete details since there is no abstract architectural answer here as far as I can tell. And we really need security experts who know TLS, SSH, SASL, you name it inside out to sit together with SNMP folks to figure out the details. Any volunteers? Can the chairs help to organize this? /js --=20 Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 01 19:48:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddcwy-0000E8-H6; Wed, 01 Jun 2005 19:48:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddcww-0000Dw-90 for isms@megatron.ietf.org; Wed, 01 Jun 2005 19:48:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21138 for ; Wed, 1 Jun 2005 19:48:34 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DddGq-0006UI-Sx for isms@ietf.org; Wed, 01 Jun 2005 20:09:13 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2005 16:47:55 -0700 X-IronPort-AV: i="3.93,159,1115017200"; d="scan'208"; a="272906099:sNHT6629672680" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j51NlAma018025; Wed, 1 Jun 2005 16:47:50 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 16:47:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] draft-schoenw-snmp-tlsm-02.txt Date: Wed, 1 Jun 2005 16:47:50 -0700 Message-ID: Thread-Topic: [Isms] draft-schoenw-snmp-tlsm-02.txt Thread-Index: AcVm93qs1Wi5UxrES9Obuj/XAWN0oAAAnKKwAAFyXkA= From: "Khanh Nguyen \(khanhvn\)" To: "Fleischman, Eric" X-OriginalArrivalTime: 01 Jun 2005 23:47:51.0805 (UTC) FILETIME=[52E2C2D0:01C56704] X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b 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 Nice summaries! A few things to add about TLS auth (beside x509 cert): + Fortezza auth is supported in SSLv3 but not TLS as far as I know. + Kerberos auth for TLS is defined in http://www.faqs.org/rfcs/rfc2712.html + SRP and PSK auth are being considered by TLS WG: http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-09.txt http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-08.txt The last two may be of interests for SNMP since they facilitate user auth. Sam may have some insight about their ietf status. Khanh > -----Original Message----- > From: isms-bounces@lists.ietf.org=20 > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Fleischman, Eric > Sent: Wednesday, June 01, 2005 3:50 PM > To: j.schoenwaelder@iu-bremen.de > Cc: dbharrington@comcast.net; Sam Hartman; isms@ietf.org > Subject: RE: [Isms] draft-schoenw-snmp-tlsm-02.txt >=20 > Well, Juergen, since you directly sent this request to me, I=20 > will give you a tentative answer. However, a more complete=20 > (and adequate) answer will require digging, including knowing=20 > specifically how we intend to use these protocols, a topic=20 > that is not exactly clear to me at this moment. Regardless,=20 > this email contains a terse summary of SSH and then another=20 > terse summary for TLS. It is written from a perspective of=20 > router security though end system uses are also touched on. >=20 > The following is a terse summary I wrote about SSH back in 2002: >=20 > Although many computers and SSH implementations currently=20 > support RSA (digital certificate)-based authentication for=20 > SSH accesses today, routers currently only support=20 > account-password based authentication according to the Cisco=20 > documentation.=20 >=20 > Within select Cisco System products (i.e., 7200, 75000, 12000=20 > series only), SSH is configured by configuring a host name=20 > and domain name on the router. This is done via the hostname=20 > and ip domain-name IOS commands. Then an RSA key-pair needs=20 > to be generated and either local or AAA authentication needs=20 > to be enabled. If AAA authentication is being used, then it=20 > must be disabled on the console port. If local=20 > account-password authentication is being used, then it should=20 > be enabled via the username command. Finally, optional SSH=20 > parameters need to be configured. These optional parameters=20 > modify the default connection behavior. This includes the=20 > timeout value for the SSH negotiation phase and the number of=20 > authentication retries which are permitted. >=20 > SSH is automatically enabled on these Cisco products when the=20 > RSA key-pair is generated and disabled when the RSA key pair=20 > is deleted. The command crypto key generate rsa generates the=20 > RSA key pair and enables SSH. >=20 > Commercial versions of SSH using X.509-based PKI certificates=20 > are available from http://www.ssh.fi/products/.=20 >=20 > Linux (and other Unix)-based systems require that the end=20 > user generate a RSA asymmetric key pair in order to=20 > authenticate himself or herself to a secure shell by using=20 > the ssh-keygen command. The resulting public key (i.e., the=20 > key contained within the resulting .pub file) needs to be=20 > added into the ~/.ssh/authorized_keys file on the Linux O/S.=20 > All keys listed in that file are subsequently allowed access=20 > to the secure shell of that Linux instance (i.e., either Red=20 > or Black) if the user correctly types the pass phrase=20 > associated with that key during login. >=20 > The Internet Engineering Task Force (IETF) has recently begun=20 > working on updating and standardizing SSH, including the=20 > Secure Copy (SCP). > Information about their work is found at=20 > http://www.ietf.org/html.charters/secsh-charter.html,=20 > including pointers to the many internet-draft documents they=20 > are currently working on. The current implementation of SSH=20 > is SSHv1. The IETF is currently defining (and standardizing) SSHv2.=20 >=20 > The RSA public keys of the managers using SSH within Linux=20 > applications will be extracted from their PKI Identity=20 > Certificates and loaded onto the ~/.ssh/authorized.key file=20 > in the normal Unix manner. These managers will be required to=20 > have their entire public key pair (i.e., both public and=20 > private keys) on the client system from which they will=20 > access their Linux (SSH) accounts). They also will need to=20 > have established a password on their Linux (SSH) account(s)=20 > in order to access the stored public key on the JTR.=20 >=20 > The following is a terse summary I wrote about TLS back in 2002: >=20 > The Transport Layer Security (TLS) standard is used to secure=20 > applications running over TCP. This is a formal standardization of the > SSLv3 protocol that was created by Netscape and widely used for web > (HTTP) security. TLS is currently widely used to secure=20 > applications that use the TCP transport, including LDAP and HTTP. >=20 > TLS is defined in RFC 2246 (see=20 > http://www.ietf.org/rfc/rfc2246.txt). It provides privacy and=20 > integrity to TCP traffic. TLS is described within Section 1=20 > of RFC 2246 as follows: >=20 > "The primary goal of the TLS Protocol is to provide privacy=20 > and data integrity between two communicating applications.=20 > The protocol is composed of two layers: the TLS Record=20 > Protocol and the TLS Handshake Protocol. At the lowest level,=20 > layered on top of some reliable transport protocol (e.g.,=20 > TCP), is the TLS Record Protocol. The TLS Record Protocol=20 > provides connection security that has two basic properties: > * The connection is private. Symmetric cryptography is used for > data encryption (e.g., DES, RC4, etc.) The keys for this=20 > symmetric encryption are generated uniquely for each=20 > connection and are based on a secret negotiated by another=20 > protocol (such as the TLS Handshake Protocol). The Record=20 > Protocol can also be used without encryption. > * The connection is reliable. Message transport includes a message > integrity check using a keyed MAC (i.e., HMAC). Secure hash=20 > functions (e.g., SHA, MD5, etc.) are used for MAC=20 > computations. The Record Protocol can operate without a MAC,=20 > but is generally only used in this mode while another=20 > protocol is using the Record Protocol as a transport for=20 > negotiating security parameters." >=20 > Among the functions supported by TLS is the TLS Handshake=20 > Protocol, which uses the TLS Cipher Suite parameter to=20 > indicate which key exchange alternative is to be used. Five=20 > different alternatives are available: > three different Diffie-Hellman protocol variants, the RSA key=20 > exchange (which encrypts the secret key with the receivers=20 > RSA public key), and Fortessa. The key exchange enables the=20 > client and the server to define a shared secret key for the=20 > session. That shared symmetric key is subsequently used for=20 > conventional encryption of SSL payloads (i.e., > privacy) and to sign a keyed message authentication code=20 > (HMAC) for integrity protection during the remainder of the=20 > session. The client and server may each optionally also=20 > formally establish each other's identity during the handshake=20 > protocol using X.509v3-compliant PKI certificates (i.e.,=20 > asymmetric (public key) cryptography (e.g., RSA, DSS)). This=20 > latter authentication can be made optional, but is generally=20 > required for at least one of the peers. This means that TLS=20 > is designed to work with X.509 version 3-compliant (PKI)=20 > digital certificates, such as PKI. > Devices (e.g., servers) can also have PKI digital=20 > certificates assigned to them. The specific mechanism by=20 > which the latter is done is operating system (and sometimes=20 > application) specific. >=20 > Changing topics, I was impressed by Eric Rescorla's book "SSL=20 > and TLS", published by Addison Wesley in 2001. Eric also=20 > co-authored the DTLS ID. > Eric has contributed to this WG. He could doublessly answer=20 > any technical questions we could ask him. I have also been=20 > impressed by two O'Reilly books about SSH: SSH the Secure=20 > Shell by Janiel Barrett and Richard Silverman and OpenSSL by=20 > John Viega, Matt Messier, and Pravir Chandra. Although they=20 > haven't yet contributed to our WG, perhaps we could appeal to=20 > them for insight as well? >=20 > --Eric >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Wednesday, June 01, 2005 10:12 AM > To: Fleischman, Eric > Cc: Sam Hartman; dbharrington@comcast.net; isms@ietf.org > Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt >=20 >=20 > On Wed, Jun 01, 2005 at 10:00:11AM -0700, Fleischman, Eric wrote: >=20 > > [...] SSL/TLS operate at the transport layer. Secure Shell (SSH)=20 > > operates at the application layer. >=20 > I do not necessarily agree to this distinction nor do I believe such a > distinction is in any way useful. The real question is indeed what is > authenticated where by which mechanism and how to leverage this (if we > want to leverage this). And finding answers to this question=20 > requires to > dive into concrete details since there is no abstract architectural > answer here as far as I can tell. And we really need security experts > who know TLS, SSH, SASL, you name it inside out to sit together with > SNMP folks to figure out the details. >=20 > Any volunteers? Can the chairs help to organize this? >=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 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jun 02 10:48:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddr01-0003Kw-Io; Thu, 02 Jun 2005 10:48:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddqzz-0003Km-JZ for isms@megatron.ietf.org; Thu, 02 Jun 2005 10:48:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22277 for ; Thu, 2 Jun 2005 10:48:41 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdrK1-0001RS-9P for isms@ietf.org; Thu, 02 Jun 2005 11:09:26 -0400 Received: from pc6 (1Cust26.tnt105.lnd4.gbr.da.uu.net [213.116.58.26]) by astro.systems.pipex.net (Postfix) with SMTP id 6F1FBE000161 for ; Thu, 2 Jun 2005 15:48:30 +0100 (BST) Message-ID: <033401c56779$204f5160$0601a8c0@pc6> From: "Tom Petch" To: References: <200506012034.QAA06882@ietf.org> Date: Thu, 2 Jun 2005 15:32:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.9 (++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] TLS Q X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I wonder if someone can identify which, if any, of the TLS options are in widespread use. As I increase my understanding of TLS from the specifications, I do find the large number of alternatives increase the complexity and hope some can be ignored on the basis that the market place will have chosen some at the expense of others. Like, - which ciphersuites or families of cipher suites (thinking of a family as defined by key exchange method, if you will allow me that term)? - DSS v RSA? - stream or block encryption? And a general question; why does TLS define ciphersuites at all when SSH has a more mix and match approach to the choice of algorithms? Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jun 02 13:11:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdtEa-0001VR-Hh; Thu, 02 Jun 2005 13:11:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdtEZ-0001UE-CL for isms@megatron.ietf.org; Thu, 02 Jun 2005 13:11:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07926 for ; Thu, 2 Jun 2005 13:11:52 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdtYc-0001RF-Jn for isms@ietf.org; Thu, 02 Jun 2005 13:32:39 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 97646E0063; Thu, 2 Jun 2005 13:11:44 -0400 (EDT) To: Tom Petch Subject: Re: [Isms] TLS Q References: <200506012034.QAA06882@ietf.org> <033401c56779$204f5160$0601a8c0@pc6> From: Sam Hartman Date: Thu, 02 Jun 2005 13:11:44 -0400 In-Reply-To: <033401c56779$204f5160$0601a8c0@pc6> (Tom Petch's message of "Thu, 2 Jun 2005 15:32:21 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 >>>>> "Tom" == Tom Petch writes: Tom> I wonder if someone can identify which, if any, of the TLS Tom> options are in widespread use. As I increase my understanding Tom> of TLS from the specifications, I do find the large number of Tom> alternatives increase the complexity and hope some can be Tom> ignored on the basis that the market place will have chosen Tom> some at the expense of others. At a protocol level you probably don't care much: if your protocol doesn't work with all the options you are probably doing something wrong. Naturally you'll want to pick mandatory to implement options. For the most part the TLS 1.1 spec should do this for you. Tom> Like, - which ciphersuites or families of cipher suites Tom> (thinking of a family as defined by key exchange method, if Tom> you will allow me that term)? - DSS v RSA? RSA Tom> - stream or Tom> block encryption? I think both are in reasonably common use although I suspect that for now block will be increasing in usage and stream decreasing. Tom> And a general question; why does TLS define ciphersuites at Tom> all when SSH has a more mix and match approach to the choice Tom> of algorithms? Preference of the designers involved. I really wish they had at least separated key exchange from the rest. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jun 03 10:37:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeDIX-0003wk-80; Fri, 03 Jun 2005 10:37:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeDIW-0003wf-Fw for isms@megatron.ietf.org; Fri, 03 Jun 2005 10:37:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03970 for ; Fri, 3 Jun 2005 10:37:18 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeDcl-0005rI-NO for isms@ietf.org; Fri, 03 Jun 2005 10:58:16 -0400 Received: from pc6 (1Cust206.tnt27.lnd4.gbr.da.uu.net [62.188.154.206]) by blaster.systems.pipex.net (Postfix) with SMTP id 119D3E00039C for ; Fri, 3 Jun 2005 15:37:07 +0100 (BST) Message-ID: <001501c56840$b35c6660$0601a8c0@pc6> From: "Tom Petch" To: References: <200506012034.QAA06882@ietf.org> <033401c56779$204f5160$0601a8c0@pc6> Date: Fri, 3 Jun 2005 15:32:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] SSH in TMSM X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I thought I would fit SSH in David's and Juergen's TMSM to see how different it looked. I include it below. It does not seem significantly different, at least at the level of abstraction in TMSM. I would glad to hear of any mistakes in it; in fact, given my knowledge of SSH, if noone finds anything wrong with it, then I will not believe those with skills in SSH have read it:-) I did wonder why the tmStateReference should be passing so much information about the session to the MPSP; I would have expected the master secret, eg, to have stayed in the TMSP I also wonder about the multiplexing of upper layers onto lower. SSH has connections and I have assumed that SNMP uses them and so the state includes a channel number, as opposed to using raw ssh transport. But for TLS, application data seems to map directly onto the TLS Record Protocol with no intervening multiplexing. Tom Petch ================================================================= (is the original TLS specific text - grep out as you will) [is my idea of the SSH equivalent] 5.1 [SSH](TLS)/TCP Transport Mapping Security Model SNMP supports multiple transports. The preferred transport for SNMP over IP is UDP [RFC3417]. An experimental transport for SNMP over TCP is defined in [RFC3430]. [SSH](TLS)/TCP will create an association between the TMSM of one SNMP entity and the TMSM of another SNMP entity. The created "tunnel" may provide encryption and data integrity. Both encryption and data integrity are optional features in [SSH](TLS). The [SSH](TLS) TMSP MUST provide authentication if auth is requested in the securityLevel of the SNMP message request (RFC3412 4.1.1). The [SSH](TLS) TM-security model MUST specify that the messages be encrypted if priv is requested in the securityLevel parameter of the SNMP message request (RFC3412 4.1.1). The [SSH](TLS) TM-security model MUST support the [SSH Transport Layer Protocol and User Authentication Protocol] (TLS Handshake Protocol with mutual authentication). 5.1.1 tmStateReference for [SSH](TLS) Upon establishment of a [SSH](TLS) session, the TMSP will cache the state information. A unique tmStateReference will be passed to the corresponding MPSP. The MPSP will pass the securityStateReference to the Message Processing Model for memory management. The tmStateReference cache: tmStateReference tmSecurityStateReference tmTransportDomain = TCP/IPv4 tmTransportAddress = x.x.x.x:y tmSecurityModel - [SSH](TLS) TMSM tmSecurityName = "tba" tmSecurityLevel = "authPriv" tmAuthProtocol = [SSH-2.0 hmac-sha1] (Handshake MD5) tmPrivProtocol = [SSH-2.0 3des-cbc](Handshake DES) {**I am unclear why all these session parameters need passing to the MPSP} tmSessionID = [SSH session_id H] (Handshake session identifier) tmSessionKey = [SSH shared secret K] (Handshake peer certificate) [{**no SSH equivalent}] (tmSessionMasterSecret = master secret) tmSessionParameters = compression method, cipher spec(, is- resumable) [tmChannelNumber = nn]({**no TLS equivalent}) 5.1.2 MPSP for [SSH](TLS) TM-Security Model messageProcessingModel = SNMPv3 securityModel = [SSH](TLS) TMSM securityName = tmSecurityName securityLevel = msgSecurityLevel _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jun 03 13:48:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeGH7-0001ej-KW; Fri, 03 Jun 2005 13:48:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeGH6-0001ec-A8 for isms@megatron.ietf.org; Fri, 03 Jun 2005 13:48:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18244 for ; Fri, 3 Jun 2005 13:48:03 -0400 (EDT) Message-Id: <200506031748.NAA18244@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeGbN-0001cf-Im for isms@ietf.org; Fri, 03 Jun 2005 14:09:01 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005060317475401100mmhjfe>; Fri, 3 Jun 2005 17:47:55 +0000 From: "David B Harrington" To: "'Tom Petch'" , Subject: RE: [Isms] SSH in TMSM Date: Fri, 3 Jun 2005 13:47:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVoSmTsToDCvzfuRfibicOJA78iMAADLYJA In-Reply-To: <001501c56840$b35c6660$0601a8c0@pc6> X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit 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 Hi Tom, Comments inline. > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Tom Petch > Sent: Friday, June 03, 2005 9:32 AM > To: isms@ietf.org > Subject: [Isms] SSH in TMSM > [...] > > I did wonder why the tmStateReference should be passing so > much information > about the session to the MPSP; I would have expected the > master secret, eg, to > have stayed in the TMSP The requirements of ISMS are not clear regarding sessions. The RFC3411 architecture does not have sessions, so if sessions are only supported at the transport mapping, and are not seen by the applications or the messaging subsystems, then the session data should not need to be passed to the MPSP. > > I also wonder about the multiplexing of upper layers onto > lower. SSH has > connections and I have assumed that SNMP uses them and so the > state includes a > channel number, as opposed to using raw ssh transport. But > for TLS, application > data > seems to map directly onto the TLS Record Protocol with no intervening > multiplexing. RFC3413 applications make the transport address decision, such as whether to use UDP port 161 or port 162. There is little discussion about how the application knows which transport mappings exist and should be used, unless the RFC3413 MIB modules are used. For Responses, the Command Responder sends the stateReference to the dispatcher via returnResponsePDU(); stateReference is a "reference to state information needed when sending a response." The RFC3413 applications do not support sessions or channels, unless that information is passed in the stateReference, or made available via the SNMP-TARGET-MIB suite. If sessions or channels can somehow be encoded into a transportDomain and transportAddress, they could fit into the existing stateReference and SNMP-TARGET-MIB suite. Whether various expectations of usage would fit into stateReference and the RFC3413 MIB modules is another thing. I expect the RFC3413 MIB modules are SET with a static configuration, representing administrative policy; I don't know how dynamic sessions can be configured into those MIB modules. If the expectation is that different SSH connections or channels will be used for request/response traffic and for notifications (Cf: ports 161/162), then the information "needed when sending a response" must be passed in the stateReference, and for non-response messages, the applications need to know how to request the different channels, and need to make the distinction in the transportDomain/transportaddress parameters of sendPDU(). RFC3430 discusses some issues regarding connections. I think that the description of a transport-mapping for snmp-over-TLS or snmp-over-SSH would probably need to be as comprehensive as RFC3430. Such a transport mapping should include definition of a suitable trasnportDomain and transportAddress format, how to manage connections, how to use the RFC3413 MIB modules to store (dynamically-generated-channel) addresses for RFC3413 applications, and the security considerations. If the expectation is that different SSH connections/channels are used for different securityLevels, then the same applies. However, the RFC3413 applications do not know how to decide which securityLevel is needed for different types of data, so a new application model would probably need to be written that describes how the channel selection is made based on data sensitivity, and it would need to be discussed how the application would register itself with the dispatcher (new verbs - GETsensitive and GETinsensitive??). That is definitely outside the scope of this WG. 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 Jun 06 06:07:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfEW5-0000Jd-Hf; Mon, 06 Jun 2005 06:07:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfEW3-0000J8-Ql for isms@megatron.ietf.org; Mon, 06 Jun 2005 06:07:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15569 for ; Mon, 6 Jun 2005 06:07:29 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfEqt-000584-13 for isms@ietf.org; Mon, 06 Jun 2005 06:29:03 -0400 Received: from pc6 (1Cust154.tnt109.lnd4.gbr.da.uu.net [62.188.172.154]) by galaxy.systems.pipex.net (Postfix) with SMTP id 4E1C2E0002D4; Mon, 6 Jun 2005 11:07:20 +0100 (BST) Message-ID: <02fa01c56a76$7f4c01e0$0601a8c0@pc6> From: "Tom Petch" To: , References: <20050603174756.ADFFAE000087@robin.systems.pipex.net> Subject: Re: [Isms] SSH in TMSM Date: Mon, 6 Jun 2005 11:01:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Interesting; time I think to split this thread. A basic SSH question, what I wanted to clarify when I wrote my comment; do applications running over SSH always use connections or do some, those in no need of what connections have to offer, run direct over ssh-transport, with or without using ssh-userauth? As I said earlier, I saw ssh as ssh-architecture, ssh-transport, ssh-connect?, ssh-userauth. I put it as 'ssh-connect?' because I was not clear if connections were always used, were regarded as a part of a conformant stack. Anyone know? Tom Petch ----- Original Message ----- From: "David B Harrington" To: "'Tom Petch'" ; Sent: Friday, June 03, 2005 7:47 PM Subject: RE: [Isms] SSH in TMSM > Hi Tom, > > Comments inline. > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Tom Petch > > Sent: Friday, June 03, 2005 9:32 AM > > To: isms@ietf.org > > Subject: [Isms] SSH in TMSM > > > [...] > > > > I did wonder why the tmStateReference should be passing so > > much information > > about the session to the MPSP; I would have expected the > > master secret, eg, to > > have stayed in the TMSP > > The requirements of ISMS are not clear regarding sessions. The RFC3411 > architecture does not have sessions, so if sessions are only supported > at the transport mapping, and are not seen by the applications or the > messaging subsystems, then the session data should not need to be > passed to the MPSP. > > > > I also wonder about the multiplexing of upper layers onto > > lower. SSH has > > connections and I have assumed that SNMP uses them and so the > > state includes a > > channel number, as opposed to using raw ssh transport. But > > for TLS, application > > data > > seems to map directly onto the TLS Record Protocol with no > intervening > > multiplexing. > > RFC3413 applications make the transport address decision, such as > whether to use UDP port 161 or port 162. There is little discussion > about how the application knows which transport mappings exist and > should be used, unless the RFC3413 MIB modules are used. For > Responses, the Command Responder sends the stateReference to the > dispatcher via returnResponsePDU(); stateReference is a "reference to > state information needed when sending a response." > > The RFC3413 applications do not support sessions or channels, unless > that information is passed in the stateReference, or made available > via the SNMP-TARGET-MIB suite. > > If sessions or channels can somehow be encoded into a transportDomain > and transportAddress, they could fit into the existing stateReference > and SNMP-TARGET-MIB suite. Whether various expectations of usage would > fit into stateReference and the RFC3413 MIB modules is another thing. > I expect the RFC3413 MIB modules are SET with a static configuration, > representing administrative policy; I don't know how dynamic sessions > can be configured into those MIB modules. > > If the expectation is that different SSH connections or channels will > be used for request/response traffic and for notifications (Cf: ports > 161/162), then the information "needed when sending a response" must > be passed in the stateReference, and for non-response messages, the > applications need to know how to request the different channels, and > need to make the distinction in the transportDomain/transportaddress > parameters of sendPDU(). > > RFC3430 discusses some issues regarding connections. I think that the > description of a transport-mapping for snmp-over-TLS or snmp-over-SSH > would probably need to be as comprehensive as RFC3430. Such a > transport mapping should include definition of a suitable > trasnportDomain and transportAddress format, how to manage > connections, how to use the RFC3413 MIB modules to store > (dynamically-generated-channel) addresses for RFC3413 applications, > and the security considerations. > > If the expectation is that different SSH connections/channels are used > for different securityLevels, then the same applies. However, the > RFC3413 applications do not know how to decide which securityLevel is > needed for different types of data, so a new application model would > probably need to be written that describes how the channel selection > is made based on data sensitivity, and it would need to be discussed > how the application would register itself with the dispatcher (new > verbs - GETsensitive and GETinsensitive??). That is definitely outside > the scope of this WG. > > David Harrington > dbharrington@comcast.net > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jun 07 15:46:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfk2H-0006gY-Qt; Tue, 07 Jun 2005 15:46:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfk2G-0006eN-E8 for isms@megatron.ietf.org; Tue, 07 Jun 2005 15:46:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26534 for ; Tue, 7 Jun 2005 15:46:50 -0400 (EDT) Message-Id: <200506071946.PAA26534@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfkNL-0003RO-CD for isms@ietf.org; Tue, 07 Jun 2005 16:08:41 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <2005060719401601300fsodne>; Tue, 7 Jun 2005 19:40:16 +0000 From: "David B Harrington" To: Subject: RE: [Isms] draft-schoenw-snmp-tlsm-02.txt Date: Tue, 7 Jun 2005 15:40:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVm7nfpeK+rY8jFQESL2zsO5ukgWgEoE3YA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit 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 Hi Sam, I am having difficulty reconciling my understanding of how an SNMP agent works, and the terminology you have used in your comments. Please help me to bridge the gap. You talk about "agents capable of accepting commands using ssh for authentication" . As I see the SNMP approach, commands are the payload encapsulated within an SNMP message, and a message is authenticated as having been sent on behalf of a known user. I envision SSH providing the transport of SNMP messages, and authenticating the message as having been sent on behalf of a known user. Do you mean "agents capable of accepting SNMP messages using SSH for authentication"? You say "agents ... will have sufficient credentials". The user's credentials are somehow made available to the authentication process implemented within the agent (or are made available to an authentication process external to the engine, such as RADIUS), and the authentication process uses the credentials to verify the identity of the user, but the agent does not itself have SNMP-related credentials to identify itself (although it may have non-SNMP-related crdentials, e.g. RADIUS-client credentials). Do you mean "agents will have (access to) sufficient credentials to authenticate the message as having been sent on behalf of the claimed user"? In the TMSM approach, the agent may not have the credentials at all. A lower layer security mechanism (SSH) would have access to the credentials and perform the authentication, and the SNMP engine would only have a mechanism to accept an assertion from the lower layer security mechanism that suitable authentication has been performed and the message is asserted as being authentic and on behalf of a known identity. I don't understand your comment about utilizing host keys for userauth for outbound authentication, and how that relates to SNMP-related message authentication. Can you expand on this? Recognize that SNMPv3 provides user-based access control for notifications, so a user not authorized to GET the value of a variable cannot typically gain access to the value of that variable using a notification. You probably do not want to support user-based authentication for access control for request/response operations, but only use host-based authentication for access control for notifications. Am I correct in reading your second sentence as meaning, "What I'm less clear about is whether administrators will typically have a mechanism (in SSH or SNMP) to authorize these credentials to be used when an SNMP notification generator application generates notifications."? If that is what you mean, then a MIB module (such as those found in RFC3413) might be able to provide the user interface for the administrator. I am not clear whether the administrator (or the SNMP engine) has sufficient access to the SSH credentials (or a way to reference an appropriate set of unseen SSH credentials) to be able to populate a MIB module. 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: Wednesday, June 01, 2005 5:08 PM > To: David B Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt > > I suspect in many environments agents capable of accepting commands > using ssh for authentication will have sufficient credentials to do > outbound authentication. This is because host keys are also useful > for ssh userauth. > > What I'm less clear about is whether people will typically be able to > authorize these credentials to generate notifications. > > _______________________________________________ > 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 Jun 09 02:09:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgGEj-0001nZ-HD; Thu, 09 Jun 2005 02:09:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgGEi-0001nP-MI for isms@megatron.ietf.org; Thu, 09 Jun 2005 02:09:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13709 for ; Thu, 9 Jun 2005 02:09:51 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgGZd-0002MP-MY for isms@ietf.org; Thu, 09 Jun 2005 02:31:30 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j5968leQ007056; Wed, 8 Jun 2005 23:08:47 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j5968iEH014639; Wed, 8 Jun 2005 23:08:44 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j5968hjY014635; Wed, 8 Jun 2005 23:08:43 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 8 Jun 2005 23:08:43 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: David B Harrington Subject: RE: [Isms] draft-schoenw-snmp-tlsm-02.txt In-Reply-To: <200506010342.XAA23104@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: 'Sam Hartman' , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, I believe that continuing to use USM for notifications would be a VERY bad choice. Having spent the last 6 months adding support for SNMPv3/USM to a product, the MOST troubling part is explaining to people the concept of "authoritative engineID" and then explaining that for traps, the sender is the authoritative engine, but for informs the receiver is the authoritative engine, which requires a double configuration of user entries in the USM user table. Give me a fricking break! Then, look at the silly engineID discovery that is done on sending informs. Who designed this stuff? This issue just drive me crazy. Hardly anyone understands the need to authoritative engineID. Many, if not all, would not believe that it is technically possible for either side to be the authoritative engine, and could not list the trade-offs for each side. (I'm stopping now...) I truely believe that if a reasonable ISMS definition is developed, that no one will use USM, if given the choice between USM and ISMS. Enjoy, /david t. perkins On Tue, 31 May 2005, David B Harrington wrote: > Hi Sam, > > I would use SSH as it was designed to be used. > > I am not very knowledgeable about the SSH suite, but I would expect to > use the SSH transport layer, and the SSH authentication protocol. > > Netconf also runs over SSH, using the SSH transport and > authentication; then the SSH connection protocol creates a session, > and runs an SSH subsystem called netconf. I expect something > comparable for SNMP. I consider it desirable to utilize a similar > approach between netconf and SNMP, to the degree the two management > protocols are similar. > > I have not worked on the details of how the binary formatted SNMP > messages might impact the SSH approach differently than the netconf > approach. > > Netconf punted on the notification channel because not all their > "transports" could handle such a thing. SNMP obviously requires > notification capabilities, so we'd need to determine how that could be > done with SSH, as with any other possible transport layer security > protocols. > > If it is difficult to make protocols not designed to support > notifications meet notification requirements, and it is expected that > USM will continue to be deployed for troubleshooting purposes when a > TMSM solution is deployed for non-troubleshooting purposes, it might > be reasonable to expect that notifications be sent using the USM > security model rather than the TMSM security model. The cost of USM > configuration for a security association with one or a few > presumably-centralized notification receiver applications would be > small compared to configuring the notification and filter tables and > the VACM access tables of the SNMP engine, and once a security > association is created between a "manager" and "agent" using TMSM, it > should be easy to configure USM "users" that represent the > notification receiver applications. > > David Harrington > dbharrington@comcast.net > > > -----Original Message----- > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > Sent: Tuesday, May 31, 2005 10:40 PM > > To: dbharrington@comcast.net > > Cc: 'Tom Petch'; isms@ietf.org > > Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt > > > > >>>>> "David" == David B Harrington > writes: > > > > David> Hi Tom, TLS is "transport layer security", so it appears > to > > David> me to be categorized as being an extension of the > transport > > David> layer. But I could be wrong. > > > > David> SSH, SASL, BEEP, and other security-related protocols > that > > David> are often layered atop TLS seem to be application layer > > David> protocols. > > > > David> I would be happy to modify the document to reflect the > > David> official categories. > > > > > > I think it doesn't matter so much what we call tls or ssh. Tom's > > question still stands: how do you see ssh interacting with your > > protocol? > > > > Are you expecting to use the ssh authentication protocol without the > > ssh transport? I don't think that's within the scope of that > > protocol. > > > > > > _______________________________________________ > 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 Jun 09 02:46:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgGnk-0007al-Bc; Thu, 09 Jun 2005 02:46:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgGni-0007ag-ND for isms@megatron.ietf.org; Thu, 09 Jun 2005 02:46:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27251 for ; Thu, 9 Jun 2005 02:46:01 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgH8c-0003FP-TQ for isms@ietf.org; Thu, 09 Jun 2005 03:07:40 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j596j8eQ018054; Wed, 8 Jun 2005 23:45:08 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j596j5Sn020260; Wed, 8 Jun 2005 23:45:05 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j596j4eF020251; Wed, 8 Jun 2005 23:45:05 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 8 Jun 2005 23:45:03 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Juergen Schoenwaelder Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt In-Reply-To: <20050601171147.GD29036@boskop.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: dbharrington@comcast.net, Sam Hartman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, Juegen - VERY WELL said! However, I tried to do this at the last IETF, and found that the security experts don't talk to each other. Consider a group in, say, the security area saying we need help from the management folks in working out how to use these management protocols of SNMP, CMIP, COPS, etc. (Hope this example is illustrative!) On Wed, 1 Jun 2005, Juergen Schoenwaelder wrote: > On Wed, Jun 01, 2005 at 10:00:11AM -0700, Fleischman, Eric wrote: > > > [...] SSL/TLS operate at the transport layer. Secure Shell (SSH) > > operates at the application layer. > > I do not necessarily agree to this distinction nor do I believe such > a distinction is in any way useful. The real question is indeed what > is authenticated where by which mechanism and how to leverage this > (if we want to leverage this). And finding answers to this question > requires to dive into concrete details since there is no abstract > architectural answer here as far as I can tell. And we really need > security experts who know TLS, SSH, SASL, you name it inside out > to sit together with SNMP folks to figure out the details. > > Any volunteers? Can the chairs help to organize this? > > /js > Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jun 09 07:24:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgL8r-0001ZP-Tg; Thu, 09 Jun 2005 07:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgL8q-0001Z6-1Z for isms@megatron.ietf.org; Thu, 09 Jun 2005 07:24:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14062 for ; Thu, 9 Jun 2005 07:24:06 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgLOl-0004V8-58 for isms@ietf.org; Thu, 09 Jun 2005 07:40:36 -0400 Received: from pc6 (1Cust88.tnt9.lnd4.gbr.da.uu.net [62.188.138.88]) by blaster.systems.pipex.net (Postfix) with SMTP id 89E65E000197; Thu, 9 Jun 2005 12:17:50 +0100 (BST) Message-ID: <01be01c56cdc$8303dac0$0601a8c0@pc6> From: "Tom Petch" To: "David T. Perkins" References: Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt Date: Thu, 9 Jun 2005 11:42:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.9 (++) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I have many times explained authoritative engine ids to users and know well the bewildered look on their faces. But the idea I think sound, and this has been reinforced by my recent exploration of SSH and TLS. Both are strongly asymmetric. SSH has host key (ie server) built in and crucial (I was going to say key) whereas going the other way, client authentication is a separate, optional protocol. Likewise in TLS, it is the server certificate that is fundamental, the server may ask for a client certificate. Sad thing is, this is back to front (for me). My #1 want is client authentication when acting as a Command Generator and this SSH and TLS seem to consider optional; whereas server authentication I can live without.. Tom Petch ----- Original Message ----- From: "David T. Perkins" To: "David B Harrington" Cc: "'Sam Hartman'" ; Sent: Thursday, June 09, 2005 8:08 AM Subject: RE: [Isms] draft-schoenw-snmp-tlsm-02.txt > HI, > > I believe that continuing to use USM for notifications would > be a VERY bad choice. Having spent the last 6 months adding > support for SNMPv3/USM to a product, the MOST troubling > part is explaining to people the concept of "authoritative > engineID" and then explaining that for traps, the sender > is the authoritative engine, but for informs the receiver > is the authoritative engine, which requires a double > configuration of user entries in the USM user table. > > Give me a fricking break! > > Then, look at the silly engineID discovery that is done > on sending informs. Who designed this stuff? > > This issue just drive me crazy. Hardly anyone understands > the need to authoritative engineID. Many, if not all, > would not believe that it is technically possible for > either side to be the authoritative engine, and could > not list the trade-offs for each side. > (I'm stopping now...) > > I truely believe that if a reasonable ISMS definition > is developed, that no one will use USM, if given the > choice between USM and ISMS. > > Enjoy, > /david t. perkins > On Tue, 31 May 2005, David B Harrington wrote: > > Hi Sam, > > > > I would use SSH as it was designed to be used. > > > > I am not very knowledgeable about the SSH suite, but I would expect to > > use the SSH transport layer, and the SSH authentication protocol. > > > > Netconf also runs over SSH, using the SSH transport and > > authentication; then the SSH connection protocol creates a session, > > and runs an SSH subsystem called netconf. I expect something > > comparable for SNMP. I consider it desirable to utilize a similar > > approach between netconf and SNMP, to the degree the two management > > protocols are similar. > > > > I have not worked on the details of how the binary formatted SNMP > > messages might impact the SSH approach differently than the netconf > > approach. > > > > Netconf punted on the notification channel because not all their > > "transports" could handle such a thing. SNMP obviously requires > > notification capabilities, so we'd need to determine how that could be > > done with SSH, as with any other possible transport layer security > > protocols. > > > > If it is difficult to make protocols not designed to support > > notifications meet notification requirements, and it is expected that > > USM will continue to be deployed for troubleshooting purposes when a > > TMSM solution is deployed for non-troubleshooting purposes, it might > > be reasonable to expect that notifications be sent using the USM > > security model rather than the TMSM security model. The cost of USM > > configuration for a security association with one or a few > > presumably-centralized notification receiver applications would be > > small compared to configuring the notification and filter tables and > > the VACM access tables of the SNMP engine, and once a security > > association is created between a "manager" and "agent" using TMSM, it > > should be easy to configure USM "users" that represent the > > notification receiver applications. > > > > David Harrington > > dbharrington@comcast.net > > > > > -----Original Message----- > > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > > Sent: Tuesday, May 31, 2005 10:40 PM > > > To: dbharrington@comcast.net > > > Cc: 'Tom Petch'; isms@ietf.org > > > Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt > > > > > > >>>>> "David" == David B Harrington > > writes: > > > > > > David> Hi Tom, TLS is "transport layer security", so it appears > > to > > > David> me to be categorized as being an extension of the > > transport > > > David> layer. But I could be wrong. > > > > > > David> SSH, SASL, BEEP, and other security-related protocols > > that > > > David> are often layered atop TLS seem to be application layer > > > David> protocols. > > > > > > David> I would be happy to modify the document to reflect the > > > David> official categories. > > > > > > > > > I think it doesn't matter so much what we call tls or ssh. Tom's > > > question still stands: how do you see ssh interacting with your > > > protocol? > > > > > > Are you expecting to use the ssh authentication protocol without the > > > ssh transport? I don't think that's within the scope of that > > > protocol. > > > > > > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jun 09 08:34:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgMF1-0002PA-Qs; Thu, 09 Jun 2005 08:34:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgMF0-0002P5-K4 for isms@megatron.ietf.org; Thu, 09 Jun 2005 08:34:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22418 for ; Thu, 9 Jun 2005 08:34:33 -0400 (EDT) Received: from 66-163-8-251.ip.tor.radiant.net ([66.163.8.251] helo=SMTP.Lamicro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgMaN-0000Ef-5q for isms@ietf.org; Thu, 09 Jun 2005 08:56:45 -0400 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO0058A6; 9 Jun 2005 08:35:12 -0400 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 9 Jun 2005 08:34:16 -0400 Received: from connotech.com (209.71.204.103) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG0058A5; 9 Jun 2005 08:34:11 -0400 Message-ID: <42A83DCC.4090305@connotech.com> Date: Thu, 09 Jun 2005 09:02:04 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Petch Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt References: <01be01c56cdc$8303dac0$0601a8c0@pc6> In-Reply-To: <01be01c56cdc$8303dac0$0601a8c0@pc6> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.3 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Tom Petch wrote: > [...I did ...] recent > exploration of SSH and TLS. Both are strongly asymmetric. SSH has host key (ie > server) built in and crucial (I was going to say key) whereas going the other > way, client authentication is a separate, optional protocol. Likewise in TLS, > it is the server certificate that is fundamental, the server may ask for a > client certificate. This is where the zero-client-preconfiguration magic originates (e.g. unauthenticated web client browsing is nonetheless "secure" according to consultant-backed risk analyses). A party's authentication requires this party's pre-configuration. > Sad thing is, this is back to front (for me). My #1 want is client > authentication when acting as a Command Generator and this SSH and TLS seem to > consider optional; whereas server authentication I can live without.. The goal of isms has been stated as *zero* incremental authentication configuration requirement. Perhaps you need that your definition of SNMP client to be the exact same as the one in some AAA scheme. Then you would look at the AAA details to see if you can piggyback the SNMP application on it. If any isms-specific authentication pre-configuration is totally out of the picture, I don't see another way. Sincerely, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jun 14 21:43:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiMw4-0005IE-NI; Tue, 14 Jun 2005 21:43:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiMw3-0005I2-43 for isms@megatron.ietf.org; Tue, 14 Jun 2005 21:43:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25821 for ; Tue, 14 Jun 2005 21:43:17 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiNIe-0002Wc-EI for isms@ietf.org; Tue, 14 Jun 2005 22:06:40 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 39316E0063; Tue, 14 Jun 2005 21:43:13 -0400 (EDT) To: "David T. Perkins" Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt References: From: Sam Hartman Date: Tue, 14 Jun 2005 21:43:13 -0400 In-Reply-To: (David T. Perkins's message of "Wed, 8 Jun 2005 23:45:03 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: dbharrington@comcast.net, 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 T Perkins writes: David> HI, Juegen - VERY WELL said! David> However, I tried to do this at the last IETF, and found David> that the security experts don't talk to each other. David> Consider a group in, say, the security area saying we need David> help from the management folks in working out how to use David> these management protocols of SNMP, CMIP, COPS, etc. (Hope David> this example is illustrative!) There's a reason Ken is a co-chair of this working group. He has enough experience with ssh, tls, SASL and Kerberos that I think he can answer these sorts of questions. So can ekr. I think I can too. I think Joe Salowey (who I believe was following ISMS at least at IETF 62) can do so too. All of these people should understand tls, sasl, ssh enough to explain difference. A good subset understand IPsec, EAP and DTLS. I am personally not following things closely enough that I'm guaranteed to catch specific unanswered questions. I'd rather not be the primary explainer of security protocols to ISMS although I'd prefer to take on that role instead of seeing ISMS fail. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jun 18 17:31:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Djkuh-0003mM-2I; Sat, 18 Jun 2005 17:31:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Djkuf-0003k1-Gf for isms@megatron.ietf.org; Sat, 18 Jun 2005 17:31:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15176 for ; Sat, 18 Jun 2005 17:31:34 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjlI1-0001u5-Am for isms@ietf.org; Sat, 18 Jun 2005 17:55:47 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 5DD36E0066; Sat, 18 Jun 2005 17:31:25 -0400 (EDT) To: Tom Petch Subject: Re: [Isms] SSH in TMSM References: <20050603174756.ADFFAE000087@robin.systems.pipex.net> <02fa01c56a76$7f4c01e0$0601a8c0@pc6> From: Sam Hartman Date: Sat, 18 Jun 2005 17:31:25 -0400 In-Reply-To: <02fa01c56a76$7f4c01e0$0601a8c0@pc6> (Tom Petch's message of "Mon, 6 Jun 2005 11:01:52 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Tom" == Tom Petch writes: Tom> Interesting; time I think to split this thread. A basic SSH Tom> question, what I wanted to clarify when I wrote my comment; Tom> do applications running over SSH always use connections or do Tom> some, those in no need of what connections have to offer, run Tom> direct over ssh-transport, with or without using Tom> ssh-userauth? I'd generally expect anything in this space to be an ssh subsystem (and thus use the connection protocol). I don't think that would be required; you could presumably start another service besides the connection protocol, but I don't see why you would. Implementing your own service would involve more complexity, more coordination for assigned numbers and more implementation complexity. I'd look at netconf and sftp as examples of how to implement a subsystem. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jun 18 17:40:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Djl3i-00051A-76; Sat, 18 Jun 2005 17:40:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Djl3h-000515-0j for isms@megatron.ietf.org; Sat, 18 Jun 2005 17:40:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15757 for ; Sat, 18 Jun 2005 17:40:53 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjlR4-0002GH-U0 for isms@ietf.org; Sat, 18 Jun 2005 18:05:07 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 0CEE6E0066; Sat, 18 Jun 2005 17:40:50 -0400 (EDT) To: ietfdbh@comcast.net Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt References: <200506071946.PAA26534@ietf.org> From: Sam Hartman Date: Sat, 18 Jun 2005 17:40:50 -0400 In-Reply-To: <200506071946.PAA26534@ietf.org> (David B. Harrington's message of "Tue, 7 Jun 2005 15:40:12 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Sam, I am having difficulty reconciling my understanding David> of how an SNMP agent works, and the terminology you have David> used in your comments. Please help me to bridge the gap. David> You talk about "agents capable of accepting commands using David> ssh for authentication" . As I see the SNMP approach, David> commands are the payload encapsulated within an SNMP David> message, and a message is authenticated as having been sent David> on behalf of a known user. So far, I agree. David> I envision SSH providing the David> transport of SNMP messages, and authenticating the message David> as having been sent on behalf of a known user. I'm not sure user is the right term here particularly when looking at notifications. David> Do you mean David> "agents capable of accepting SNMP messages using SSH for David> authentication"? No I'm not sure that means the same thing. I mean what I said;) David> You say "agents ... will have sufficient credentials". The David> user's credentials are somehow made available to the I mean agents as an architectural entity, including any security services they rely on. So yes, the credential may be part of the TLS implementation or the ssh implementation. But the point is that if I'm going to contact an agent and send it a command, there is some credential involved on the agent accepting the command. In USM, the credential is user (and engineid ) specific. For a typical ssh cli session and thus presumably for a typical ssh SNMP session if that ever exists, there is a host key or GSS credential the agent uses to authenticate the server side of the credential. Really agent is the wrong term here; I need a term that encompases the whole engine and the security transport that it is using. My point though is that if you can accept commands you have some credential. It turns out that ssh server credentials are roughly symmetric and can be used as ssh client credentials. The same is not true for client credentials: most ssh clients do not have a sufficient credential to act as an ssh server. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jun 20 06:15:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkJJP-0003bV-RH; Mon, 20 Jun 2005 06:15:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkJJO-0003b8-JK for isms@megatron.ietf.org; Mon, 20 Jun 2005 06:15:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11454 for ; Mon, 20 Jun 2005 06:15:24 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkJh4-0004if-SB for isms@ietf.org; Mon, 20 Jun 2005 06:39:56 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 4E54FE0066; Mon, 20 Jun 2005 06:15:13 -0400 (EDT) To: Tom Petch Subject: Re: [Isms] SSH in TMSM References: <200506012034.QAA06882@ietf.org> <033401c56779$204f5160$0601a8c0@pc6> <001501c56840$b35c6660$0601a8c0@pc6> From: Sam Hartman Date: Mon, 20 Jun 2005 06:15:13 -0400 In-Reply-To: <001501c56840$b35c6660$0601a8c0@pc6> (Tom Petch's message of "Fri, 3 Jun 2005 15:32:08 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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've read this and it seems sort of OK as far as it goes, but it doesn't deal with the tricky bits such as what connection subsystem is used and the over-the-wire encoding of messages. I think that exposing the authentication/integrity protocol, the confidentiality protocol, and some of the other ssh parameters exposes too much low-level ssh state to higher levels. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jun 24 13:49:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlsJS-0000i6-G9; Fri, 24 Jun 2005 13:49:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlsJR-0000ht-Eo for isms@megatron.ietf.org; Fri, 24 Jun 2005 13:49:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28701 for ; Fri, 24 Jun 2005 13:49:56 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlsi1-0003hn-3e for isms@ietf.org; Fri, 24 Jun 2005 14:15:21 -0400 Received: from pc6 (1Cust118.tnt101.lnd4.gbr.da.uu.net [213.116.50.118]) by blaster.systems.pipex.net (Postfix) with SMTP id EAD8EE0000B9; Fri, 24 Jun 2005 18:49:34 +0100 (BST) Message-ID: <036201c578dc$ac3638a0$0601a8c0@pc6> From: "Tom Petch" To: , "Sam Hartman" References: <200506071946.PAA26534@ietf.org> Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt Date: Fri, 24 Jun 2005 18:48:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Sam Hartman" To: Sent: Saturday, June 18, 2005 11:40 PM Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt > >>>>> "David" == David B Harrington writes: > David> I envision SSH providing the > David> transport of SNMP messages, and authenticating the message > David> as having been sent on behalf of a known user. > > I'm not sure user is the right term here particularly when looking at > notifications. > I think the right term is principal. SNMP Architecture (RFC 3411) defines all activitities as taking place on behalf of a principal, who/which is identified by a (model independent) securityName, an abstract concept but something outside the snmp entity (a bit like users versus user agents in e-mail). In the USM, the principal is a user, but given the use of securityName in the interchanges between elements of the model, the idea of principal is part of the architecture and not part of USM and so is a given for isms, whatever security model is used; the architecture implies that it is a principal that has security credentials. (I do not think this fits well with transport level security, where servers have host keys and principals do not feature). > David> Do you mean > David> "agents capable of accepting SNMP messages using SSH for > David> authentication"? > > No I'm not sure that means the same thing. I mean what I said;) Again, SNMP Architecture defines messages as the unit (containing a SNMP PDU) which the security model sends on its way, not commands. > > David> You say "agents ... will have sufficient credentials". The > David> user's credentials are somehow made available to the > > I mean agents as an architectural entity, including any security > services they rely on. So yes, the credential may be part of the TLS > implementation or the ssh implementation. But the point is that if > I'm going to contact an agent and send it a command, there is some > credential involved on the agent accepting the command. In USM, the > credential is user (and engineid ) specific. For a typical ssh cli > session and thus presumably for a typical ssh SNMP session if that > ever exists, there is a host key or GSS credential the agent uses to > authenticate the server side of the credential. > > Really agent is the wrong term here; I need a term that encompases the > whole engine and the security transport that it is using. There isn't such a term at present:-) SNMP Architecture defines SNMP engine (dispatcher, message processing, access control, security subsystem) and SNMP entity (SNMP engine plus SNMP applications); the transport, secure or not, is beyond the pale. We can invent terms for engine+transport or entity+transport but their absence from SNMP Architecture will always leave some inconsistency. > My point though is that if you can accept commands you have some > credential. It turns out that ssh server credentials are roughly > symmetric and can be used as ssh client credentials. The same is not > true for client credentials: most ssh clients do not have a sufficient > credential to act as an ssh server. > I agree but the credentials are of the server and have to be made into something principal related because that is what SNMP Architecture says. So, I wish the SNMP Architecture did not say what it does, but it does, and that is where we are:-( _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jun 24 15:52:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DluEK-00060g-Pj; Fri, 24 Jun 2005 15:52:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DluEJ-00060O-LD for isms@megatron.ietf.org; Fri, 24 Jun 2005 15:52:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09351 for ; Fri, 24 Jun 2005 15:52:46 -0400 (EDT) Message-Id: <200506241952.PAA09351@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.89]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlucu-0008C9-9A for isms@ietf.org; Fri, 24 Jun 2005 16:18:13 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <2005062419523601400ma5gle>; Fri, 24 Jun 2005 19:52:37 +0000 From: "David B Harrington" To: "'Tom Petch'" , "'Sam Hartman'" Date: Fri, 24 Jun 2005 15:52:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcV45RetiKvOCcuSTa2B4q0ESP7j5QAA2bag X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <036201c578dc$ac3638a0$0601a8c0@pc6> X-Spam-Score: 0.1 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: [Isms] Authentication and access control requirements 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, Tom, thanks for acting as interpreter. I agree with almost everything you interpreted. It's close enough that I choose not to spend time correcting the minor differences. I'd rather discuss the SNMPv3 philosophy, and how that relates to the current issues. In SNMPv3, we deliberately provided for application-specific (SNMP) authentication of the principal, because it is that authenticated principal to which the application-specific access control is applied. The operators who provided input to the SNMPv3 design process requested the ability to distinguish users, so they could control and audit who made which modifications to a device via SNMP. Some felt that authenticating an application (such as HPOV) was adequate for many purposes, where a specific application is used to configure certain aspects of network behavior via SNMP. It might be acceptable to have a combinations of users and applications authenticated. Authenticating a notification receiver application might be sufficient, but operators would need to be careful about the information contained in notification varbinds to ensure that information not read-accessible to a user-principal is not revealed to the user via an application-principal. I don't recall proponents for authenticating at the host level (except for making the ASIs capable of passing transport info for backwards-compatibility reasons). At the time, certificates were not being used widely for the types of devices SNMP managed, and would have been (and still frequently are) considered heavy-weight for low-end SNMP-manageable devices. The consensus was that the SNMPv1 approach of authenticating based on a source address was inadequately secure for access control and auditing purposes, as well as being hard to achieve given address spoofing, DHCP, NAT, and so on. We deliberately did not include transport info in the ASIs between the transport-mapping and the secuirty models to discourage the very-weak authentication based on source-address. Trying to leverage an existing transport-layer authentication infrastructure, there are a number of different approaches we could use. 1) We could provide for two levels of authentication - one to authenticate the message, and the other to authenticate the SNMP principal for access control purposes. Thus it would be possible to use TLS or SSH or IPSec to transport the message securely, and then use another mechanism to authenticate the SNMP principal. There are problems of getting an appropriate binding to prevent masquerade, but that is one approach we could use. Of course, if we need to have an SNMP-specific principal authentication anyway, then we might as well use it to secure the message as well, as was done with USM. 2) We can have one level of authentication, that serves to authenticate both the message and the principal to which we can apply SNMP-specific access control. 2a) If the transport-layer "principal" is a host, and we used the same principal for the SNMP-access control, the granularity may not be adequate for the requested SNMP access control and auditing. 2b) If the transport "principal" is an application, such as an authenticated SSH-client, that may be adequate for both SNMP access control and auditing, if access control/auditing at the application granularity is adequate; I am of the impression it would not meet operators' requirements. It may be adequate if the application has the responsibility of authenticating the user that logs into the application, and that is considered "good enough" for access control and auditing purposes. 2c) If the principal is a user, such as an operator, that seems to best meet the requirements that the operators identified. The SNMPv3 (USM) approach is to provide the ability to identify a principal that might be a user, an application, or a host (or other "principal" of whatever nature. Ideally, a transport-layer security model would permit the same levels of authentication where desired. It might be possible to use SSH hostbased authentication. According to http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-secsh-use rauth-27.txt, section 9, "Once the client host's identity is established, authorization (but no further authentication) is performed based on the user names on the server and the client, and the client host name." Note that the Internet Draft says the hostbased "form of authentication is not suitable for high-security sites". If we permit different types of authentication in SSH, we may need to have different security models or the ability to assign securityLevels based on the approach, so the access control system can be configured accordingly. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Friday, June 24, 2005 12:49 PM > To: ietfdbh@comcast.net; Sam Hartman > Cc: isms@ietf.org > Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt > > > Tom Petch > ----- Original Message ----- > From: "Sam Hartman" > To: > Sent: Saturday, June 18, 2005 11:40 PM > Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt > > > > >>>>> "David" == David B Harrington writes: > > > David> I envision SSH providing the > > David> transport of SNMP messages, and authenticating > the message > > David> as having been sent on behalf of a known user. > > > > I'm not sure user is the right term here particularly when > looking at > > notifications. > > > I think the right term is principal. SNMP Architecture (RFC > 3411) defines all > activitities as taking place on behalf of a principal, > who/which is identified > by a (model > independent) securityName, an abstract concept but something > outside the snmp > entity (a bit like users versus user agents in e-mail). In > the USM, the > principal is a user, but given the use of securityName in the > interchanges > between elements of the model, the idea of principal is part > of the architecture > and not part of USM and so is a given for isms, whatever > security model is used; > the architecture implies that it is a principal that has > security credentials. > (I do not think this fits well with transport level security, > where servers have > host keys and principals do not feature). > > > David> Do you mean > > David> "agents capable of accepting SNMP messages using SSH for > > David> authentication"? > > > > No I'm not sure that means the same thing. I mean what I said;) > > Again, SNMP Architecture defines messages as the unit > (containing a SNMP PDU) > which the security model sends on its way, not commands. > > > > David> You say "agents ... will have sufficient > credentials". The > > David> user's credentials are somehow made available to the > > > > I mean agents as an architectural entity, including any security > > services they rely on. So yes, the credential may be part > of the TLS > > implementation or the ssh implementation. But the point is that if > > I'm going to contact an agent and send it a command, there is some > > credential involved on the agent accepting the command. In USM, the > > credential is user (and engineid ) specific. For a typical ssh cli > > session and thus presumably for a typical ssh SNMP session if that > > ever exists, there is a host key or GSS credential the agent uses to > > authenticate the server side of the credential. > > > > Really agent is the wrong term here; I need a term that > encompases the > > whole engine and the security transport that it is using. > > There isn't such a term at present:-) SNMP Architecture > defines SNMP engine > (dispatcher, message processing, access control, security > subsystem) and SNMP > entity (SNMP engine plus SNMP applications); the transport, > secure or not, is > beyond the pale. We can invent terms for engine+transport or > entity+transport > but their absence from SNMP Architecture will always leave > some inconsistency. > > > My point though is that if you can accept commands you have some > > credential. It turns out that ssh server credentials are roughly > > symmetric and can be used as ssh client credentials. The > same is not > > true for client credentials: most ssh clients do not have a > sufficient > > credential to act as an ssh server. > > > I agree but the credentials are of the server and have to be > made into something > principal related because that is what SNMP Architecture says. > > So, I wish the SNMP Architecture did not say what it does, > but it does, and that > is where we are:-( > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jun 25 09:37:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmAr5-0005bL-5j; Sat, 25 Jun 2005 09:37:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmAr2-0005bG-RZ for isms@megatron.ietf.org; Sat, 25 Jun 2005 09:37:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27806 for ; Sat, 25 Jun 2005 09:37:51 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmBFk-0006A0-8S for isms@ietf.org; Sat, 25 Jun 2005 10:03:27 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 0011711D384; Sat, 25 Jun 2005 06:37:40 -0700 (PDT) From: Wes Hardaker To: ietfdbh@comcast.net Subject: Re: [Isms] Authentication and access control requirements Organization: Sparta References: <200506241952.PAA09351@ietf.org> Date: Sat, 25 Jun 2005 06:37:37 -0700 In-Reply-To: <200506241952.PAA09351@ietf.org> (David B. Harrington's message of "Fri, 24 Jun 2005 15:52:37 -0400") 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 'Sam Hartman' , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David> 2b) If the transport "principal" is an application, such as an David> authenticated SSH-client, that may be adequate for both SNMP David> access control and auditing, if access control/auditing at the David> application granularity is adequate; David, I think your concept of where authentication here is slightly broken. You seem to be saying that a ssh client is authenticating the user behind it and thus won't meet operator needs, which is bogus. A SSH connection authenticates the user just as much as SNMP does. The application will always have access to the credentials to send authentication information to the other side, be it a SNMPv3/USM proof of identity through a authenticated hash or via a SSH public/private key pair signing or through a ... The whole point of a transport underneath SNMP, which is at the application layer (not at the host layer like IPsec or other lowere protocols) is that a user has been authenticated already and the SNMP application should have knowledge of that authentication. SSH is actually the easiest case of this, because it does operate at a user-level authentication. TLS is actually harder because by default it doesn't without something like SASL combined with it. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jun 26 11:59:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmZY5-0001nd-Cd; Sun, 26 Jun 2005 11:59:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmZY3-0001mz-49 for isms@megatron.ietf.org; Sun, 26 Jun 2005 11:59:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06317 for ; Sun, 26 Jun 2005 11:59:51 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmXsR-0001WZ-JQ for isms@ietf.org; Sun, 26 Jun 2005 10:12:53 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 50025E0063; Sun, 26 Jun 2005 09:46:43 -0400 (EDT) To: References: <200506241952.j5OJqbLN012349@fort-point-station.mit.edu> From: Sam Hartman Date: Sun, 26 Jun 2005 09:46:43 -0400 In-Reply-To: <200506241952.j5OJqbLN012349@fort-point-station.mit.edu> (David B. Harrington's message of "Fri, 24 Jun 2005 15:52:37 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: isms@ietf.org Subject: [Isms] Re: Authentication and access control requirements 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 For ISMS to be useful, I think it is critical that ISMS not create a bunch of additional requirements on the principals of the underlying credential system. If I as an operator only have permanent keys for applications then that's probably what I'm going to want to use as targets of notifications. If there are user keys available then I'll use them. The whole point of ISMS is to take advantage of the underlying credentials. If you add significant requirements beyond that, then you might as well deploy USM. Moreover, in a lot of the systems we're discussing, the underlying credentials will not tell you whether they are a user, application or host. (I don't think they will ever really be host credentials, but I could see how someone might view TLS certificates that way.) _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jun 26 20:25:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmhRX-0007aO-0H; Sun, 26 Jun 2005 20:25:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmhRV-0007aG-FV for isms@megatron.ietf.org; Sun, 26 Jun 2005 20:25:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27297 for ; Sun, 26 Jun 2005 20:25:39 -0400 (EDT) Message-Id: <200506270025.UAA27297@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmhqW-0002JE-9x for isms@ietf.org; Sun, 26 Jun 2005 20:51:34 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <20050627002528013002v48ve>; Mon, 27 Jun 2005 00:25:28 +0000 From: "David B Harrington" To: "'Sam Hartman'" Date: Sun, 26 Jun 2005 20:25:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcV6VX+CeUf8APwzQCeWmia4f8Fp2AAT5Bwg X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: [Isms] RE: Authentication and access control requirements 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 Sam, I started this thread to discuss just which SNMPv3 requirements/goals must be met, and how those requirements compare to the concepts/capabilities of SSH, since SSH seems to be getting the greatest amount of discussion. I am not trying to set new requirements for an underlying credential system; I am trying to determine whether the requirements and goals that have already been defined for SNMPv3 are still applicable, and how using SSH will meet them. The charter says "A solution must not modify the other aspects of SNMPv3 protocol as defined in STD 62". As one of the authors of the architecture document, and a co-chair of the SNMPv3 WG, I'm trying to be sure that any solution is compatible with the concepts of, and the requirements met by, the existing SNMPv3 architecture, or that any deviation from the existing SNMPv3 architecture is done knowingly and deliberately. SNMPv3 was designed to allow various types of principals to be represented, in order to meet various specific requirements of the operator and NMS-developer communities. I am interested in understanding how the SSH concepts fit into the SNMPv3 architecture. Does SSH support authenticating users and applications and other principals, or is SSH restricted to certain types of principals? > For ISMS to be useful, I think it is critical that ISMS not create a > bunch of additional requirements on the principals of the underlying > credential system. I agree, if the underlying credential system can meet the requirements/goals of SNMPv3. If the underlying credential system doesn't support the same requirements, then we should discuss the impact to SNMPv3 of using said credential system. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Sunday, June 26, 2005 9:47 AM > To: ietfdbh@comcast.net > Cc: 'Tom Petch'; isms@ietf.org > Subject: Re: Authentication and access control requirements > > > For ISMS to be useful, I think it is critical that ISMS not create a > bunch of additional requirements on the principals of the underlying > credential system. > > If I as an operator only have permanent keys for applications then > that's probably what I'm going to want to use as targets of > notifications. If there are user keys available then I'll use them. > > The whole point of ISMS is to take advantage of the underlying > credentials. If you add significant requirements beyond that, then > you might as well deploy USM. > > Moreover, in a lot of the systems we're discussing, the underlying > credentials will not tell you whether they are a user, application or > host. (I don't think they will ever really be host credentials, but I > could see how someone might view TLS certificates that way.) > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jun 26 20:39:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmhee-0001GA-N7; Sun, 26 Jun 2005 20:39:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmhed-0001G5-4f for isms@megatron.ietf.org; Sun, 26 Jun 2005 20:39:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28420 for ; Sun, 26 Jun 2005 20:39:13 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmi3e-0002ZN-W6 for isms@ietf.org; Sun, 26 Jun 2005 21:05:08 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 26 Jun 2005 17:39:05 -0700 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 j5R0d3vM010830; Sun, 26 Jun 2005 17:39:03 -0700 (PDT) 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] RE: Authentication and access control requirements Date: Sun, 26 Jun 2005 17:43:18 -0700 Message-ID: <7210B31550AC934A8637D6619739CE69056DCABF@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Isms] RE: Authentication and access control requirements Thread-Index: AcV6VX+CeUf8APwzQCeWmia4f8Fp2AAT5BwgAAKPriA= From: "Salowey, Joe" To: , "Sam Hartman" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 > SNMPv3 was designed to allow various types of principals to=20 > be represented, in order to meet various specific=20 > requirements of the operator and NMS-developer communities. I=20 > am interested in understanding how the SSH concepts fit into=20 > the SNMPv3 architecture. > Does SSH support authenticating users and applications and=20 > other principals, or is SSH restricted to certain types of principals? >=20 [Joe] SSH can support different types of credentials representing different types of principals. Typically the SSH server application is authenticated to SSH client application using a public/private key pair, there are other options available such as draft-ietf-secsh-gsskeyex-09.txt which use different types of credentials. Once the server application has been authenticated then SSH authentication protocol (draft-ietf-secsh-userauth-27.txt) is executed to authenticate the client principal which typically is a user or an application. The SSH authentication protocol can support a wide range of credential types. =20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jun 30 18:31:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do7ZH-0005pI-5f; Thu, 30 Jun 2005 18:31:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do7ZE-0005oZ-Nv for isms@megatron.ietf.org; Thu, 30 Jun 2005 18:31:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01297 for ; Thu, 30 Jun 2005 18:31:29 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do7z5-000746-9N for isms@ietf.org; Thu, 30 Jun 2005 18:58:15 -0400 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j5UMVOOU011505 for ; Thu, 30 Jun 2005 18:31:24 -0400 (EDT) Message-Id: <200506302231.j5UMVOOU011505@ginger.cmf.nrl.navy.mil> To: isms@ietf.org X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Thu, 30 Jun 2005 18:31:25 -0400 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: [Isms] Coming to consensus 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 ISMS participants: First off, my apologies for not being more active in recent weeks; the rest of my life keeps intruding onto IETF work. To cut to the chase: I recently had a conference call with our sheperding AD, Sam Hartman, regarding the current status of ISMS. These are the conclusions that we came to: - The consensus declaration for encapsulation keying has been accepted by the working group. - There has been no clear consensus expressed by the WG participants regarding a particular protocol to be used by ISMS with EK. - There are three obvious choices (to us) for protocols to be used by ISMS: TLS+SASL (more on us throwing SASL into this mix in a moment) SSH DTLS Of these three obvious choices, the first two really want a stream transport (TCP). Obviously, DTLS does not. So, the question before the ISMS WG is: which protocol do we want? Other suggestions for protocols to be used are welcome; Sam and I just listed the ones that we saw people talking about, and ones that we thought were a reasonable fit for ISMS. We would like the WG to come to a consensus by August. If we had a draft by then, that would be great, but we do not view that as necessary. Regarding TLS+SASL ... since the desire of ISMS is to produce a protocol which can leverage other authentication mechanisms, not only do you want to use TLS (which will provide session encryption plus the use of PK certificates), but you also want provisions to use SASL (or something like SASL I suppose, but I'm not aware of an equivalant), which supports a wide variety of authentication mechanisms. This combination has been used by a number of protocols within the IETF community, and seems to be rather successful. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jun 30 18:43:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do7kT-0000wm-1L; Thu, 30 Jun 2005 18:43:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do7kR-0000wh-4i for isms@megatron.ietf.org; Thu, 30 Jun 2005 18:43:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02115 for ; Thu, 30 Jun 2005 18:43:04 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do8AC-0007VV-CG for isms@ietf.org; Thu, 30 Jun 2005 19:09:49 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA06313; Thu, 30 Jun 2005 15:42:39 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j5UMgiv11732; Thu, 30 Jun 2005 17:42:44 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Jun 2005 15:42:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Coming to consensus Date: Thu, 30 Jun 2005 15:42:34 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC38D@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] Coming to consensus Thread-Index: AcV9w4bhlwihrDeYSvSDSfbZDbSE9wAAL/mw From: "Fleischman, Eric" To: "Ken Hornstein" , X-OriginalArrivalTime: 30 Jun 2005 22:42:34.0686 (UTC) FILETIME=[021495E0:01C57DC5] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Group: Don't both TLS and SSH require TCP transports while only DTLS can support UDP? If this is true, isn't our next decision point the evaluation of whether SNMP shall continue to be supported over either TCP or UDP or whether we only want it over UDP? If the former, do we want one "secure session" technology to be used for both UDP and TCP or do we allow the UDP to have a different "secure session" technology than TCP? My own perspective (for whatever it is worth) is that SNMP has had better performance in wireless and bandwidth constrained environments using UDP than TCP. Thus, the view from my knot-hole is that UDP is important. I also would prefer a single generic "secure session" approach. Can SSH support UDP? If not, then I suggest that we use (D)TLS (i.e., TLS for TCP and DTLS for UDP). --Eric _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jun 30 18:44:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do7lX-000192-Cs; Thu, 30 Jun 2005 18:44:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do7lV-00018u-Bp for isms@megatron.ietf.org; Thu, 30 Jun 2005 18:44:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02214 for ; Thu, 30 Jun 2005 18:44:10 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do8BL-0007Xl-SF for isms@ietf.org; Thu, 30 Jun 2005 19:10:56 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA07388; Thu, 30 Jun 2005 15:43:58 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j5UMi3v12857; Thu, 30 Jun 2005 17:44:03 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Jun 2005 15:44:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Coming to consensus Date: Thu, 30 Jun 2005 15:44:01 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC38E@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] Coming to consensus Thread-Index: AcV9w4bhlwihrDeYSvSDSfbZDbSE9wAAL/mwAAA06+A= From: "Fleischman, Eric" To: "Fleischman, Eric" , "Ken Hornstein" , X-OriginalArrivalTime: 30 Jun 2005 22:44:02.0187 (UTC) FILETIME=[363C2DB0:01C57DC5] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Silly me: I mis-stated the first question. It should be whether we want to be able to convey SNMP over either UDP or TCP or whether we only want to convey it over TCP.=20 -----Original Message----- From: Fleischman, Eric=20 Sent: Thursday, June 30, 2005 3:43 PM To: 'Ken Hornstein'; isms@ietf.org Subject: RE: [Isms] Coming to consensus=20 Group: Don't both TLS and SSH require TCP transports while only DTLS can support UDP? If this is true, isn't our next decision point the evaluation of whether SNMP shall continue to be supported over either TCP or UDP or whether we only want it over UDP? If the former, do we want one "secure session" technology to be used for both UDP and TCP or do we allow the UDP to have a different "secure session" technology than TCP? My own perspective (for whatever it is worth) is that SNMP has had better performance in wireless and bandwidth constrained environments using UDP than TCP. Thus, the view from my knot-hole is that UDP is important. I also would prefer a single generic "secure session" approach. Can SSH support UDP? If not, then I suggest that we use (D)TLS (i.e., TLS for TCP and DTLS for UDP). --Eric _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jun 30 20:06:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do92x-0002ND-4m; Thu, 30 Jun 2005 20:06:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do92v-0002JD-6K for isms@megatron.ietf.org; Thu, 30 Jun 2005 20:06:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21032 for ; Thu, 30 Jun 2005 20:06:15 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do9Sj-0005cM-EG for isms@ietf.org; Thu, 30 Jun 2005 20:33:00 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 30 Jun 2005 17:06:04 -0700 X-IronPort-AV: i="3.93,248,1115017200"; d="scan'208"; a="284841546:sNHT26595092" Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j61063vN002216; Thu, 30 Jun 2005 17:06:04 -0700 (PDT) Message-Id: <6.2.0.14.0.20050630170124.03861eb8@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 30 Jun 2005 17:06:04 -0700 To: Ken Hornstein From: Kaushik Narayan Subject: Re: [Isms] Coming to consensus In-Reply-To: <200506302231.j5UMVOOU011505@ginger.cmf.nrl.navy.mil> References: <200506302231.j5UMVOOU011505@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: isms@ietf.org, elear@cisco.com 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 Ken, We believe that BEEP should be considered as a choice of encapsulation protocol for ISMS. This will align us closer to NetConf and Secure Syslog. regards, kaushik! At 03:31 PM 6/30/2005, Ken Hornstein wrote: >ISMS participants: > >First off, my apologies for not being more active in recent weeks; the >rest of my life keeps intruding onto IETF work. > >To cut to the chase: I recently had a conference call with our sheperding >AD, Sam Hartman, regarding the current status of ISMS. These are the >conclusions that we came to: > >- The consensus declaration for encapsulation keying has been accepted by > the working group. > >- There has been no clear consensus expressed by the WG participants regarding > a particular protocol to be used by ISMS with EK. > >- There are three obvious choices (to us) for protocols to be used by ISMS: > > TLS+SASL (more on us throwing SASL into this mix in a moment) > SSH > DTLS > >Of these three obvious choices, the first two really want a stream transport >(TCP). Obviously, DTLS does not. > >So, the question before the ISMS WG is: which protocol do we want? Other >suggestions for protocols to be used are welcome; Sam and I just listed >the ones that we saw people talking about, and ones that we thought were >a reasonable fit for ISMS. We would like the WG to come to a consensus >by August. If we had a draft by then, that would be great, but we do >not view that as necessary. > >Regarding TLS+SASL ... since the desire of ISMS is to produce a protocol >which can leverage other authentication mechanisms, not only do you want >to use TLS (which will provide session encryption plus the use of PK >certificates), but you also want provisions to use SASL (or something like >SASL I suppose, but I'm not aware of an equivalant), which supports >a wide variety of authentication mechanisms. This combination has been >used by a number of protocols within the IETF community, and seems to >be rather successful. > >--Ken > >_______________________________________________ >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