From isms-bounces@lists.ietf.org Mon May 02 07:49:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSZQ7-0006Ep-QV; Mon, 02 May 2005 07:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSIr9-0006Eg-FU for isms@megatron.ietf.org; Sun, 01 May 2005 14:07: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 OAA06023 for ; Sun, 1 May 2005 14:07:47 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSJ4e-00009n-Bb for isms@ietf.org; Sun, 01 May 2005 14:21:49 -0400 Received: from pc6 (1Cust141.tnt110.lnd4.gbr.da.uu.net [62.188.174.141]) by galaxy.systems.pipex.net (Postfix) with SMTP id 8CFF1E0000C4 for ; Sun, 1 May 2005 19:07:36 +0100 (BST) Message-ID: <000901c54e6f$bdc26fe0$0601a8c0@pc6> From: "Tom Petch" To: References: <200504292026.j3TKQGq2020968@ginger.cmf.nrl.navy.mil><003901c54d29$c13fa9e0$7f1afea9@oemcomputer><009101c54d4a$4c16abc0$7f1afea9@oemcomputer> <00e701c54d70$3686b180$0601a8c0@pc6> Date: Sun, 1 May 2005 19:01: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: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] SNMPv3 security; the fundamental flaw? 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 Thinking about the recent posts, I think the problem with USM is that it tries to do too much, to do things that were better done, or done better, elsewhere, at least nowadays. The wish of organisations to use the same end-user names everywhere is understandable but the consequence with USM is that the SNMP private 'databases' must be updated whenever people come or go or change jobs or update security credentials; for many, the price is too high. But there is more to it than that. Every SNMP manager (command generator) I see runs on a server platform - Microsoft Windows 200x Server, IBM AIX or z/OS et al - and these have their own authentication - of considerable strength - and authorisation - to a very fine level of detail - offering organisations a range of solutions commensurate with their security policies, based around a security server (usually a physically separate box). Microsoft have been doing this for 10 years, IBM for longer. By the time a request gets to the API of the command generator, it has been secured better than we are likely to do using a private database. In wrapping this up in SNMP, in SMI and MIB, we have put a barrier around SNMP security impenetrable to those who do not understand SNMP. If someone working on the security of a Microsoft or IBM et al server could see clearly what we were doing, they might well say, why bother? All that is needed is a Something to put in the SNMP PDU that can authenticate the PDU to the command responder and index into the authorisation there. This can be done by a call to the security process (task, daemon) of the SNMP manager server which has links into the organisation-wide security system. And if the command responder is also on a server platform, then it can use the Something in the same way. All that is needed from us is the definition of the Something in the PDU that is acceptable to the security processes of different manufacturers. Where we should then focus, because Microsoft, IBM et al may not, is on the command responders which run on non-server platforms, like a workgroup switch or access router with a 68000 chipset, where the mention of Diffie-Hellman is likely to engender a response of 'come back in a month when I have had a chance to think about it'. It is unreasonable to expect these to integrate with the organisation-wide security system or even to maintain a subset of end user name, security credentials etc to be updated promptly whenever anything changes. Or if that is what the security policy demands, then put in a Windows 2003 Server with loads of interface cards and configure it as a router - problem solved. Nor do I see it as practical to download the end user name and security credentials dynamically into the command responder whenever that end user wishes to access an SNMP agent. Rather we need a simpler range of security commensurate with the other capabilities of an entry level box. My thinking - as I have expressed before - is of a basic level consisting of a shared secret with the security server (not with the SNMP manager-server) which is then used to generate session keys for a small fixed set of userids; not as secure as USM but much more secure than some systems I see. This can be a one touch solution; the secret can be randomised by engine id (as Khanh suggested), to vary with box type (switch, router, firewall) etc. The security can be increased by a two-party protocol (not three) between box and security server to update the shared secret(s) when required (after a breach, at irregular intervals etc). This could be extended to amend other long term information, such as user id to VACM group name mapping But if it is not a server platform, then it has these fixed user ids, not the organisation wide end user names. The issue is how to map end user name into the fixed user id. The security server must allocate the user id (since the user id is the key into VACM and authorisation) and pass it to the SNMP manager server which generates the PDU. All soluble, especially if use is made of the existing server infrastructure. It was David's question about the logging, and could not the SNMP manager put a corrupt securityName into the PDU that made me think this through. Of course it could, but if you have successfully attacked one of these servers, then the organisation will have a lot more than SNMP to worry about. This network of servers, communicating with a security server, using proprietary or standard protocols, is what I always see, in any organisation which takes security seriously; it is the foundation of that organisation's security and I take its integrity for granted; and so to integrate SNMP security needs more than just reusing user names and security credentials, it means integrating with that network of servers. Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 12:23:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSdhf-0001fi-Bs; Mon, 02 May 2005 12:23:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSdhd-0001fd-76 for isms@megatron.ietf.org; Mon, 02 May 2005 12:23:25 -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 MAA00919 for ; Mon, 2 May 2005 12:23:22 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSdvL-0007AY-Dk for isms@ietf.org; Mon, 02 May 2005 12:37:35 -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 j42GN6oF016918; Mon, 2 May 2005 09:23:06 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j42GN3Ts004059; Mon, 2 May 2005 09:23:03 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j42GN2m0004048; Mon, 2 May 2005 09:23:03 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 2 May 2005 09:23:02 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Tom Petch Subject: Re: [Isms] SNMPv3 security; the fundamental flaw? In-Reply-To: <000901c54e6f$bdc26fe0$0601a8c0@pc6> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, Take a look at slides 3 and 4 from the presentation that I gave at the WG meeting.... http://www3.ietf.org/proceedings/05mar/slides/isms-2/sld3.htm These slides don't include the elaboration that I provided. However, I believe that they do highlight a couple of key points. First, most of what a manager (which is a colection of management apps) does is poll for statistics and status. This is important - it doesn't have the identity of a user when it does this, and must use its own identity. The colected data can be later (maybe months later, or maybe just a few minutes later) viewed by many different users. When they do, there is no interaction with SNMP agent(s). Likewise, there may be programs that are set up to be run when certain events occur. These are primarily automated. Whose identity should they be run with? There are many other examples that can show that the identity used in SNMP operations is not a user (since there is no user present when the SNMP app runs). The identity may be of the manager (the collection of mgmt apps), or could be named per mgmt app. However, for non routine and "real-time" management apps, such as those used for trouble shooting, or for "overriding" the configuration at managed systems, it is probably appropriate to use the identity of the user instead of the identity of the SNMP manager (or SNMP mgmt app). An example of a "real time" mgmt app is a "MIB browser" - a program that allows a user to view and possibly set the value of any allowed instance of management info. "Purpose built" mgmt apps need access only the instances of mgmt info needed to perform a specific purpose. For auditing, it's important to know who initiated (started) it (if its start is not automated). However, unless you are "debugging" the mgmt app (or the SNMP agent), it's generally not important to track each SNMP operation. In summary, it appears to me that much that has been done with SNMP is overly biased to support MIB browsers, and in support of complete management systems. Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 13:40:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSeu6-000102-2c; Mon, 02 May 2005 13:40:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSeu3-0000zr-RQ for isms@megatron.ietf.org; Mon, 02 May 2005 13:40: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 NAA07721 for ; Mon, 2 May 2005 13:40:16 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSf7l-0000Jp-J8 for isms@ietf.org; Mon, 02 May 2005 13:54:30 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA09134; Mon, 2 May 2005 12:40:04 -0500 (CDT) Received: from XCH-NWBH-02.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 j42He4m10676; Mon, 2 May 2005 12:40:04 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 10:39:48 -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] securityName in Keep the agent simple; was RADIUS is not a trusted third party Date: Mon, 2 May 2005 10:39:24 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC268@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] securityName in Keep the agent simple; was RADIUS is not a trusted third party Thread-Index: AcVM3G+2pOQA5xCJShmaQxpZFcCwZwAEhwUAAJOzEnA= From: "Fleischman, Eric" To: "Khanh Nguyen \(khanhvn\)" , "Tom Petch" X-OriginalArrivalTime: 02 May 2005 17:39:48.0254 (UTC) FILETIME=[EFABCBE0:01C54F3D] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 100% in favor of giving operators choices. However, the alternative which I value the most is the choice to use enterprise-wide authentication services (e.g., Kerberos, PKI). AAA is a fine alternative, but local accounts are a poor alternative (i.e., a real bear to regularize within large enterprises). Khanh Nguyen (khanhvn) [mailto:khanhvn@cisco.com] wrote: >So I think the ideal solution should be able to give operators >both choices: local user account and/or centralized AAA users. >I think EUSM, for example, supports both modes. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 13:55:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSf8p-0004eQ-4V; Mon, 02 May 2005 13:55:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSf8m-00043d-Nl for isms@megatron.ietf.org; Mon, 02 May 2005 13:55:33 -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 NAA09556 for ; Mon, 2 May 2005 13:55:31 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSfMV-0000gV-J7 for isms@ietf.org; Mon, 02 May 2005 14:09:43 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA00407; Mon, 2 May 2005 12:55:19 -0500 (CDT) Received: from xch-nwbh-01.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 j42HtIm03173; Mon, 2 May 2005 12:55:18 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by xch-nwbh-01.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 10:55:09 -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] CALL FOR CONSENSUS: ISMS Architecture Date: Mon, 2 May 2005 10:54:26 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC269@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] CALL FOR CONSENSUS: ISMS Architecture Thread-Index: AcVNyrZQ3XW0/WAkQsqSEDbsAT/80ABdGzwA From: "Fleischman, Eric" To: "Tom Petch" X-OriginalArrivalTime: 02 May 2005 17:55:09.0461 (UTC) FILETIME=[14C0D450:01C54F40] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 A generic question for you, Tom:=20 What is your concept of operations (CONOPS) for Out of band keying? For example, is a PKI system in which authentication occurs through digitally signing a message an out of band keying example from your perspective? If not, what is you view for how OOB would work when using Kerberos or PKI authentication systems? --Eric Tom Petch [mailto:nwnetworks@dial.pipex.com] wrote: >Out of Band keying is my preference. > >The discussions of the past few months have shown=20 >(what I think . of as) flaws in all the approaches=20 >and I now think Out of Band has the greatest=20 >flexibility to produce a workable proposal. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 14:42:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSfsK-0002s7-LA; Mon, 02 May 2005 14:42:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSfsI-0002rz-Jq for isms@megatron.ietf.org; Mon, 02 May 2005 14:42:34 -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 OAA17178 for ; Mon, 2 May 2005 14:42:33 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSg61-0002ri-OY for isms@ietf.org; Mon, 02 May 2005 14:56:46 -0400 Received: from pc6 (1Cust16.tnt27.lnd4.gbr.da.uu.net [62.188.154.16]) by galaxy.systems.pipex.net (Postfix) with SMTP id 104A6E00036E; Mon, 2 May 2005 19:42:21 +0100 (BST) Message-ID: <01fe01c54f3d$c19b31a0$0601a8c0@pc6> From: "Tom Petch" To: "David T. Perkins" References: Subject: Re: [Isms] SNMPv3 security; the fundamental flaw? Date: Mon, 2 May 2005 19:37:13 +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: 14582b0692e7f70ce7111d04db3781c8 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 Does this relate to the post you made in February asking about managed system identity? If so, I had not made the connection until now. (And I never did see a response). The more security-conscious organisations I have seen always run automated processes under a user id because that is the way the security system is set up, to check authorisations etc. If you are not an authorised user, you cannot start a task, execute the relevant code, such as an SNMP manager. I used to see role-based ids (independent of a human being) but that is now seen as too insecure, and so now there is (usually) an accountable human being under whose id the automated tasks run. It might for example be the person who created the automation script, it might be the person who raised the change request which set the process going. And of course these people change roles, leave the organisation etc but the principle remains, there is always someone accountable. And I agree, once collected, the data is available for months and years for all sorts of uses, SLAs, capacity planning and so on. And again, I see that as available only to authorised users ie the default is you cannot access any 'system' databases unless the system authorises your user id to do so. All of which is highly secure and needs nothing from isms to remain so:-) Tom Petch ----- Original Message ----- From: "David T. Perkins" To: "Tom Petch" Cc: Sent: Monday, May 02, 2005 6:23 PM Subject: Re: [Isms] SNMPv3 security; the fundamental flaw? > HI, > > Take a look at slides 3 and 4 from the presentation that I gave at > the WG meeting.... > http://www3.ietf.org/proceedings/05mar/slides/isms-2/sld3.htm > > These slides don't include the elaboration that I provided. > > However, I believe that they do highlight a couple of > key points. > > First, most of what a manager (which is a colection of > management apps) does is poll for statistics and status. > This is important - it doesn't have the identity of a user > when it does this, and must use its own identity. The > colected data can be later (maybe months later, or > maybe just a few minutes later) viewed by many > different users. When they do, there is no interaction > with SNMP agent(s). Likewise, there may be programs > that are set up to be run when certain events occur. > These are primarily automated. Whose identity should > they be run with? There are many other examples that > can show that the identity used in SNMP operations > is not a user (since there is no user present > when the SNMP app runs). The identity may be > of the manager (the collection of mgmt apps), > or could be named per mgmt app. > > However, for non routine and "real-time" management > apps, such as those used for trouble shooting, or > for "overriding" the configuration at managed systems, > it is probably appropriate to use the identity > of the user instead of the identity of the SNMP > manager (or SNMP mgmt app). An example of > a "real time" mgmt app is a "MIB browser" - > a program that allows a user to view and > possibly set the value of any allowed instance > of management info. > > "Purpose built" mgmt apps need access only the > instances of mgmt info needed to perform a > specific purpose. For auditing, it's important > to know who initiated (started) it (if its > start is not automated). However, unless you > are "debugging" the mgmt app (or the SNMP agent), > it's generally not important to track each > SNMP operation. > > In summary, it appears to me that much that > has been done with SNMP is overly biased > to support MIB browsers, and in support of > complete management systems. > > Regards, > /david t. perkins > > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 15:01:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSgAc-0004ET-D1; Mon, 02 May 2005 15:01:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSgAb-0004EO-JD for isms@megatron.ietf.org; Mon, 02 May 2005 15:01:29 -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 PAA19050 for ; Mon, 2 May 2005 15:01:28 -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 1DSgOK-0003OE-39 for isms@ietf.org; Mon, 02 May 2005 15:15:41 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 May 2005 12:00:51 -0700 X-IronPort-AV: i="3.92,146,1112598000"; d="scan'208"; a="257265237:sNHT2245706072" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j42J07LX008523; Mon, 2 May 2005 12:00:43 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 12:00:47 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] SNMPv3 security; the fundamental flaw? Date: Mon, 2 May 2005 12:00:46 -0700 Message-ID: Thread-Topic: [Isms] SNMPv3 security; the fundamental flaw? Thread-Index: AcVPDiTJGUfoDuxeTTuXcxCXrOHrbgALm7Gw From: "Khanh Nguyen \(khanhvn\)" To: "Tom Petch" , X-OriginalArrivalTime: 02 May 2005 19:00:47.0337 (UTC) FILETIME=[3FE90590:01C54F49] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 > From: Tom Petch >=20 > My thinking ... is of a basic level consisting=20 > of a shared secret with the security server (not with the=20 > SNMP manager-server) which is then used to generate session=20 > keys for a small fixed set of userids; not as secure as USM=20 > but much more secure than some systems I see. This can be a=20 > one touch solution; the secret can be randomised by engine id=20 > (as Khanh suggested), to vary with box type (switch, router, > firewall) etc. For proper credit, key localization is not my new idea :) I borrowed the concept from USM. The problem with USM is that it uses the localized authKey and=20 privKey statically: the same keys are used again and again for=20 all messages. This breaks perfect forward secrecy (PFS). This is not really USM fault (it has a smart design). Its lack=20 of PFS and replay attack protection is rather an inherent problem=20 with any sessionless secure transport. All ISMS proposals we have=20 seen here solve that problem (conciously or not) by using some=20 sorts of sessions/connections. =20 Back to localization, my LPSK proposal retains that USM concept,=20 but instead of using the localized secrets statically, the secrets=20 are used in conjuction with a secure PSK auth protocol such as SRP=20 to (1) authenticate *both* the user/manager and the agent, and=20 (2) generate a dynamic key for encryp & data integrity session. =20 LPSK can be used in all 3 keying environments: OOBK (e.g. EAP-SRP,=20 SASL-SRP), IBK (SNMP implementation of SRP, which is quite simple),=20 and EK (TLS-SRP, etc.) SRP (http://srp.stanford.edu) is just one of many PSK methods=20 that can be used to implement LPSK. I picked it as an example because it's secure, relatively simple, and widely used. Khanh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 15:13:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSgLr-0003Ng-Qm; Mon, 02 May 2005 15:13:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSgLq-0003Nb-PV for isms@megatron.ietf.org; Mon, 02 May 2005 15:13:06 -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 PAA21373 for ; Mon, 2 May 2005 15:13:05 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSgZZ-0003oJ-7J for isms@ietf.org; Mon, 02 May 2005 15:27:18 -0400 Received: from pc6 (1Cust237.tnt28.lnd4.gbr.da.uu.net [62.188.156.237]) by astro.systems.pipex.net (Postfix) with SMTP id 66F1AE0003B0; Mon, 2 May 2005 20:12:55 +0100 (BST) Message-ID: <002401c54f42$05a59260$0601a8c0@pc6> From: "Tom Petch" To: "Fleischman, Eric" References: <474EEBD229DF754FB83D256004D021080EC268@XCH-NW-6V1.nw.nos.boeing.com> Subject: Re: [Isms] securityName in Keep the agent simple; was RADIUS is not a trusted third party Date: Mon, 2 May 2005 20:08:46 +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: 0bc60ec82efc80c84b8d02f4b0e4de22 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 And a question for you; would you clarify what you mean by AAA? I tend to use it as a generic term to encompass accounting as well as elements of security, since the raw data of the two often overlap; I do not mean a specific technology such as Diameter.. Tom Petch ----- Original Message ----- From: "Fleischman, Eric" To: "Khanh Nguyen (khanhvn)" ; "Tom Petch" Cc: Sent: Monday, May 02, 2005 7:39 PM Subject: RE: [Isms] securityName in Keep the agent simple;was RADIUS is not a trusted third party I am 100% in favor of giving operators choices. However, the alternative which I value the most is the choice to use enterprise-wide authentication services (e.g., Kerberos, PKI). AAA is a fine alternative, but local accounts are a poor alternative (i.e., a real bear to regularize within large enterprises). Khanh Nguyen (khanhvn) [mailto:khanhvn@cisco.com] wrote: >So I think the ideal solution should be able to give operators >both choices: local user account and/or centralized AAA users. >I think EUSM, for example, supports both modes. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 15:13:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSgLt-0003YH-Vp; Mon, 02 May 2005 15:13:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSgLs-0003P1-VV for isms@megatron.ietf.org; Mon, 02 May 2005 15:13:09 -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 PAA21367 for ; Mon, 2 May 2005 15:13:04 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSgZZ-0003oH-0x for isms@ietf.org; Mon, 02 May 2005 15:27:17 -0400 Received: from pc6 (1Cust237.tnt28.lnd4.gbr.da.uu.net [62.188.156.237]) by astro.systems.pipex.net (Postfix) with SMTP id 36F9CE0003BC; Mon, 2 May 2005 20:12:51 +0100 (BST) Message-ID: <002301c54f42$04809a60$0601a8c0@pc6> From: "Tom Petch" To: "Fleischman, Eric" References: <474EEBD229DF754FB83D256004D021080EC269@XCH-NW-6V1.nw.nos.boeing.com> Date: Mon, 2 May 2005 20:04:19 +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: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: [Isms] What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture 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 To quote Ken, from March "Out of Band Keying" This is the approach chosen by EUSM. Essentially, a seperate protocol exchange is conducted between the manager and agent (or a third party) and a key is then established/derived for use with standard USM. Features: - Can make use of existing USM (already-analyzed protocol). - Likely wide variety of IETF protocols to use as out-of-band keying protocol - Encryption/checksum modes limited to ones supported by USM - Extra care would be required to assure keying material derived from out-of-band exchange is matched with a particular USM session." The ensuing discussion suggested that there was not a one to one mapping between the three proposals and the three methods of key derivation, rather several could use several - I think someone did produce a matrix (why don't we have a web site of things like this?) If the manager conducts an exchange with a third party, and agent conducts an exchange with a third party, be that Kerberos or proprietary, and so keys are derived for the security needs of the SNMP PDU, then I take that to be Out Of Band. Which model PKI is depends for me where the certificates are; could be any. You need to check with Ken; it was he who introduced the terminology to my vocabulary (In passing, when I say IBM, think RACF, which you may be familiar with) Tom Petch ----- Original Message ----- From: "Fleischman, Eric" To: "Tom Petch" Cc: Sent: Monday, May 02, 2005 7:54 PM Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture A generic question for you, Tom: What is your concept of operations (CONOPS) for Out of band keying? For example, is a PKI system in which authentication occurs through digitally signing a message an out of band keying example from your perspective? If not, what is you view for how OOB would work when using Kerberos or PKI authentication systems? --Eric Tom Petch [mailto:nwnetworks@dial.pipex.com] wrote: >Out of Band keying is my preference. > >The discussions of the past few months have shown >(what I think . of as) flaws in all the approaches >and I now think Out of Band has the greatest >flexibility to produce a workable proposal. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 16:16:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DShHX-0007vt-PE; Mon, 02 May 2005 16:12:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DShHW-0007oK-0S for isms@megatron.ietf.org; Mon, 02 May 2005 16:12:42 -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 QAA05720 for ; Mon, 2 May 2005 16:12:40 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DShV8-0007yA-Fw for isms@ietf.org; Mon, 02 May 2005 16:26:50 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA16452; Mon, 2 May 2005 13:12:19 -0700 (PDT) Received: from xch-nwbh-01.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 j42KCIm26555; Mon, 2 May 2005 15:12:19 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by xch-nwbh-01.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 13:12:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 May 2005 13:12:08 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC26B@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture Thread-Index: AcVPT0It6IOH2GHvQiSQBmZ5jEvDIQAAoUWQ From: "Fleischman, Eric" To: "Tom Petch" X-OriginalArrivalTime: 02 May 2005 20:12:16.0851 (UTC) FILETIME=[3CA8EA30:01C54F53] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org Subject: [Isms] RE: What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture 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 Thank you, Tom, for this excellent summary. However, my specific question was in regards to how **you** envision OOB keying being done in conjunction with Kerberos- and PKI-based authentication systems.=20 If I were to answer my own question, I would say that both the manager and the agent need to independently query the same Kerberos TGS system in an OOB approach to get the credentials. But, since the queries are independent, I am unsure whether the answers would necessarily be associated (compatable) to permit interoperability. Hence my question to you since I am not confident that OOB works with Kerberos. Since I may well be overlooking something important, I'd appreciate learning your viewpoint.=20 On the other hand, I think that PKI is more straight-forward (if authentication is being done via signing and if both are using the same PKI system) and shouldn't be problematic for OOB.=20 How do you see things?=20 -----Original Message----- From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 Sent: Monday, May 02, 2005 11:04 AM To: Fleischman, Eric Cc: isms@ietf.org Subject: What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture To quote Ken, from March "Out of Band Keying" This is the approach chosen by EUSM. Essentially, a seperate protocol exchange is conducted between the manager and agent (or a third party) and a key is then established/derived for use with standard USM. Features: - Can make use of existing USM (already-analyzed protocol). - Likely wide variety of IETF protocols to use as out-of-band keying protocol - Encryption/checksum modes limited to ones supported by USM - Extra care would be required to assure keying material derived from out-of-band exchange is matched with a particular USM session." The ensuing discussion suggested that there was not a one to one mapping between the three proposals and the three methods of key derivation, rather several could use several - I think someone did produce a matrix (why don't we have a web site of things like this?) If the manager conducts an exchange with a third party, and agent conducts an exchange with a third party, be that Kerberos or proprietary, and so keys are derived for the security needs of the SNMP PDU, then I take that to be Out Of Band. Which model PKI is depends for me where the certificates are; could be any. You need to check with Ken; it was he who introduced the terminology to my vocabulary (In passing, when I say IBM, think RACF, which you may be familiar with) Tom Petch ----- Original Message ----- From: "Fleischman, Eric" To: "Tom Petch" Cc: Sent: Monday, May 02, 2005 7:54 PM Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture A generic question for you, Tom: What is your concept of operations (CONOPS) for Out of band keying? For example, is a PKI system in which authentication occurs through digitally signing a message an out of band keying example from your perspective? If not, what is you view for how OOB would work when using Kerberos or PKI authentication systems? --Eric Tom Petch [mailto:nwnetworks@dial.pipex.com] wrote: >Out of Band keying is my preference. > >The discussions of the past few months have shown >(what I think . of as) flaws in all the approaches >and I now think Out of Band has the greatest >flexibility to produce a workable proposal. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 16:33:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DShbB-00049M-AD; Mon, 02 May 2005 16:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DShb9-00041P-Lu for isms@megatron.ietf.org; Mon, 02 May 2005 16:32:59 -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 QAA12620 for ; Mon, 2 May 2005 16:32:57 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DShos-0001jJ-Qz for isms@ietf.org; Mon, 02 May 2005 16:47:12 -0400 Received: from pc6 (1Cust176.tnt103.lnd4.gbr.da.uu.net [213.116.54.176]) by astro.systems.pipex.net (Postfix) with SMTP id E344AE00040F; Mon, 2 May 2005 21:32:46 +0100 (BST) Message-ID: <006201c54f4d$2dfc1b20$0601a8c0@pc6> From: "Tom Petch" To: "Khanh Nguyen \(khanhvn\)" , References: Date: Mon, 2 May 2005 21:24:31 +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: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] TLA 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 mmm there's something about Three Letter Acronyms at the back of my mind. I probably shouldn't be asking - since we are in the security area - but PSK is Pre-Shared Key - yes? PFS is what concept; perhaps you can point me at a seminal article on it or a reference in a standard text. (I may know it under another name). Tom Petch ----- Original Message ----- From: "Khanh Nguyen (khanhvn)" To: "Tom Petch" ; Sent: Monday, May 02, 2005 9:00 PM Subject: RE: [Isms] SNMPv3 security; the fundamental flaw? > From: Tom Petch > > My thinking ... is of a basic level consisting > of a shared secret with the security server (not with the > SNMP manager-server) which is then used to generate session > keys for a small fixed set of userids; not as secure as USM > but much more secure than some systems I see. This can be a > one touch solution; the secret can be randomised by engine id > (as Khanh suggested), to vary with box type (switch, router, > firewall) etc. For proper credit, key localization is not my new idea :) I borrowed the concept from USM. The problem with USM is that it uses the localized authKey and privKey statically: the same keys are used again and again for all messages. This breaks perfect forward secrecy (PFS). This is not really USM fault (it has a smart design). Its lack of PFS and replay attack protection is rather an inherent problem with any sessionless secure transport. All ISMS proposals we have seen here solve that problem (conciously or not) by using some sorts of sessions/connections. Back to localization, my LPSK proposal retains that USM concept, but instead of using the localized secrets statically, the secrets are used in conjuction with a secure PSK auth protocol such as SRP to (1) authenticate *both* the user/manager and the agent, and (2) generate a dynamic key for encryp & data integrity session. LPSK can be used in all 3 keying environments: OOBK (e.g. EAP-SRP, SASL-SRP), IBK (SNMP implementation of SRP, which is quite simple), and EK (TLS-SRP, etc.) SRP (http://srp.stanford.edu) is just one of many PSK methods that can be used to implement LPSK. I picked it as an example because it's secure, relatively simple, and widely used. Khanh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 16:36:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DShef-0003uA-O8; Mon, 02 May 2005 16:36:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DShed-0003u5-OF for isms@megatron.ietf.org; Mon, 02 May 2005 16:36:35 -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 QAA13036 for ; Mon, 2 May 2005 16:36:33 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DShsL-0001o1-L0 for isms@ietf.org; Mon, 02 May 2005 16:50:48 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA18778; Mon, 2 May 2005 13:36:23 -0700 (PDT) Received: from XCH-NWBH-02.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 j42KaNN00832; Mon, 2 May 2005 13:36:23 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 13:36:21 -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] securityName in Keep the agent simple; was RADIUS is not a trusted third party Date: Mon, 2 May 2005 13:36:02 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC26C@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] securityName in Keep the agent simple; was RADIUS is not a trusted third party Thread-Index: AcVPS1YPYqKUUbVgTxiEm+cCtNzCyQAB/EkA From: "Fleischman, Eric" To: "Tom Petch" X-OriginalArrivalTime: 02 May 2005 20:36:21.0976 (UTC) FILETIME=[9A057D80:01C54F56] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Tom, Yes, terminology can be problematic. In my own posting, I used AAA to generically refer to client-server policy based systems such as COPS servers, Radius, and Diameter. I wasn't explicitly intending the literal meaning of the acronym (authentication, authorization, and accounting) but rather the generic client-server technology approach often associated with that acronym. Since you asked, my own "hot buttons" are that I want whatever the WG comes up with to be easily administrated in very large (i.e., huge, vast) networks. I favor leveraging enterprise wide authentication systems such as Kerberos and PKI, but also major client-server solutions such as Radius. Our experience is that local-account based approaches are really tough to scale to large networks in an operationally secure manner. Also, if ISMS leverages USM, then I want the USM "keys" to leverage major authentication systems already deployed within large networks rather than persisting in using a "unique" system (i.e., no other IETF protocol or deployed (application) authentication system uses its keys today in many/most environments). I am open to all three major keying mechanisms, depending on specifics of how they are done. I am skeptical that OOB supports Kerberos, which, if true, is A Big Deal and forms the nucleus of my questions to you. I favor in-band because it is easy to create unique "session keys" from "authentication keys" in a negotiated manner using widely deployed protocol approaches (e.g., D-H). As you may recall, I am worried about a number of session key issues, and prefer approaches supporting Perfect Forward Secrecy (PFS). I believe PFS is more difficult in OOB approaches but I am quite willing to support any approach that actually works. Thus, my questions to you were all real questions to try to learn from your insights. --Eric >From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 >And a question for you; would you clarify what you=20 >mean by AAA? I tend to use it as a generic term to=20 >encompass accounting as well as elements of security,=20 >since the raw data of the two often overlap; I do=20 >not mean a specific technology such as Diameter.. >>From: Eric Fleischman >>I am 100% in favor of giving operators choices.=20 >>However, the alternative which I value the most=20 >>is the choice to use enterprise-wide authentication=20 >>services (e.g., Kerberos, PKI). AAA is a fine alternative,=20 >>but local accounts are a poor alternative (i.e., a real=20 >>bear to regularize within large enterprises). >>>Khanh Nguyen (khanhvn) [mailto:khanhvn@cisco.com] wrote: >>>So I think the ideal solution should be able to give operators=20 >>>both choices: local user account and/or centralized AAA users.=20 >>>I think EUSM, for example, supports both modes. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 16:48:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DShqG-0007PA-Fp; Mon, 02 May 2005 16:48:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DShqC-0007P3-NM for isms@megatron.ietf.org; Mon, 02 May 2005 16:48:32 -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 QAA13924 for ; Mon, 2 May 2005 16:48:30 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSi3w-00021w-DD for isms@ietf.org; Mon, 02 May 2005 17:02:45 -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 j42KmM5Y027125 for ; Mon, 2 May 2005 16:48:23 -0400 (EDT) Message-Id: <200505022048.j42KmM5Y027125@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: Mon, 02 May 2005 16:48:23 -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: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Isms] Status of 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 FYI, Just to keep everyone up-to-date on our status .... Juergen and I have been talking about the recent discussion and the state of consensus within the working group. Expect an message regarding the group's consensus soon (hopefully within a day). --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 16:49:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DShrV-0001En-Ng; Mon, 02 May 2005 16:49:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DShrS-0001CS-0q for isms@megatron.ietf.org; Mon, 02 May 2005 16:49: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 QAA14070 for ; Mon, 2 May 2005 16:49:48 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSi5C-00024F-Hr for isms@ietf.org; Mon, 02 May 2005 17:04:02 -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 PAA17411; Mon, 2 May 2005 15:49:40 -0500 (CDT) Received: from XCH-NWBH-02.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 j42KndN24728; Mon, 2 May 2005 13:49:39 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 13:49:38 -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] TLA Date: Mon, 2 May 2005 13:49:27 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC26D@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] TLA Thread-Index: AcVPVlJnl2FvMTQSTaOS/WpcBLSHOwAAhHrg From: "Fleischman, Eric" To: "Tom Petch" , "Khanh Nguyen \(khanhvn\)" , X-OriginalArrivalTime: 02 May 2005 20:49:38.0505 (UTC) FILETIME=[74CA2B90:01C54F58] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 PFS is defined in Section 3.3 of RFC 2409 as: "When used in the memo Perfect Forward Secrecy (PFS) refers to the notion that compromise of a single key will permit access to only data protected by a single key. For PFS to exist the key used to protect transmission of data MUST NOT be used to derive any additional keys, and if the key used to protect transmission of data was derived from some other keying material, that material MUST NOT be used to derive any more keys." -----Original Message----- From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 Sent: Monday, May 02, 2005 12:25 PM To: Khanh Nguyen (khanhvn); isms@ietf.org Subject: [Isms] TLA mmm there's something about Three Letter Acronyms at the back of my mind. I probably shouldn't be asking - since we are in the security area - but PSK is Pre-Shared Key - yes? PFS is what concept; perhaps you can point me at a seminal article on it or a reference in a standard text. (I may know it under another name). Tom Petch ----- Original Message ----- From: "Khanh Nguyen (khanhvn)" To: "Tom Petch" ; Sent: Monday, May 02, 2005 9:00 PM Subject: RE: [Isms] SNMPv3 security; the fundamental flaw? > From: Tom Petch > > My thinking ... is of a basic level consisting > of a shared secret with the security server (not with the SNMP=20 > manager-server) which is then used to generate session keys for a=20 > small fixed set of userids; not as secure as USM but much more secure=20 > than some systems I see. This can be a one touch solution; the secret > can be randomised by engine id (as Khanh suggested), to vary with box=20 > type (switch, router, > firewall) etc. For proper credit, key localization is not my new idea :) I borrowed the concept from USM. The problem with USM is that it uses the localized authKey and privKey statically: the same keys are used again and again for all messages. This breaks perfect forward secrecy (PFS). This is not really USM fault (it has a smart design). Its lack of PFS and replay attack protection is rather an inherent problem with any sessionless secure transport. All ISMS proposals we have seen here solve that problem (conciously or not) by using some sorts of sessions/connections. Back to localization, my LPSK proposal retains that USM concept, but instead of using the localized secrets statically, the secrets are used in conjuction with a secure PSK auth protocol such as SRP to (1) authenticate *both* the user/manager and the agent, and (2) generate a dynamic key for encryp & data integrity session. LPSK can be used in all 3 keying environments: OOBK (e.g. EAP-SRP, SASL-SRP), IBK (SNMP implementation of SRP, which is quite simple), and EK (TLS-SRP, etc.) SRP (http://srp.stanford.edu) is just one of many PSK methods that can be used to implement LPSK. I picked it as an example because it's secure, relatively simple, and widely used. Khanh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 17:05:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSi73-0004W2-2c; Mon, 02 May 2005 17:05:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSi71-0004Vu-1b for isms@megatron.ietf.org; Mon, 02 May 2005 17:05:55 -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 RAA15022 for ; Mon, 2 May 2005 17:05:52 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSiKl-0002Lc-D9 for isms@ietf.org; Mon, 02 May 2005 17:20:07 -0400 Received: from pc6 (1Cust176.tnt103.lnd4.gbr.da.uu.net [213.116.54.176]) by astro.systems.pipex.net (Postfix) with SMTP id 084BFE0002A1; Mon, 2 May 2005 22:05:42 +0100 (BST) Message-ID: <00a001c54f51$c8014980$0601a8c0@pc6> From: "Tom Petch" To: "Fleischman, Eric" References: <474EEBD229DF754FB83D256004D021080EC26C@XCH-NW-6V1.nw.nos.boeing.com> Subject: Re: [Isms] securityName in Keep the agent simple; was RADIUS is not a trusted third party Date: Mon, 2 May 2005 22:01:31 +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: cd26b070c2577ac175cd3a6d878c6248 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 Thanks for that. I am happy with all your requirements with one proviso. That the solution scales down to smaller organisations with less support staff; and to smaller boxes which may never have the capability to handle Kerberos etc (a recent post suggested that even D-H would be too computationaly demanding for some systems - I have no information on that but take the post seriously). So I don't see a shared secret put in at installation as strong security, but I do see it as commensurate with some organisations and some boxes (and a lot better than that which they have at the moment:-). Where security really matters (DoD, banking, law enforcement, air traffic control etc), then people buy powerful enough boxes to do what it takes. I am concerned for those where it matters less. Tom Petch ----- Original Message ----- From: "Fleischman, Eric" To: "Tom Petch" Cc: Sent: Monday, May 02, 2005 10:36 PM Subject: RE: [Isms] securityName in Keep the agent simple;was RADIUS is not a trusted third party Tom, Yes, terminology can be problematic. In my own posting, I used AAA to generically refer to client-server policy based systems such as COPS servers, Radius, and Diameter. I wasn't explicitly intending the literal meaning of the acronym (authentication, authorization, and accounting) but rather the generic client-server technology approach often associated with that acronym. Since you asked, my own "hot buttons" are that I want whatever the WG comes up with to be easily administrated in very large (i.e., huge, vast) networks. I favor leveraging enterprise wide authentication systems such as Kerberos and PKI, but also major client-server solutions such as Radius. Our experience is that local-account based approaches are really tough to scale to large networks in an operationally secure manner. Also, if ISMS leverages USM, then I want the USM "keys" to leverage major authentication systems already deployed within large networks rather than persisting in using a "unique" system (i.e., no other IETF protocol or deployed (application) authentication system uses its keys today in many/most environments). I am open to all three major keying mechanisms, depending on specifics of how they are done. I am skeptical that OOB supports Kerberos, which, if true, is A Big Deal and forms the nucleus of my questions to you. I favor in-band because it is easy to create unique "session keys" from "authentication keys" in a negotiated manner using widely deployed protocol approaches (e.g., D-H). As you may recall, I am worried about a number of session key issues, and prefer approaches supporting Perfect Forward Secrecy (PFS). I believe PFS is more difficult in OOB approaches but I am quite willing to support any approach that actually works. Thus, my questions to you were all real questions to try to learn from your insights. --Eric >From: Tom Petch [mailto:nwnetworks@dial.pipex.com] >And a question for you; would you clarify what you >mean by AAA? I tend to use it as a generic term to >encompass accounting as well as elements of security, >since the raw data of the two often overlap; I do >not mean a specific technology such as Diameter.. >>From: Eric Fleischman >>I am 100% in favor of giving operators choices. >>However, the alternative which I value the most >>is the choice to use enterprise-wide authentication >>services (e.g., Kerberos, PKI). AAA is a fine alternative, >>but local accounts are a poor alternative (i.e., a real >>bear to regularize within large enterprises). >>>Khanh Nguyen (khanhvn) [mailto:khanhvn@cisco.com] wrote: >>>So I think the ideal solution should be able to give operators >>>both choices: local user account and/or centralized AAA users. >>>I think EUSM, for example, supports both modes. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 17:27:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSiRo-0001h1-Jk; Mon, 02 May 2005 17:27:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSiRn-0001fP-3z for isms@megatron.ietf.org; Mon, 02 May 2005 17:27:23 -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 RAA17050 for ; Mon, 2 May 2005 17:27:20 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSifX-0002r6-RX for isms@ietf.org; Mon, 02 May 2005 17:41:36 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA22991; Mon, 2 May 2005 14:27:12 -0700 (PDT) Received: from XCH-NWBH-02.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 j42LRCm17405; Mon, 2 May 2005 16:27:12 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 14:27:08 -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] securityName in Keep the agent simple; was RADIUS is not a trusted third party Date: Mon, 2 May 2005 14:26:47 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC26E@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] securityName in Keep the agent simple; was RADIUS is not a trusted third party Thread-Index: AcVPWrdLgw/zYw5hQked2IYRi2OWdQAAj0ww From: "Fleischman, Eric" To: "Tom Petch" X-OriginalArrivalTime: 02 May 2005 21:27:08.0463 (UTC) FILETIME=[B1DE83F0:01C54F5D] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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 Tom, I fully agree with you. Even though my "hot button" is creating a system that can adequately scale large (huge), our total approach also needs to support small deployments as well. I don't want to necessarily impose my own thoughts on the WG, but the approach that I had privately envisioned was to continue to support SNMPv1, SNMPv2, and SNMPv3 USM for systems/deployments that are well-supported by those approaches, but to make ISMS to also become available for environments that are not well supported by those existing approaches. This includes huge deployments and deployments with enhanced security requirements. --Eric >From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 Sent: Monday, May 02, 2005 1:02 PM To: Fleischman, Eric Cc: isms@ietf.org Subject: Re: [Isms] securityName in Keep the agent simple;was RADIUS is not a trusted third party Thanks for that. I am happy with all your requirements with one proviso. That the solution scales down to smaller organisations with less support staff; and to smaller boxes which may never have the capability to handle Kerberos etc (a recent post suggested that even D-H would be too computationaly demanding for some systems - I have no information on that but take the post seriously). So I don't see a shared secret put in at installation as strong security, but I do see it as commensurate with some organisations and some boxes (and a lot better than that which they have at the moment:-). Where security really matters (DoD, banking, law enforcement, air traffic control etc), then people buy powerful enough boxes to do what it takes. I am concerned for those where it matters less. Tom Petch ----- Original Message ----- From: "Fleischman, Eric" To: "Tom Petch" Cc: Sent: Monday, May 02, 2005 10:36 PM Subject: RE: [Isms] securityName in Keep the agent simple;was RADIUS is not a trusted third party Tom, Yes, terminology can be problematic. In my own posting, I used AAA to generically refer to client-server policy based systems such as COPS servers, Radius, and Diameter. I wasn't explicitly intending the literal meaning of the acronym (authentication, authorization, and accounting) but rather the generic client-server technology approach often associated with that acronym. Since you asked, my own "hot buttons" are that I want whatever the WG comes up with to be easily administrated in very large (i.e., huge, vast) networks. I favor leveraging enterprise wide authentication systems such as Kerberos and PKI, but also major client-server solutions such as Radius. Our experience is that local-account based approaches are really tough to scale to large networks in an operationally secure manner. Also, if ISMS leverages USM, then I want the USM "keys" to leverage major authentication systems already deployed within large networks rather than persisting in using a "unique" system (i.e., no other IETF protocol or deployed (application) authentication system uses its keys today in many/most environments). I am open to all three major keying mechanisms, depending on specifics of how they are done. I am skeptical that OOB supports Kerberos, which, if true, is A Big Deal and forms the nucleus of my questions to you. I favor in-band because it is easy to create unique "session keys" from "authentication keys" in a negotiated manner using widely deployed protocol approaches (e.g., D-H). As you may recall, I am worried about a number of session key issues, and prefer approaches supporting Perfect Forward Secrecy (PFS). I believe PFS is more difficult in OOB approaches but I am quite willing to support any approach that actually works. Thus, my questions to you were all real questions to try to learn from your insights. --Eric >From: Tom Petch [mailto:nwnetworks@dial.pipex.com] >And a question for you; would you clarify what you >mean by AAA? I tend to use it as a generic term to >encompass accounting as well as elements of security, >since the raw data of the two often overlap; I do >not mean a specific technology such as Diameter.. >>From: Eric Fleischman >>I am 100% in favor of giving operators choices. >>However, the alternative which I value the most >>is the choice to use enterprise-wide authentication >>services (e.g., Kerberos, PKI). AAA is a fine alternative, but local=20 >>accounts are a poor alternative (i.e., a real bear to regularize=20 >>within large enterprises). >>>Khanh Nguyen (khanhvn) [mailto:khanhvn@cisco.com] wrote: >>>So I think the ideal solution should be able to give operators both=20 >>>choices: local user account and/or centralized AAA users. I think=20 >>>EUSM, for example, supports both modes. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 17:35:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSiZu-00023I-VM; Mon, 02 May 2005 17:35:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSiZs-00022u-Bc for isms@megatron.ietf.org; Mon, 02 May 2005 17:35: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 RAA18059 for ; Mon, 2 May 2005 17:35:42 -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 1DSind-000354-91 for isms@ietf.org; Mon, 02 May 2005 17:49:57 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 02 May 2005 14:35:35 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j42LYuiU002788; Mon, 2 May 2005 14:35:32 -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); Mon, 2 May 2005 14:35:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 May 2005 14:35:31 -0700 Message-ID: Thread-Topic: TLA Thread-Index: AcVPViu3mxRC+9aRT8KROaNMUYKf/gAASucQ From: "Khanh Nguyen \(khanhvn\)" To: "Tom Petch" , X-OriginalArrivalTime: 02 May 2005 21:35:32.0371 (UTC) FILETIME=[DE38C630:01C54F5E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Cc: Subject: [Isms] RE: TLA 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 > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > To: Khanh Nguyen (khanhvn); isms@ietf.org >=20 > mmm there's something about Three Letter Acronyms at the back of my mind. > I probably shouldn't be asking - since we are in the security area - but >=20 > PSK is Pre-Shared Key - yes? Yes. PSK is often used for encryption (e.g. IPsec, Radius, etc),=20 but it can also be used for multual authentication and generating dynamic session keys for encryption. For example: http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-08.txt > PFS is what concept; perhaps you can point me at a seminal=20 > article on it or a reference in a standard text. (I may know=20 > it under another name). Brief definition of perfect forward secrecy: http://www.mpirical.com/companion/IP/PFS_-_Perfect_Forward_Secrecy.htm Basically, it's a desirable property of a cryptography system that if any short/long-term secret is compromised, past encryption is still protected. USM breaks PFS by using the same privKey for all SNMP messages. A hacker can silently tape all USM encrypted conversations, wait=20 until a day when he can steal a SNMP device and retrieves the=20 privKeys from it, then he can decrypt all the past communication=20 he have taped. The operator can never feel secure, because the=20 fact that a session is secure now will not guarantee that it'll=20 continue to be so in the future (that's why it's call "forward" secrecy.) TLS is an example of PFS. If an attacker gains additional=20 knowledge of a system secret in the future, he can not use=20 it to break past communication.=20 Sorry for the lengthy explanation, but I couldn't find any good=20 online seminal article about it. Many cryptography books may=20 have in-deep discussion about PFS. Maybe someone can provide more info. Khanh >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Khanh Nguyen (khanhvn)" > To: "Tom Petch" ; > Sent: Monday, May 02, 2005 9:00 PM > Subject: RE: [Isms] SNMPv3 security; the fundamental flaw? >=20 >=20 > > From: Tom Petch > > > > My thinking ... is of a basic level consisting of a shared=20 > secret with=20 > > the security server (not with the SNMP manager-server)=20 > which is then=20 > > used to generate session keys for a small fixed set of=20 > userids; not as=20 > > secure as USM but much more secure than some systems I see.=20 > This can=20 > > be a one touch solution; the secret can be randomised by=20 > engine id (as=20 > > Khanh suggested), to vary with box type (switch, router, > > firewall) etc. >=20 > For proper credit, key localization is not my new idea :) I=20 > borrowed the concept from USM. >=20 > The problem with USM is that it uses the localized authKey=20 > and privKey statically: the same keys are used again and=20 > again for all messages. This breaks perfect forward secrecy (PFS). >=20 > This is not really USM fault (it has a smart design). Its=20 > lack of PFS and replay attack protection is rather an=20 > inherent problem with any sessionless secure transport. All=20 > ISMS proposals we have seen here solve that problem=20 > (conciously or not) by using some sorts of sessions/connections. >=20 > Back to localization, my LPSK proposal retains that USM=20 > concept, but instead of using the localized secrets=20 > statically, the secrets are used in conjuction with a secure=20 > PSK auth protocol such as SRP to (1) authenticate *both* the=20 > user/manager and the agent, and > (2) generate a dynamic key for encryp & data integrity session. > LPSK can be used in all 3 keying environments: OOBK (e.g.=20 > EAP-SRP, SASL-SRP), IBK (SNMP implementation of SRP, which is=20 > quite simple), and EK (TLS-SRP, etc.) >=20 > SRP (http://srp.stanford.edu) is just one of many PSK methods=20 > that can be used to implement LPSK. I picked it as an=20 > example because it's secure, relatively simple, and widely used. >=20 > Khanh >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 17:41:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSiff-0007YL-Um; Mon, 02 May 2005 17:41:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSife-0007YD-Im for isms@megatron.ietf.org; Mon, 02 May 2005 17:41:42 -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 RAA18485 for ; Mon, 2 May 2005 17:41:40 -0400 (EDT) Received: from adsl-64-165-72-150.dsl.scrm01.pacbell.net ([64.165.72.150] helo=localhost.localdomain) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSitP-0003E0-GO for isms@ietf.org; Mon, 02 May 2005 17:55:55 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 8FA23D015; Mon, 2 May 2005 14:41:39 -0700 (PDT) Received: (from baerm@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id j42LfbkZ006678; Mon, 2 May 2005 14:41:38 -0700 X-Authentication-Warning: localhost.localdomain: baerm set sender to sbsm@mikesoffice.com using -f To: Ken Hornstein Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture From: Michael Baer X-Face: "*g#dUT3; 8M9AE5dLk\\b4G\cNCQkRb.g/2QwEXQKf.: (Ken Hornstein's message of "Thu, 21 Apr 2005 16:17:32 -0400") Message-ID: User-Agent: Gnus/5.090015 (Oort Gnus v0.15) XEmacs/21.4 (Rational FORTRAN, powerpc-unknown-linux) References: <200504212017.j3LKHUQO028810@ginger.cmf.nrl.navy.mil> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Given Ken's status of consensus message this may be too late, but in any case, IBK yes I think this would work best for the WG goals. EK maybe Could work, but I don't think it would work as well. OOBK no Could work, but I have doubts. (I'd really like this to be between a maybe and a no, i.e. less than EK but greater than no, but that's not a option in our voting style.) >>>>> "Ken" == Ken Hornstein writes: Ken> ISMS members, There's been a lot of discussion recently on Ken> the mailing list about the pros and cons of different Ken> security models. I think the discussion has been good, but Ken> unfortunately I don't think it's getting any closer to a Ken> consensus (I thank Robert for trying to draw things closer; Ken> unfortunately Juergen and I have been rather busy off-line, Ken> and I apologize for that). I know that some on the mailing Ken> list have expressed a preference for choosing a security Ken> protocol first, but we've been tasked with choosing the Ken> architecture first, and I believe that is the appropriate Ken> approach. Ken> Anyway, I'd like to call for a consensus on the security Ken> architecture. As we all know, the three choices are: Ken> - Out of band keying (the architecture used by EUSM) Ken> - In-bakd keying (the architecture used by SBSM) Ken> - Encapsulation keying (the architecture used by TLSM) Ken> What I would like to see is WG members express which Ken> architecture(s) they prefer (you can choose more than one, Ken> but please, don't choose all three). Please feel free to Ken> state your reasons for your choices, but in the interests Ken> of reaching consensus in a reasonable timeframe, I am Ken> asking that WG members please refrain from commenting on Ken> other people's choices unless they feel that the person has Ken> stated a fact which is obviously wrong. Ken> Thanks for your time, Ken> --Ken Ken> _______________________________________________ Isms Ken> mailing list Isms@lists.ietf.org Ken> https://www1.ietf.org/mailman/listinfo/isms -- isms@mikesoffice.com Michael Baer _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 17:57:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSiuf-0006xm-H7; Mon, 02 May 2005 17:57:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSiuf-0006xe-1a for isms@megatron.ietf.org; Mon, 02 May 2005 17:57:13 -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 RAA19786 for ; Mon, 2 May 2005 17:57:10 -0400 (EDT) Received: from pop-a065c05.pas.sa.earthlink.net ([207.217.121.183]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSj8O-0003YN-PJ for isms@ietf.org; Mon, 02 May 2005 18:11:26 -0400 Received: from h-64-105-137-177.snvacaid.dynamic.covad.net ([64.105.137.177] helo=oemcomputer) by pop-a065c05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DSiub-0005gT-00 for isms@ietf.org; Mon, 02 May 2005 14:57:09 -0700 Message-ID: <004301c54f62$2fe2a8e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Isms] RE: TLA Date: Mon, 2 May 2005 14:59:17 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 2.9 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Khanh Nguyen (khanhvn)" > To: "Tom Petch" ; > Sent: Monday, May 02, 2005 2:35 PM > Subject: [Isms] RE: TLA ... > USM breaks PFS by using the same privKey for all SNMP messages. ... No, the issue is how key changes work. With USM, cracking a key (by whatever means) allows decryption of all messages encrypted with that key. This is true of *any* system. Due to the way USM key updates work, cracking a USM key does not help the attacker figure out what key was used prior to the cracked key, unless the key update was done in the clear. What some folks would like, and what USM does *not* provide (unless one uses RFC 2786) is the ability to prevent cracking a key from helping an attacker figure out a key used *after* the cracked one. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 19:06:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSjzb-0004NT-9j; Mon, 02 May 2005 19:06:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSjzZ-0004Ko-9k for isms@megatron.ietf.org; Mon, 02 May 2005 19:06: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 TAA27552 for ; Mon, 2 May 2005 19:06:15 -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 1DSkDG-000596-Vu for isms@ietf.org; Mon, 02 May 2005 19:20:32 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 02 May 2005 16:06:08 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j42N5hi8022894; Mon, 2 May 2005 16:06:05 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 16:05:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: TLA Date: Mon, 2 May 2005 16:05:54 -0700 Message-ID: Thread-Topic: [Isms] RE: TLA Thread-Index: AcVPYkZXNViqQZhnRYyLq6eC1x/LOwABFX4g From: "Khanh Nguyen \(khanhvn\)" To: "Randy Presuhn" , X-OriginalArrivalTime: 02 May 2005 23:05:56.0087 (UTC) FILETIME=[7F022870:01C54F6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 > From: Randy Presuhn > > Hi - >=20 > > From: "Khanh Nguyen (khanhvn)" > ... > > USM breaks PFS by using the same privKey for all SNMP messages. > ... >=20 > No, the issue is how key changes work. >=20 > With USM, cracking a key (by whatever means) allows=20 > decryption of all messages encrypted with that key. This is=20 > true of *any* system. Of course. But the difference is USM keys are re-used repeatedly=20 for encryption, while in TLS, for example, the master keys are=20 generated dynamically using Diffie-Hellman or RSA key exchange. One the session is over, TLS master keys are destroyed - no=20 trace left. But in USM, the keys stay in the device=20 indefinitely (until someone changes them manually). That's why attackers can look back to decrypt past communications. Again, as I said, this is not USM fault, but a common problem for all sessionless methods. >=20 > Due to the way USM key updates work, cracking a USM key does=20 > not help the attacker figure out what key was used prior to=20 > the cracked key, unless the key update was done in the clear.=20 No argument about this. My point is that USM keys are very=20 static. They can be changed manually once in a while, but are not dynamically generated as in other session-based methods. =20 USM auth/privKeys are generated from the user passwords, and=20 people don't change their passwords every hour. BTW, USM lack of PFS is not something new. It has been mentioned earlier elsewhere (e.g. draft-ietf-isms-proposal-comparison-00) Khanh > What some folks would like, and what USM does *not* provide=20 > (unless one uses RFC 2786) is the ability to prevent cracking=20 > a key from helping an attacker figure out a key used *after*=20 > the cracked one. >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 19:38:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSkUe-0002lW-MP; Mon, 02 May 2005 19:38:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSkUc-0002gS-MY for isms@megatron.ietf.org; Mon, 02 May 2005 19:38:26 -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 TAA00628 for ; Mon, 2 May 2005 19:38:23 -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 1DSkiO-0005ny-JZ for isms@ietf.org; Mon, 02 May 2005 19:52:41 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 02 May 2005 16:38:17 -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 j42NcD2w012978; Mon, 2 May 2005 16:38:14 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Isms] RE: What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture Date: Mon, 2 May 2005 16:41:54 -0700 Message-ID: <7210B31550AC934A8637D6619739CE69051E8A04@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Isms] RE: What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture Thread-Index: AcVPT0It6IOH2GHvQiSQBmZ5jEvDIQAAoUWQAAbJf4A= From: "Salowey, Joe" To: "Fleischman, Eric" , "Tom Petch" X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org =20 > -----Original Message----- > From: Fleischman, Eric [mailto:eric.fleischman@boeing.com]=20 > Sent: Monday, May 02, 2005 1:12 PM > To: Tom Petch > Cc: isms@ietf.org > Subject: [Isms] RE: What is Out Of Band Keying;was CALL FOR=20 > CONSENSUS: ISMS Architecture >=20 > Thank you, Tom, for this excellent summary. However, my=20 > specific question was in regards to how **you** envision OOB=20 > keying being done in conjunction with Kerberos- and PKI-based=20 > authentication systems.=20 >=20 > If I were to answer my own question, I would say that both=20 > the manager and the agent need to independently query the=20 > same Kerberos TGS system in an OOB approach to get the=20 > credentials. But, since the queries are independent, I am=20 > unsure whether the answers would necessarily be associated=20 > (compatable) to permit interoperability. Hence my question to=20 > you since I am not confident that OOB works with Kerberos.=20 > Since I may well be overlooking something important, I'd=20 > appreciate learning your viewpoint.=20 >=20 [Joe] The capability for Kerberos support should be the same for all three approaches. I suppose there are multiple ways of implementing this, but I would expect the entity hosting the authoritative engine would have a service principal and a service key shared with the KDC and that the non-authoritative engine would have to obtain a service ticket for that service principal. =20 > On the other hand, I think that PKI is more straight-forward=20 > (if authentication is being done via signing and if both are=20 > using the same PKI system) and shouldn't be problematic for OOB.=20 >=20 > How do you see things?=20 >=20 > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Monday, May 02, 2005 11:04 AM > To: Fleischman, Eric > Cc: isms@ietf.org > Subject: What is Out Of Band Keying; was CALL FOR CONSENSUS:=20 > ISMS Architecture >=20 >=20 > To quote Ken, from March >=20 > "Out of Band Keying" >=20 > This is the approach chosen by EUSM. Essentially, a=20 > seperate protocol > exchange is conducted between the manager and agent (or a=20 > third party) > and a key is then established/derived for use with standard USM. >=20 > Features: >=20 > - Can make use of existing USM (already-analyzed protocol). > - Likely wide variety of IETF protocols to use as out-of-band keying > protocol > - Encryption/checksum modes limited to ones supported by USM > - Extra care would be required to assure keying material=20 > derived from > out-of-band exchange is matched with a particular USM session." >=20 > The ensuing discussion suggested that there was not a one to=20 > one mapping > between the three proposals and the three methods of key derivation, > rather several could use several - I think someone did=20 > produce a matrix > (why don't we have a web site of things like this?) >=20 > If the manager conducts an exchange with a third party, and agent > conducts an exchange with a third party, be that Kerberos or > proprietary, and so keys are derived for the security needs=20 > of the SNMP > PDU, then I take that to be Out Of Band. Which model PKI is=20 > depends for > me where the certificates are; could be any. >=20 > You need to check with Ken; it was he who introduced the=20 > terminology to > my vocabulary >=20 > (In passing, when I say IBM, think RACF, which you may be=20 > familiar with) >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Fleischman, Eric" > To: "Tom Petch" > Cc: > Sent: Monday, May 02, 2005 7:54 PM > Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture >=20 >=20 > A generic question for you, Tom: >=20 > What is your concept of operations (CONOPS) for Out of band=20 > keying? For > example, is a PKI system in which authentication occurs through > digitally signing a message an out of band keying example from your > perspective? If not, what is you view for how OOB would work=20 > when using > Kerberos or PKI authentication systems? >=20 > --Eric >=20 >=20 > Tom Petch [mailto:nwnetworks@dial.pipex.com] wrote: > >Out of Band keying is my preference. > > > >The discussions of the past few months have shown > >(what I think . of as) flaws in all the approaches > >and I now think Out of Band has the greatest > >flexibility to produce a workable proposal. >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 19:41:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSkXk-0006dN-Qt; Mon, 02 May 2005 19:41:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSkXj-0006dC-Cd for isms@megatron.ietf.org; Mon, 02 May 2005 19:41:39 -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 TAA01132 for ; Mon, 2 May 2005 19:41:36 -0400 (EDT) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSklU-0005t8-Fp for isms@ietf.org; Mon, 02 May 2005 19:55:53 -0400 Received: from h-64-105-137-177.snvacaid.dynamic.covad.net ([64.105.137.177] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DSkXb-0007Gf-00 for isms@ietf.org; Mon, 02 May 2005 16:41:31 -0700 Message-ID: <001e01c54f70$c5a232c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Isms] RE: TLA Date: Mon, 2 May 2005 16:43:41 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 2.9 (++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Khanh Nguyen (khanhvn)" > To: "Randy Presuhn" ; > Sent: Monday, May 02, 2005 4:05 PM > Subject: RE: [Isms] RE: TLA ... > Of course. But the difference is USM keys are re-used repeatedly > for encryption, while in TLS, for example, the master keys are > generated dynamically using Diffie-Hellman or RSA key exchange. > One the session is over, TLS master keys are destroyed - no > trace left. But in USM, the keys stay in the device > indefinitely (until someone changes them manually). That's > why attackers can look back to decrypt past communications. > > Again, as I said, this is not USM fault, but a common problem > for all sessionless methods. Let's not confuse PFS with the desire to limit key lifetimes. One can limit key lifetimes without providing PFS, and one can have PFS without limiting key lifetimes. Both are valuable, but they're not the same thing. ... > My point is that USM keys are very > static. They can be changed manually once in a while, but are > not dynamically generated as in other session-based methods. USM does not limit the frequency of key updates. That's up to the user/SA. The remaining question is that of limiting key lifetime, which can be accomplished by far less drastic means than these. For example, an automated security administrator could delete "old" usm user entries. When a user app needed to interact with a managed system, it could ask the security administrator application to (re-)create its entry, possibly using 2786 to establish the key(s), and possibly consulting with some AAA infrastructure. What would require some thought/discussion is the question of how the end of a session is detected. For example, users could be permitted to delete their own usm user entries, or the security administrator application could do it on their behalf. > USM auth/privKeys are generated from the user passwords, and > people don't change their passwords every hour. ... Passphrases, but I agree with this point inasmuch as it applies to authentication keys. Encryption keys are a different matter, particularly in light of how one might use RFC 2786. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 19:50:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSkgR-0003ne-RV; Mon, 02 May 2005 19:50:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSkgQ-0003ls-GH for isms@megatron.ietf.org; Mon, 02 May 2005 19:50: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 TAA01824 for ; Mon, 2 May 2005 19:50:35 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSkuB-00062l-Co for isms@ietf.org; Mon, 02 May 2005 20:04:52 -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 QAA21811; Mon, 2 May 2005 16:50:27 -0700 (PDT) Received: from XCH-NWBH-02.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 j42NoQm00574; Mon, 2 May 2005 18:50:26 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 16:50:24 -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] RE: What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture Date: Mon, 2 May 2005 16:49:50 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC273@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] RE: What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture Thread-Index: AcVPT0It6IOH2GHvQiSQBmZ5jEvDIQAAoUWQAAbJf4AAAOx48A== From: "Fleischman, Eric" To: "Salowey, Joe" X-OriginalArrivalTime: 02 May 2005 23:50:24.0936 (UTC) FILETIME=[B5C43280:01C54F71] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Joe, Thank you for helping me better understand how OOB keying would work with Kerberos. I understand your reply as stating that the network manager needs to query the Ticket Granting Service to access a specific SNMP Agent, which Kerberos treats like a Server. The SNMP Agent has been "pre-registered" (or whatever the proper term is) to the Kerberos system such that the SNMP Agent itself never needs to independently obtain the Network Manager's credentials, thus since only the client (i.e., the network manager) is doing the querying, the two have no opportunity of ever getting out-of-synch with each other (as long as the tickets are valid). Is this accurate? Thanks. --Eric >From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 >[Joe] The capability for Kerberos support should be the same for all >three approaches. I suppose there are multiple ways of implementing >this, but I would expect the entity hosting the authoritative engine >would have a service principal and a service key shared with the KDC and >that the non-authoritative engine would have to obtain a service ticket >for that service principal. =20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 20:06:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSkvf-00067R-Qx; Mon, 02 May 2005 20:06:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSkvd-00066f-QS for isms@megatron.ietf.org; Mon, 02 May 2005 20:06: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 UAA02855 for ; Mon, 2 May 2005 20:06:20 -0400 (EDT) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSl9P-0006Kd-IW for isms@ietf.org; Mon, 02 May 2005 20:20:35 -0400 Received: from h-64-105-137-177.snvacaid.dynamic.covad.net ([64.105.137.177] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DSkvb-0006nC-00 for isms@ietf.org; Mon, 02 May 2005 17:06:19 -0700 Message-ID: <000401c54f74$3be39b60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <474EEBD229DF754FB83D256004D021080EC273@XCH-NW-6V1.nw.nos.boeing.com> Subject: Re: [Isms] RE: What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture Date: Mon, 2 May 2005 17:08:27 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 2.9 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Fleischman, Eric" > To: "Salowey, Joe" > Cc: > Sent: Monday, May 02, 2005 4:49 PM > Subject: RE: [Isms] RE: What is Out Of Band Keying;was CALL FOR CONSENSUS: ISMS Architecture ... > such that the SNMP Agent itself never needs to independently obtain the > Network Manager's credentials, thus since only the client (i.e., the > network manager) is doing the querying, the two have no opportunity of > ever getting out-of-synch with each other (as long as the tickets are > valid). Is this accurate? Thanks. If one ignores authenticated or encrypted notifications transmitted as Informs, proxy, and systems implementing, for example, the disman WG's MIBs. It was not on a whim that the SNMPv3 working group eliminated the manager/agent distinction from the architecture. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 20:07:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSkwp-0007WN-F5; Mon, 02 May 2005 20:07:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSkwn-0007WE-Jf for isms@megatron.ietf.org; Mon, 02 May 2005 20:07:33 -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 UAA02940 for ; Mon, 2 May 2005 20:07:32 -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 1DSlAY-0006MA-Tj for isms@ietf.org; Mon, 02 May 2005 20:21:48 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 02 May 2005 17:07:24 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4307Khu010022; Mon, 2 May 2005 17:07:21 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Isms] RE: What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture Date: Mon, 2 May 2005 17:11:01 -0700 Message-ID: <7210B31550AC934A8637D6619739CE69051E8A13@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Isms] RE: What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture Thread-Index: AcVPT0It6IOH2GHvQiSQBmZ5jEvDIQAAoUWQAAbJf4AAAOx48AAAmSvA From: "Salowey, Joe" To: "Fleischman, Eric" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org =20 > -----Original Message----- > From: Fleischman, Eric [mailto:eric.fleischman@boeing.com]=20 > Sent: Monday, May 02, 2005 4:50 PM > To: Salowey, Joe > Cc: isms@ietf.org > Subject: RE: [Isms] RE: What is Out Of Band Keying;was CALL=20 > FOR CONSENSUS: ISMS Architecture >=20 > Joe, >=20 > Thank you for helping me better understand how OOB keying=20 > would work with Kerberos. I understand your reply as stating=20 > that the network manager needs to query the Ticket Granting=20 > Service to access a specific SNMP Agent, which Kerberos=20 > treats like a Server. The SNMP Agent has been=20 > "pre-registered" (or whatever the proper term is) to the=20 > Kerberos system such that the SNMP Agent itself never needs=20 > to independently obtain the Network Manager's credentials,=20 > thus since only the client (i.e., the network manager) is=20 > doing the querying, the two have no opportunity of ever=20 > getting out-of-synch with each other (as long as the tickets=20 > are valid). Is this accurate? Thanks. >=20 [Joe] yes.=20 > --Eric >=20 > >From: Salowey, Joe [mailto:jsalowey@cisco.com] [Joe] The=20 > capability for=20 > >Kerberos support should be the same for all three approaches. I=20 > >suppose there are multiple ways of implementing this, but I would=20 > >expect the entity hosting the authoritative engine would=20 > have a service=20 > >principal and a service key shared with the KDC > and > >that the non-authoritative engine would have to obtain a=20 > service ticket=20 > >for that service principal. >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 02 20:33:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSlM7-0006i1-KE; Mon, 02 May 2005 20:33:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSlM5-0006ht-Mz for isms@megatron.ietf.org; Mon, 02 May 2005 20:33:41 -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 UAA05254 for ; Mon, 2 May 2005 20:33:40 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSlZs-0006tp-8T for isms@ietf.org; Mon, 02 May 2005 20:47:56 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 02 May 2005 17:33:32 -0700 X-IronPort-AV: i="3.92,147,1112598000"; d="scan'208"; a="633781650:sNHT32127484" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j430XThu000707; Mon, 2 May 2005 17:33:30 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture Date: Mon, 2 May 2005 17:37:10 -0700 Message-ID: <7210B31550AC934A8637D6619739CE69051E8A26@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Isms] CALL FOR CONSENSUS: ISMS Architecture Thread-Index: AcVNMPz0n7vXCBL3RvWRjUQk5oKz0wCQyDKQ From: "Salowey, Joe" To: "Wes Hardaker" X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org =20 > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com]=20 > Sent: Friday, April 29, 2005 7:58 PM > To: Salowey, Joe > Cc: Juergen Quittek; isms@ietf.org > Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture >=20 > >>>>> On Fri, 29 Apr 2005 17:56:46 -0700, "Salowey, Joe"=20 > said: >=20 > Joe> The motivation for EUSM was to implement a solution with minimal=20 > Joe> changes to USM. >=20 > For reasons I've still yet to see posted to the list,=20 > although I've asked. >=20 [Joe] In-band and encapsulation approaches either require the addition of new fields to SNMPv3/USM messages, changes to the processing of SNMPv3/USM messages or both.=20 > Joe> For this reason we choose to use out-of-band keying. I am still=20 > Joe> strongly in favor of out-of-band keying. >=20 > Every architecture could use USM underneath for traffic=20 > protection, so that's not really a good argument for OOB, IMHO. >=20 [Joe] Out-of-band minimizes the change to SNMPv3 and USM. An in-band exchange has more impact on existing processing. > Joe> I have not been convinced by any of the discussion that=20 > out-of-band=20 > Joe> keying is any more difficult or problematic than any of=20 > the other=20 > Joe> methods so I am opposed to both encapsulation and=20 > in-band keying as=20 > Joe> I believe they both will require more changes to existing USM=20 > Joe> implementations. >=20 > If you want to use USM and if you assume it will be used then=20 > it probably won't matter which architecture you pick because=20 > the results of implementing any of the architectures could be=20 > feeding the keys into USM. This is truly identical for OOB=20 > and for IB. (there may be other reasons for not wanting to=20 > pick one or the other, but compatibility with USM can be done=20 > with either). EK is less straight forward, though it could=20 > be done that way but I'm not sure you'd want to. >=20 > Joe> If it is shown that another keying architecture is less=20 > invasive to=20 > Joe> USM or the working group decides that protection=20 > mechanisms within=20 > Joe> USM need to be replaced then I would reconsider my opposition. >=20 > Can you explain *why* the other architectures are more invasive? >=20 > Lets take a concrete example. Consider one instance of IBK=20 > that has already been defined (just for example, I'm not=20 > arguing at the moment that it's the right choice for an IBK=20 > implementation because it's not relevant here): SBSM. The=20 > results of the keying exchange of SBSM could simply result in=20 > a USM principal ending up with the negotiated keys. Can you=20 > explain how that's affecting USM in some way that OOB wouldn't be? >=20 [Joe] In an in-band approach such as SBSM you need to add new fields and processing to USM/SNMPv3. In an out-of-band approach that uses USM you don't. > -- > Wes Hardaker > Sparta, Inc. >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 03 11:34:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSzPQ-0004Ph-96; Tue, 03 May 2005 11:34:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSzPP-0004OV-03 for isms@megatron.ietf.org; Tue, 03 May 2005 11:34: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 LAA00903 for ; Tue, 3 May 2005 11:34:00 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSzdD-0004IG-8Q for isms@ietf.org; Tue, 03 May 2005 11:48:22 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA19353; Tue, 3 May 2005 10:33:40 -0500 (CDT) Received: from xch-nwbh-01.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 j43FXdm16391; Tue, 3 May 2005 10:33:40 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by xch-nwbh-01.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 08:33:35 -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] CALL FOR CONSENSUS: ISMS Architecture Date: Tue, 3 May 2005 08:33:24 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC276@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] CALL FOR CONSENSUS: ISMS Architecture Thread-Index: AcVNMPz0n7vXCBL3RvWRjUQk5oKz0wCQyDKQAB/2PoA= From: "Fleischman, Eric" To: "Salowey, Joe" , "Wes Hardaker" X-OriginalArrivalTime: 03 May 2005 15:33:35.0205 (UTC) FILETIME=[7831F950:01C54FF5] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 >From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 >[Joe] In-band and encapsulation approaches either require the addition >of new fields to SNMPv3/USM messages, changes to the processing of >SNMPv3/USM messages or both.=20 > >[Joe] Out-of-band minimizes the change to SNMPv3 and USM. An in-band >exchange has more impact on existing processing. Joe, Your observations make sense to me for symmetric keying approaches like Kerberos. However, I am having trouble following them to your logical conclusion. I am stumbling because I suspect that any asymmetric keying mechanism, such as PKI, will also require changes to the SNMP packet formats, perhaps including the addition of new fields. Since extending SNMPv3 to include both symmetric and asymmetric keying technologies is an explicit goal of mine (i.e., I want SNMP to leverage the major enterprise-wide authentication systems), I don't understand why this particular argument would lead us to prefer OOB keying. Or perhaps I am overlooking something important? If so, I'd appreciate better understanding your insights. Thanks. --Eric _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 03 11:44:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSzZI-0007lZ-TZ; Tue, 03 May 2005 11:44:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSzZI-0007jZ-5N for isms@megatron.ietf.org; Tue, 03 May 2005 11:44:16 -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 LAA01952 for ; Tue, 3 May 2005 11:44:11 -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 1DSznA-0004YC-03 for isms@ietf.org; Tue, 03 May 2005 11:58:36 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 849CE11D944; Tue, 3 May 2005 08:44:04 -0700 (PDT) From: Wes Hardaker To: "Salowey, Joe" Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture Organization: Sparta References: <7210B31550AC934A8637D6619739CE69051E8A26@e2k-sea-xch2.sea-alpha.cisco.com> Date: Tue, 03 May 2005 08:44:03 -0700 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Mon, 2 May 2005 17:37:10 -0700, "Salowey, Joe" said: Joe> [Joe] In-band and encapsulation approaches either require the Joe> addition of new fields to SNMPv3/USM messages, changes to the Joe> processing of SNMPv3/USM messages or both. No it doesn't. For in-band, if you do something within a new SNMPv3 security model (which I realize you probably want but you haven't stated that clearly) but pass the keys to a USM user at the completion of that transaction, USM doesn't change at all. It stays exactly the same. USM could still be used to protect real SNMP PDU traffic. Without modification. None what so ever. Only the keying would be in-band. For encapsulation, you can still use USM underneath in the SNMPv3 part of the message (say with a security name selected during the encapsulation exchange) if you so choose. It would be a waste of bandwidth but it could be done. Heck, you could even process it like you would a USM message if you wanted to burn the CPU cycles. But you wouldn't have to modify USM at all, hence you should be just as happy. If you look at a device as a whole, you *must* modify something. Somehow someway you need to modify it to get the new keys and/or new exchange in there. I don't think OOB has any improvement over the size of that new code set. In fact, in my case at least, I think it's a huge hit over the other two possibilities. In fact, if I was going to pick a method that offered the least impact in both terms of existing stuff in the box and not having to modify the agent I'd probably pick encapsulation not OOB. In OOB you still have to inject the keys which takes a potentially entirely new service and potentially code to get the keys installed into a running service, plus potentially vendor interoperability or incompatibility as I've spelled out previously. It's a *huge* amount of work in my eyes to support OOB. So much so I'm not sure I could ever implement it in a non-intrusive way. I don't think comparing only the work required to modify an agent is the right way to go. You have to compare the work in modifying everything needed within a device as well as everything needed within a manager and potentially other software (radius servers, eg). Joe> [Joe] In an in-band approach such as SBSM you need to add new Joe> fields and processing to USM/SNMPv3. As explained above, that's simply not true. It would require no modifications to USM if you wanted to use USM services to protect the messages themselves. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 03 14:26:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT26F-0004j3-U7; Tue, 03 May 2005 14:26:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT26E-0004iy-1m for isms@megatron.ietf.org; Tue, 03 May 2005 14:26:26 -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 OAA18375 for ; Tue, 3 May 2005 14:26:24 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT2K9-0000lk-31 for isms@ietf.org; Tue, 03 May 2005 14:40:50 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 03 May 2005 11:26:15 -0700 X-IronPort-AV: i="3.92,151,1112598000"; d="scan'208"; a="633930944:sNHT25909172" Received: from kaushik-w2k03.cisco.com (dhcp-171-69-126-100.cisco.com [171.69.126.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j43IQ5L0017031; Tue, 3 May 2005 11:26:06 -0700 (PDT) Message-Id: <6.2.0.14.0.20050503102434.04f02a60@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 03 May 2005 11:26:05 -0700 To: "Fleischman, Eric" From: Kaushik Narayan Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture In-Reply-To: <474EEBD229DF754FB83D256004D021080EC276@XCH-NW-6V1.nw.nos.b oeing.com> References: <474EEBD229DF754FB83D256004D021080EC276@XCH-NW-6V1.nw.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Eric, The key benefit of OOB is that the SNMP protocol does not need to understand how the keying the happens. The SNMP protocol continues to use USM for protection of SNMP packets, the keys used by USM for protection are created by an out-of-band Key Setup Protocol. The Key Setup protocol supports both symmetric and asymmetric keying. regards, kaushik! At 08:33 AM 5/3/2005, Fleischman, Eric wrote: > >From: Salowey, Joe [mailto:jsalowey@cisco.com] > >[Joe] In-band and encapsulation approaches either require the addition > >of new fields to SNMPv3/USM messages, changes to the processing of > >SNMPv3/USM messages or both. > > > >[Joe] Out-of-band minimizes the change to SNMPv3 and USM. An in-band > >exchange has more impact on existing processing. > >Joe, > >Your observations make sense to me for symmetric keying approaches like >Kerberos. However, I am having trouble following them to your logical >conclusion. I am stumbling because I suspect that any asymmetric keying >mechanism, such as PKI, will also require changes to the SNMP packet >formats, perhaps including the addition of new fields. Since extending >SNMPv3 to include both symmetric and asymmetric keying technologies is >an explicit goal of mine (i.e., I want SNMP to leverage the major >enterprise-wide authentication systems), I don't understand why this >particular argument would lead us to prefer OOB keying. Or perhaps I am >overlooking something important? If so, I'd appreciate better >understanding your insights. Thanks. > >--Eric > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 03 14:39:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT2JA-0000n9-31; Tue, 03 May 2005 14:39:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT2J7-0000n3-V5 for isms@megatron.ietf.org; Tue, 03 May 2005 14:39: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 OAA19581 for ; Tue, 3 May 2005 14:39:42 -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 1DT2X1-000154-KE for isms@ietf.org; Tue, 03 May 2005 14:54:08 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 03 May 2005 11:39:31 -0700 X-IronPort-AV: i="3.92,151,1112598000"; d="scan'208"; a="257784902:sNHT6859427660" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j43IdOL1027041; Tue, 3 May 2005 11:39:26 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture Date: Tue, 3 May 2005 11:43:09 -0700 Message-ID: <7210B31550AC934A8637D6619739CE69051E8BC3@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Isms] CALL FOR CONSENSUS: ISMS Architecture Thread-Index: AcVNMPz0n7vXCBL3RvWRjUQk5oKz0wCQyDKQAB/2PoAABUJacA== From: "Salowey, Joe" To: "Fleischman, Eric" , "Wes Hardaker" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 > Joe, >=20 > Your observations make sense to me for symmetric keying=20 > approaches like Kerberos. However, I am having trouble=20 > following them to your logical conclusion. I am stumbling=20 > because I suspect that any asymmetric keying mechanism, such=20 > as PKI, will also require changes to the SNMP packet formats,=20 > perhaps including the addition of new fields. Since extending > SNMPv3 to include both symmetric and asymmetric keying=20 > technologies is an explicit goal of mine (i.e., I want SNMP=20 > to leverage the major enterprise-wide authentication=20 > systems), I don't understand why this particular argument=20 > would lead us to prefer OOB keying. Or perhaps I am=20 > overlooking something important? If so, I'd appreciate better=20 > understanding your insights. Thanks. [Joe] So you could integrate with public key in (at least) two different ways. =20 1) You could use a public key exchange to establish a shared secret that is valid for several exchanges. I believe this is essentially what all of the proposals suggest doing and is similar to the way TLS, SSH and IKE work. In the case of an out-of-band approach the key exchange protocol would execute outside the SNMP protocol and the resulting keys would be configured in the SNMP engines. The out of band key exchange could be based on public key cryptography and credentials. The same is true for in-band and encapsulation except that the key exchange would happen within SNMP. As Kaushik mentioned the advantage with out-of-band is the SNMP protocol does not have to understand how the keying happens. 2) You could protect each SNMP PDU using public key similar to what you would do with an email message using SMIME or CMS. In this case each protocol message is protected with a different key which encrypted under the senders private key. I don't think anyone has suggested this since it would be very complicated, computationally intensive, only work when all parties had public key credentials, and probably result in really long messages. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 03 14:51:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT2Uq-00049O-Nw; Tue, 03 May 2005 14:51:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT2Up-00049J-AM for isms@megatron.ietf.org; Tue, 03 May 2005 14:51: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 OAA20611 for ; Tue, 3 May 2005 14:51:49 -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 1DT2ik-0001Nj-KD for isms@ietf.org; Tue, 03 May 2005 15:06:15 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 7159211D944; Tue, 3 May 2005 11:51:45 -0700 (PDT) From: Wes Hardaker To: Kaushik Narayan Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture Organization: Sparta References: <474EEBD229DF754FB83D256004D021080EC276@XCH-NW-6V1.nw.nos.boeing.com> <6.2.0.14.0.20050503102434.04f02a60@email.cisco.com> Date: Tue, 03 May 2005 11:51:44 -0700 In-Reply-To: <6.2.0.14.0.20050503102434.04f02a60@email.cisco.com> (Kaushik Narayan's message of "Tue, 03 May 2005 11:26:05 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Tue, 03 May 2005 11:26:05 -0700, Kaushik Narayan said: Kaushik> The key benefit of OOB is that the SNMP protocol does not need to Kaushik> understand how the keying the happens. The SNMP protocol continues Kaushik> to use USM for protection of SNMP packets, the keys used by USM for Kaushik> protection are created by an out-of-band Key Setup Protocol. The Key Kaushik> Setup protocol supports both symmetric and asymmetric keying. Something else does though, and that something else doesn't understand SNMP today. Either way something needs to be taught something new. The keys won't magically get from an existing OOB service into an SNMP Engine without modification of at least the OOB service and quite possibly the SNMP engine (I'm not an expert on most of the SNMP stacks out there, but I doubt all or even most of them provide an API/RPC that lets you insert running keys into a running SNMP engine without modification to the SNMP stack to make that happen). -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 03 15:03:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT2gZ-0007lS-QV; Tue, 03 May 2005 15:03:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT2gX-0007lE-VL for isms@megatron.ietf.org; Tue, 03 May 2005 15:03:58 -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 PAA21860 for ; Tue, 3 May 2005 15:03:56 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT2uU-0001f3-8O for isms@ietf.org; Tue, 03 May 2005 15:18:22 -0400 Received: from h-64-105-34-164.snvacaid.dynamic.covad.net ([64.105.34.164] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DT2gV-0006wq-00 for isms@ietf.org; Tue, 03 May 2005 12:03:55 -0700 Message-ID: <005201c55013$282bffa0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <474EEBD229DF754FB83D256004D021080EC276@XCH-NW-6V1.nw.nos.boeing.com><6.2.0.14.0.20050503102434.04f02a60@email.cisco.com> Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture Date: Tue, 3 May 2005 12:05:22 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Wes Hardaker" > To: "Kaushik Narayan" > Cc: > Sent: Tuesday, May 03, 2005 11:51 AM > Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture > > >>>>> On Tue, 03 May 2005 11:26:05 -0700, Kaushik Narayan said: > > Kaushik> The key benefit of OOB is that the SNMP protocol does not need to > Kaushik> understand how the keying the happens. The SNMP protocol continues > Kaushik> to use USM for protection of SNMP packets, the keys used by USM for > Kaushik> protection are created by an out-of-band Key Setup Protocol. The Key > Kaushik> Setup protocol supports both symmetric and asymmetric keying. > > Something else does though, and that something else doesn't understand > SNMP today. Either way something needs to be taught something new. > The keys won't magically get from an existing OOB service into an SNMP > Engine without modification of at least the OOB service and quite > possibly the SNMP engine (I'm not an expert on most of the SNMP stacks > out there, but I doubt all or even most of them provide an API/RPC > that lets you insert running keys into a running SNMP engine without > modification to the SNMP stack to make that happen). ... However, any SNMP stack out there that supports USM should provide the ability to use SNMPv3 to set the keys. Rather than modifying the SNMP stack, or modifying the existing "OOB service", one could use an application acting on behalf of the security administrator to talk to the OOB service, and use SNMPv3 to set the USM keys. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 03 15:46:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT3Le-0004eQ-36; Tue, 03 May 2005 15:46:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT3Lc-0004e8-ER for isms@megatron.ietf.org; Tue, 03 May 2005 15:46:24 -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 PAA27102 for ; Tue, 3 May 2005 15:46:22 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT3ZX-0002rz-U7 for isms@ietf.org; Tue, 03 May 2005 16:00:49 -0400 Received: from pc6 (1Cust129.tnt103.lnd4.gbr.da.uu.net [213.116.54.129]) by galaxy.systems.pipex.net (Postfix) with SMTP id D3F9EE0001E2; Tue, 3 May 2005 20:46:11 +0100 (BST) Message-ID: <014f01c5500f$d60f8500$0601a8c0@pc6> From: "Tom Petch" To: "Fleischman, Eric" References: <474EEBD229DF754FB83D256004D021080EC273@XCH-NW-6V1.nw.nos.boeing.com> Date: Tue, 3 May 2005 20:40:27 +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: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: [Isms] Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture 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 Eric A belated response to your question to me about Kerberos. (I think Joe has dealt with everything else). I like it and would be happy to see it used more widely. Historically I have associated it with Unix platforms but since Microsoft has made it part of Windows 200x Server, I expect it will become much more widely known and deployed. So although Wes' survey showed only 10% (from memory) interest, I expect that to grow. But it does require, like any three party system, reliable and rapid communications at session setup time, which is fine when the agent is an enterprise server, may not be for the workgroup switch or access router. Rather than a triangle, our communications may be a fast reliable pipe from security server to SNMP manager-server but not from manager to agent and even less so from agent back to security server. SNMPv1 seemed to cater for an really unreliable network (as opposed to one that was only nominally unreliable) and that also colours my thinking about how sophisticated session setup should be for SNMP. As ever, I want a scalable solution. PKI? limited experience on a Windows platform and there seemed to be quite a bit of administration (eg revocation lists) which are fine on a central server, less so on a distant network box. Tom Petch ----- Original Message ----- From: "Fleischman, Eric" To: "Salowey, Joe" Cc: Sent: Tuesday, May 03, 2005 1:49 AM Subject: RE: [Isms] RE: What is Out Of Band Keying;was CALL FOR CONSENSUS: ISMS Architecture Joe, Thank you for helping me better understand how OOB keying would work with Kerberos. I understand your reply as stating that the network manager needs to query the Ticket Granting Service to access a specific SNMP Agent, which Kerberos treats like a Server. The SNMP Agent has been "pre-registered" (or whatever the proper term is) to the Kerberos system such that the SNMP Agent itself never needs to independently obtain the Network Manager's credentials, thus since only the client (i.e., the network manager) is doing the querying, the two have no opportunity of ever getting out-of-synch with each other (as long as the tickets are valid). Is this accurate? Thanks. --Eric >From: Salowey, Joe [mailto:jsalowey@cisco.com] >[Joe] The capability for Kerberos support should be the same for all >three approaches. I suppose there are multiple ways of implementing >this, but I would expect the entity hosting the authoritative engine >would have a service principal and a service key shared with the KDC and >that the non-authoritative engine would have to obtain a service ticket >for that service principal. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 03 16:35:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT47C-0002fb-Sd; Tue, 03 May 2005 16:35:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT47A-0002el-Vn for isms@megatron.ietf.org; Tue, 03 May 2005 16:35:33 -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 QAA10219 for ; Tue, 3 May 2005 16:35:30 -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 1DT4L7-0007OA-5a for isms@ietf.org; Tue, 03 May 2005 16:49:58 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 21F6211D944; Tue, 3 May 2005 13:35:27 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture Organization: Sparta References: <474EEBD229DF754FB83D256004D021080EC276@XCH-NW-6V1.nw.nos.boeing.com> <6.2.0.14.0.20050503102434.04f02a60@email.cisco.com> <005201c55013$282bffa0$7f1afea9@oemcomputer> Date: Tue, 03 May 2005 13:35:25 -0700 In-Reply-To: <005201c55013$282bffa0$7f1afea9@oemcomputer> (Randy Presuhn's message of "Tue, 3 May 2005 12:05:22 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Tue, 3 May 2005 12:05:22 -0700, "Randy Presuhn" said: Randy> However, any SNMP stack out there that supports USM should Randy> provide the ability to use SNMPv3 to set the keys. Rather than Randy> modifying the SNMP stack, or modifying the existing "OOB Randy> service", one could use an application acting on behalf of the Randy> security administrator to talk to the OOB service, and use Randy> SNMPv3 to set the USM keys. The thought had crossed my mind as well, but that still requires either provisioning of the SNMPv3 service with an initial USM user (bad IMHO) or requires the service to be run on the same host and a noAuthNoPriv user with access privileges tied to the loopback address (or any other form of an internal-to-the-box-trusted-network) which probably doesn't exist in most implementations today. Requiring the setup of just one USM user instead of X is still bad, IMHO, because operators don't want to do this today either. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 03 17:07:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT4bm-0004bu-CD; Tue, 03 May 2005 17:07:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT4bj-0004bl-L7 for isms@megatron.ietf.org; Tue, 03 May 2005 17:07:09 -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 RAA12391 for ; Tue, 3 May 2005 17:07:05 -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 1DT4ph-000872-0C for isms@ietf.org; Tue, 03 May 2005 17:21:33 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 03 May 2005 14:03:36 -0700 X-IronPort-AV: i="3.92,152,1112598000"; d="scan'208"; a="257845410:sNHT1344893264" 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 j43L3Y2w007612; Tue, 3 May 2005 14:03:34 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture Date: Tue, 3 May 2005 14:07:15 -0700 Message-ID: <7210B31550AC934A8637D6619739CE69051E8C6F@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Isms] CALL FOR CONSENSUS: ISMS Architecture Thread-Index: AcVP94G8TlmUTsX9Q2CByDVIl4rD6AAKRN+g From: "Salowey, Joe" To: "Wes Hardaker" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 It seems that in order for in-band key exchange to work you would need to add data and extra processing to SNMP messages to perform the key exchange. For example SBSM defines more new ASN.1 SEQUENCES than what is defined for USM. In contrast an out-of-band approach like EUSM defines none. The amount of implementation work for out-of-band vs. in-band will be difficult to quantitatively measure for different code bases. I do know that in our prototype we were able to leverage a lot of existing code on agents, managers and AAA. I primarily want to avoid inventing a new key exchange protocol and I think we should make as much re-use of USM as possible. I would prefer not to burden SNMP implementations with the added data and processing complexities of key exchange that in-band requires. If it came down to creating another security model different than USM then I would prefer to see an standard encapsulation mechanism such as TLS.=20 Joe > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com]=20 > Sent: Tuesday, May 03, 2005 8:44 AM > To: Salowey, Joe > Cc: Juergen Quittek; isms@ietf.org > Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture >=20 > >>>>> On Mon, 2 May 2005 17:37:10 -0700, "Salowey, Joe"=20 > said: >=20 > Joe> [Joe] In-band and encapsulation approaches either require the=20 > Joe> addition of new fields to SNMPv3/USM messages, changes to the=20 > Joe> processing of SNMPv3/USM messages or both. >=20 > No it doesn't. >=20 > For in-band, if you do something within a new SNMPv3 security=20 > model (which I realize you probably want but you haven't stated that > clearly) but pass the keys to a USM user at the completion of=20 > that transaction, USM doesn't change at all. It stays=20 > exactly the same. > USM could still be used to protect real SNMP PDU traffic. =20 > Without modification. None what so ever. Only the keying=20 > would be in-band. >=20 > For encapsulation, you can still use USM underneath in the=20 > SNMPv3 part of the message (say with a security name selected=20 > during the encapsulation exchange) if you so choose. It=20 > would be a waste of bandwidth but it could be done. Heck,=20 > you could even process it like you would a USM message if you=20 > wanted to burn the CPU cycles. But you wouldn't have to=20 > modify USM at all, hence you should be just as happy. >=20 > If you look at a device as a whole, you *must* modify something. > Somehow someway you need to modify it to get the new keys=20 > and/or new exchange in there. I don't think OOB has any=20 > improvement over the size of that new code set. In fact, in=20 > my case at least, I think it's a huge hit over the other two=20 > possibilities. In fact, if I was going to pick a method that=20 > offered the least impact in both terms of existing stuff in=20 > the box and not having to modify the agent I'd probably pick=20 > encapsulation not OOB. In OOB you still have to inject the=20 > keys which takes a potentially entirely new service and=20 > potentially code to get the keys installed into a running=20 > service, plus potentially vendor interoperability or=20 > incompatibility as I've spelled out previously. It's a=20 > *huge* amount of work in my eyes to support OOB. So much so=20 > I'm not sure I could ever implement it in a non-intrusive way. >=20 > I don't think comparing only the work required to modify an=20 > agent is the right way to go. You have to compare the work=20 > in modifying everything needed within a device as well as=20 > everything needed within a manager and potentially other=20 > software (radius servers, eg). >=20 > Joe> [Joe] In an in-band approach such as SBSM you need to add new=20 > Joe> fields and processing to USM/SNMPv3. >=20 > As explained above, that's simply not true. It would require=20 > no modifications to USM if you wanted to use USM services to=20 > protect the messages themselves. >=20 > -- > Wes Hardaker > Sparta, Inc. >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 03 17:11:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT4gL-0006T1-3B; Tue, 03 May 2005 17:11:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT4gJ-0006St-IP for isms@megatron.ietf.org; Tue, 03 May 2005 17:11: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 RAA12821 for ; Tue, 3 May 2005 17:11:49 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT4u9-0008FK-QS for isms@ietf.org; Tue, 03 May 2005 17:26:17 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j43LBfZC025127 for ; Tue, 3 May 2005 17:11:41 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 03 May 2005 17:11:41 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Tue, 03 May 2005 17:11:41 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 May 2005 17:11:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture Date: Tue, 3 May 2005 17:11:39 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032311@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] CALL FOR CONSENSUS: ISMS Architecture Thread-Index: AcVP94G8TlmUTsX9Q2CByDVIl4rD6AAKRN+gAADzqbA= From: "Nelson, David" To: X-OriginalArrivalTime: 03 May 2005 21:11:40.0889 (UTC) FILETIME=[B367B490:01C55024] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:79.5348 M:98.0659 P:95.9108 R:95.9108 S:90.7223 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Joe Salowey writes... =20 > It seems that in order for in-band key exchange to work you would need > to add data and extra processing to SNMP messages to perform the key > exchange. For example SBSM defines more new ASN.1 SEQUENCES than what > is defined for USM. In contrast an out-of-band approach like EUSM > defines none. The amount of implementation work for out-of-band vs. > in-band will be difficult to quantitatively measure for different code > bases. I do know that in our prototype we were able to leverage a lot > of existing code on agents, managers and AAA. I primarily want to avoid > inventing a new key exchange protocol and I think we should make as much > re-use of USM as possible. I would prefer not to burden SNMP > implementations with the added data and processing complexities of key > exchange that in-band requires. If it came down to creating another > security model different than USM then I would prefer to see an standard > encapsulation mechanism such as TLS. That seems to summarize my thinking as well. My preference poll results would therefore be: OBK - yes IBK - no EK - yes _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 03 17:25:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT4tn-0002uM-Ro; Tue, 03 May 2005 17:25:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT4tm-0002uH-2I for isms@megatron.ietf.org; Tue, 03 May 2005 17:25: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 RAA13457 for ; Tue, 3 May 2005 17:25:43 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT57i-0008V5-DO for isms@ietf.org; Tue, 03 May 2005 17:40:11 -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 j43LPSoF028275; Tue, 3 May 2005 14:25:28 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j43LPPUI016019; Tue, 3 May 2005 14:25:25 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j43LPP5f016014; Tue, 3 May 2005 14:25:25 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 3 May 2005 14:25:24 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Nelson, David" Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032311@MAANDMBX2.ets.enterasys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, Reminder... The goal of the charter is to reduce OPERATIONAL costs, not the coding costs. You guys are providing solutions to a different problem, and coming to a different choice. Please make an evaluation based on OPERATIONAL costs. Provide scenarios. Describe assumptions. However, please address the WG charter. On Tue, 3 May 2005, Nelson, David wrote: > Joe Salowey writes... > > > It seems that in order for in-band key exchange to work you would need > > to add data and extra processing to SNMP messages to perform the key > > exchange. For example SBSM defines more new ASN.1 SEQUENCES than what > > is defined for USM. In contrast an out-of-band approach like EUSM > > defines none. The amount of implementation work for out-of-band vs. > > in-band will be difficult to quantitatively measure for different code > > bases. I do know that in our prototype we were able to leverage a lot > > of existing code on agents, managers and AAA. I primarily want to > avoid > > inventing a new key exchange protocol and I think we should make as > much > > re-use of USM as possible. I would prefer not to burden SNMP > > implementations with the added data and processing complexities of key > > exchange that in-band requires. If it came down to creating another > > security model different than USM then I would prefer to see an > standard > > encapsulation mechanism such as TLS. > > That seems to summarize my thinking as well. > > My preference poll results would therefore be: > > OBK - yes > IBK - no > EK - yes > Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 03 17:37:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT55H-0007Gb-NZ; Tue, 03 May 2005 17:37:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT55G-0007GW-7A for isms@megatron.ietf.org; Tue, 03 May 2005 17:37: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 RAA14216 for ; Tue, 3 May 2005 17:37:35 -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 1DT5JC-0000NR-TI for isms@ietf.org; Tue, 03 May 2005 17:52:04 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 8C89211D944; Tue, 3 May 2005 14:37:29 -0700 (PDT) From: Wes Hardaker To: "Salowey, Joe" Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture Organization: Sparta References: <7210B31550AC934A8637D6619739CE69051E8C6F@e2k-sea-xch2.sea-alpha.cisco.com> Date: Tue, 03 May 2005 14:37:26 -0700 In-Reply-To: <7210B31550AC934A8637D6619739CE69051E8C6F@e2k-sea-xch2.sea-alpha.cisco.com> (Joe Salowey's message of "Tue, 3 May 2005 14:07:15 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Tue, 3 May 2005 14:07:15 -0700, "Salowey, Joe" said: Joe> It seems that in order for in-band key exchange to work you would Joe> need to add data and extra processing to SNMP messages to perform Joe> the key exchange. For example SBSM defines more new ASN.1 Joe> SEQUENCES than what is defined for USM. I agree that in-band would obviously require more extensions to exchange keys (hence the word "in" in "in-band"). However, you keep stating that USM needs to be modified which is not true. SNMPv3 will need to be extended through the extension fields that already exist in the protocol today (and thus it doesn't need to be modified, only extended...) USM wouldn't need to be touched at all. That's my only point and I'm tired of seeing it said that it would need to be modified, because it wouldn't need to be. Even SBSM as is, with a complete replacement for the message security during PDU transmission, doesn't modify USM at all. It does make use of SNMPv3 extension mechanisms though and I agree it requires new code in SNMPv3 stacks [3190 lines of code in my prototype SBSM implementation for example]. Now, EK could require 0 modification to existing SNMPv3 stacks. Joe> If it came down to creating another security model different than Joe> USM then I would prefer to see an standard encapsulation Joe> mechanism such as TLS. We haven't begun to argue about whether something different than USM is needed or not yet. I agree that simplicity would be provided by using an EK approach in order to achieve the needed security modifications to packet-processing. The downside is that it's less versatile and would likely require TCP to support some authentication services (eg, SSH). Others may support UDP but aren't deployed at all yet (DTLS) but that's likely not a big deal because neither is any in-band approach (aside from kerberized SNMP which is deployed and used [1886 lines of code incidentally]). -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 03 18:12:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT5c4-0001gt-Tl; Tue, 03 May 2005 18:11:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT5c3-0001f1-5m for isms@megatron.ietf.org; Tue, 03 May 2005 18:11: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 SAA17171 for ; Tue, 3 May 2005 18:11:28 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT5q0-0001C8-Vf for isms@ietf.org; Tue, 03 May 2005 18:25:57 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id RAA24880; Tue, 3 May 2005 17:11:16 -0500 (CDT) Received: from XCH-NWBH-02.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 j43MBGm19946; Tue, 3 May 2005 17:11:16 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 15:11:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 May 2005 15:10:56 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC27A@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture Thread-Index: AcVQGMbWN8a984ALR4eLClMSrX/WLgAC5/VQ From: "Fleischman, Eric" To: "Tom Petch" X-OriginalArrivalTime: 03 May 2005 22:11:04.0060 (UTC) FILETIME=[FF3873C0:01C5502C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org Subject: [Isms] RE: Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture 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 >From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 >Historically I have associated it [Kerberos] with Unix platforms=20 >but since Microsoft has made it part of Windows 200x=20 >Server, I expect it will become much more widely known=20 >and deployed. So although Wes' survey showed only 10%=20 >(from memory) interest, I expect that to grow. My memory is that Wes' survey occurred at a meeting that was primarily populated by Internet Service Providers (ISP). Having "hung out" with ISPs at the IETF for over a decade, I've concluded that the ISPs' environments are very different from our (very large end users) environments. For example, in our environments more than 90% of the devices use a Microsoft operating system that natively supports Kerberos by default. [Note: this is a statistic -- not a value judgement. Please exclude me from Unix-vs-Microsoft or end-system-vs-intermediate-system flames.] Also, large end users have historic issues with supporting authentication systems (e.g., for users and applications) due to our staggeringly huge scale (literally multiple hundreds of thousands of entities). Because of this, large corporations have also aggressively pursued (and deploy) PKI-based systems. Thus, while I respect Wes' numbers, I assert that if this WG is interested in supporting the large end user, then it will support both Kerberos and PKI, and hopefully client-server policy systems (e.g., AAA, COPS server, Radius, Diameter) as well. >But it does require, like any three party system, reliable=20 >and rapid communications at session setup time, which is=20 >fine when the agent is an enterprise server, may not be=20 >for the workgroup switch or access router. =20 Tom, you are bringing up very important issues. To me, this particular issue is the "age old" delemma of "whether the system should naturally support the needs of 97% of its population or whether the needs of the 3% should determine the total system approach." It is value judgement of which population this community should favor -- assuming that router management is indeed less capable than PCs (are you sure about that?? -- it certainly doesn't seem that way from my knot hole). I will state, however, that to satisfy my type of community, the solution needs to support both Kerberos and PKI.=20 >Rather than a triangle, our communications may be a fast=20 >reliable pipe from security server to SNMP manager-server=20 >but not from manager to agent and even less so from agent=20 >back to security server. =20 I don't mean to be cruel, but your example seems to assume a wired environment. As you know, our ISMS solution will ultimately need to support a very wide range of possible deployments, including unreliable wireless environments (possibly including MANET). Because our design needs to address the needs of so many diverse types of users, it is important that our solution support several different authentication infrastructures including enterprise authentication mechanisms (Kerberos, PKI) and client-server authentication mechanisms such as policy servers. >PKI? limited experience on a Windows platform and=20 >there seemed to be quite a bit of administration=20 >(eg revocation lists) which are fine on a central server,=20 >less so on a distant network box. This is our (i.e., the administrator's of end user networks) problem, not the ISMS' WG's problem. I recommend that the ISMS WG design a flexible authentication system that is able to use a wide variety of authentication infrastructures. I recommend that all ISMS systems must support one of these alternatives (i.e., one supportable by 100% of the devices). Therefore, if a vendor is unable to support all of the ISMS-supported alternatives for a particular device, then that device could be supported by whatever the vendor can (or chooses to) support, including the minimalist (universal) alternative. However, the end user is also empowered to determine which primary authentication system to use in their own deployment based on their own goals, requirements, and environment -- including building special purpose management sub-systems for the capability-limited systems, if indeed they are important enough to that deployment to justify that type of expense. Please note that I explicitly believe that there are a large number of possible end user requirements and environments and that SNMPv3 USM doesn't work well in many of them today because of its lack of flexibility. This lack of flexibility is what I believe the ISMS WG is trying to fix. Therefore, our goal should be to increase the authentication flexibility, not continue to maintain a limiting lack of flexibility. This, anyway, is the view from my knot hole. --Eric _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 03 19:30:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT6qc-0003IB-7j; Tue, 03 May 2005 19:30:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT6qb-0003GL-As for isms@megatron.ietf.org; Tue, 03 May 2005 19:30:37 -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 TAA22988 for ; Tue, 3 May 2005 19:30: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 1DT74Z-0002uk-0v for isms@ietf.org; Tue, 03 May 2005 19:45:04 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 03 May 2005 16:30:24 -0700 X-IronPort-AV: i="3.92,152,1112598000"; d="scan'208"; a="257903844:sNHT27270142" Received: from kaushik-w2k03.cisco.com ([171.69.75.179]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j43NUKhv019483; Tue, 3 May 2005 16:30:21 -0700 (PDT) Message-Id: <6.2.0.14.0.20050503153238.03d8f988@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 03 May 2005 16:30:14 -0700 To: Wes Hardaker , "Randy Presuhn" From: Kaushik Narayan Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture In-Reply-To: References: <474EEBD229DF754FB83D256004D021080EC276@XCH-NW-6V1.nw.nos.boeing.com> <6.2.0.14.0.20050503102434.04f02a60@email.cisco.com> <005201c55013$282bffa0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [171.69.75.179] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Randy, The use of SNMPv3 to acquire keys generated from OOB key exchange is something we have been discussing. This does bring up the issue of requiring to setup a USM "superuser" that can be used for the key acquisition. This however should not be a significant issue since we this a local subsystem, setting up and coordinating a local "superuser" can be done with minimal work. regards, kaushik! At 01:35 PM 5/3/2005, Wes Hardaker wrote: > >>>>> On Tue, 3 May 2005 12:05:22 -0700, "Randy Presuhn" > said: > >Randy> However, any SNMP stack out there that supports USM should >Randy> provide the ability to use SNMPv3 to set the keys. Rather than >Randy> modifying the SNMP stack, or modifying the existing "OOB >Randy> service", one could use an application acting on behalf of the >Randy> security administrator to talk to the OOB service, and use >Randy> SNMPv3 to set the USM keys. > >The thought had crossed my mind as well, but that still requires >either provisioning of the SNMPv3 service with an initial USM user >(bad IMHO) or requires the service to be run on the same host and a >noAuthNoPriv user with access privileges tied to the loopback address >(or any other form of an internal-to-the-box-trusted-network) which >probably doesn't exist in most implementations today. > >Requiring the setup of just one USM user instead of X is still bad, >IMHO, because operators don't want to do this today either. > >-- >Wes Hardaker >Sparta, Inc. > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 03 22:23:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT9YJ-0006p5-Su; Tue, 03 May 2005 22:23:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT9YH-0006p0-VH for isms@megatron.ietf.org; Tue, 03 May 2005 22:23:54 -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 WAA04234 for ; Tue, 3 May 2005 22:23:44 -0400 (EDT) Message-Id: <200505040223.WAA04234@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT9mB-0006dk-51 for isms@ietf.org; Tue, 03 May 2005 22:38:15 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <20050504022310015004lhj4e>; Wed, 4 May 2005 02:23:10 +0000 From: "David B Harrington" To: "'Fleischman, Eric'" , "'Tom Petch'" Subject: RE: [Isms] RE: Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture Date: Tue, 3 May 2005 22:23:03 -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: AcVQGMbWN8a984ALR4eLClMSrX/WLgAC5/VQAAonrbA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <474EEBD229DF754FB83D256004D021080EC27A@XCH-NW-6V1.nw.nos.boeing.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Comments inline > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Fleischman, Eric > Sent: Tuesday, May 03, 2005 6:11 PM > To: Tom Petch > Cc: isms@ietf.org > Subject: [Isms] RE: Kerberos and PKI; was What is Out Of Band > Keying;was CALL FOR CONSENSUS: ISMS Architecture > > > This is our (i.e., the administrator's of end user networks) problem, > not the ISMS' WG's problem. I recommend that the ISMS WG design a > flexible authentication system that is able to use a wide variety of > authentication infrastructures. The SNMPv3 architecture was designed to provide that flexibility; it allows multiple alternative security models to co-exist. We deliberately made SNMPv3 modular and able to support multiple security models because it was recognized that trying to design one security model to meet all needs is not likely to be feasible, and trying to do so would probably result in never completing the work. SNMPv3 is designed to allow multiple models to co-exist to meet different needs. Operators can of course choose which to utilize for their environments. > I recommend that all ISMS systems must > support one of these alternatives (i.e., one supportable by > 100% of the > devices). USM is the one security model required for compliance to the SNMPv3 standard for purposes of interoperability. I am not convinced that making compliance dependent on the presence of another security infrastructure is a good idea, especially since it is obvious none of the suggested infrastructures meets everybody's needs. I hope ISMS does not try to satisfy all the people all of the time with one security model, or even one security model architecture. The constraint that we must choose one architecture, or one proposal, to pursue is all about what this WG is chartered to do. That does not mean SNMPv3 should be constrained to have one security model to meet all needs. I personally would be satisfied to see all three architecural models under discussion, or all three proposals, implemented and made available for deployment to supplement the USM security model. If in practice one of the new deployed security models can be shown to meet everybody's (minimalist) needs, then we could make that the rerquired-for-interoperability model to replace USM, but I don't think we should be planning to eliminate USM until another security model is proven in the field to be more adequate (at least we have a low bar). > Therefore, if a vendor is unable to support all of the > ISMS-supported alternatives for a particular device, then that device > could be supported by whatever the vendor can (or chooses to) support, > including the minimalist (universal) alternative. However, > the end user > is also empowered to determine which primary authentication system to > use in their own deployment based on their own goals, > requirements, and > environment -- including building special purpose management > sub-systems > for the capability-limited systems, if indeed they are > important enough > to that deployment to justify that type of expense. > > Please note that I explicitly believe that there are a large number of > possible end user requirements and environments and that SNMPv3 USM > doesn't work well in many of them today because of its lack of > flexibility. This lack of flexibility is what I believe the ISMS WG is > trying to fix. Therefore, our goal should be to increase the > authentication flexibility, not continue to maintain a > limiting lack of > flexibility. This, anyway, is the view from my knot hole. > > --Eric > 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 May 03 22:26:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT9ao-0007NL-GO; Tue, 03 May 2005 22:26:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT9ak-0007Hy-Ll for isms@megatron.ietf.org; Tue, 03 May 2005 22:26:29 -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 WAA04518 for ; Tue, 3 May 2005 22:26:24 -0400 (EDT) Message-Id: <200505040226.WAA04518@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT9ok-0006i4-V6 for isms@ietf.org; Tue, 03 May 2005 22:40:55 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005050402261601400kndgge>; Wed, 4 May 2005 02:26:17 +0000 From: "David B Harrington" To: "'Kaushik Narayan'" , "'Wes Hardaker'" , "'Randy Presuhn'" Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture Date: Tue, 3 May 2005 22:26:10 -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: AcVQOodoWu/bmVRQSYO+MiMkgqKFKgAFc8Og X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <6.2.0.14.0.20050503153238.03d8f988@email.cisco.com> 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: 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 Can you repost your message with the last sentence rewritten? I couldn't understand what you said fully. Could you also justify your conclusion that "coordinating a local 'superuser' can be done with minimal work"? Thanks, David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Kaushik Narayan > Sent: Tuesday, May 03, 2005 7:30 PM > To: Wes Hardaker; Randy Presuhn > Cc: isms@ietf.org > Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture > > Hi Randy, > > The use of SNMPv3 to acquire keys generated from OOB key > exchange is something we have been discussing. This does > bring up the issue of requiring to setup a USM "superuser" that > can be used for the key acquisition. This however should not be > a significant issue since we this a local subsystem, setting up and > coordinating a local "superuser" can be done with minimal work. > > regards, > kaushik! > > > At 01:35 PM 5/3/2005, Wes Hardaker wrote: > > >>>>> On Tue, 3 May 2005 12:05:22 -0700, "Randy Presuhn" > > said: > > > >Randy> However, any SNMP stack out there that supports USM should > >Randy> provide the ability to use SNMPv3 to set the keys. > Rather than > >Randy> modifying the SNMP stack, or modifying the existing "OOB > >Randy> service", one could use an application acting on behalf of the > >Randy> security administrator to talk to the OOB service, and use > >Randy> SNMPv3 to set the USM keys. > > > >The thought had crossed my mind as well, but that still requires > >either provisioning of the SNMPv3 service with an initial USM user > >(bad IMHO) or requires the service to be run on the same host and a > >noAuthNoPriv user with access privileges tied to the loopback address > >(or any other form of an internal-to-the-box-trusted-network) which > >probably doesn't exist in most implementations today. > > > >Requiring the setup of just one USM user instead of X is still bad, > >IMHO, because operators don't want to do this today either. > > > >-- > >Wes Hardaker > >Sparta, Inc. > > > >_______________________________________________ > >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 Wed May 04 02:03:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTCz1-0004gd-1L; Wed, 04 May 2005 02:03:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTCyx-0004bS-6q for isms@megatron.ietf.org; Wed, 04 May 2005 02:03:39 -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 CAA23028 for ; Wed, 4 May 2005 02:03:37 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTDCy-000330-Ie for isms@ietf.org; Wed, 04 May 2005 02:18:08 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 03 May 2005 23:03:29 -0700 Received: from kaushik-w2k03.cisco.com (sjc-vpn5-83.cisco.com [10.21.88.83]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j4463Pb5014361; Tue, 3 May 2005 23:03:26 -0700 (PDT) Message-Id: <6.2.0.14.0.20050503222905.048cb6c8@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 03 May 2005 23:03:19 -0700 To: From: Kaushik Narayan Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture In-Reply-To: <40qjma$242hn5@sj-inbound-e.cisco.com> References: <6.2.0.14.0.20050503153238.03d8f988@email.cisco.com> <40qjma$242hn5@sj-inbound-e.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, Here is my previous message "The use of SNMPv3 to acquire keys generated from OOB key exchange is something we have been discussing. This does bring up the issue of requiring to setup a USM "superuser" that can be used for the key acquisition. This however should not be a significant issue since with a local subsystem, setting up a local "superuser" can be done with minimal work." I was trying to indicate that if indeed SNMPv3 is used as the API for the keys between the keying subsystem and USM then it wouldn't be too difficult to setup a local USM "superuser" that can be used for this purpose. There is actually no co-ordination required. regards, kaushik! At 07:26 PM 5/3/2005, David B Harrington wrote: >Can you repost your message with the last sentence rewritten? I >couldn't understand what you said fully. > >Could you also justify your conclusion that "coordinating a local >'superuser' can be done with minimal work"? > >Thanks, >David Harrington >dbharrington@comcast.net > > > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Kaushik Narayan > > Sent: Tuesday, May 03, 2005 7:30 PM > > To: Wes Hardaker; Randy Presuhn > > Cc: isms@ietf.org > > Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture > > > > Hi Randy, > > > > The use of SNMPv3 to acquire keys generated from OOB key > > exchange is something we have been discussing. This does > > bring up the issue of requiring to setup a USM "superuser" that > > can be used for the key acquisition. This however should not be > > a significant issue since we this a local subsystem, setting up and > > coordinating a local "superuser" can be done with minimal work. > > > > regards, > > kaushik! > > > > > > At 01:35 PM 5/3/2005, Wes Hardaker wrote: > > > >>>>> On Tue, 3 May 2005 12:05:22 -0700, "Randy Presuhn" > > > said: > > > > > >Randy> However, any SNMP stack out there that supports USM should > > >Randy> provide the ability to use SNMPv3 to set the keys. > > Rather than > > >Randy> modifying the SNMP stack, or modifying the existing "OOB > > >Randy> service", one could use an application acting on behalf of >the > > >Randy> security administrator to talk to the OOB service, and use > > >Randy> SNMPv3 to set the USM keys. > > > > > >The thought had crossed my mind as well, but that still requires > > >either provisioning of the SNMPv3 service with an initial USM user > > >(bad IMHO) or requires the service to be run on the same host and a > > >noAuthNoPriv user with access privileges tied to the loopback >address > > >(or any other form of an internal-to-the-box-trusted-network) which > > >probably doesn't exist in most implementations today. > > > > > >Requiring the setup of just one USM user instead of X is still bad, > > >IMHO, because operators don't want to do this today either. > > > > > >-- > > >Wes Hardaker > > >Sparta, Inc. > > > > > >_______________________________________________ > > >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 Wed May 04 09:09:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTJcy-0006dh-Ld; Wed, 04 May 2005 09:09:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTJcx-0006dG-7c for isms@megatron.ietf.org; Wed, 04 May 2005 09:09:23 -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 JAA03995 for ; Wed, 4 May 2005 09:09:21 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTJr1-0005d0-2C for isms@ietf.org; Wed, 04 May 2005 09:23:57 -0400 Received: from pc6 (1Cust234.tnt106.lnd4.gbr.da.uu.net [213.116.60.234]) by galaxy.systems.pipex.net (Postfix) with SMTP id DCDD9E000262 for ; Wed, 4 May 2005 14:09:04 +0100 (BST) Message-ID: <009a01c550a1$86ed9100$0601a8c0@pc6> From: "Tom Petch" To: References: <001e01c54f70$c5a232c0$7f1afea9@oemcomputer> Subject: Re: [Isms] RE: TLA Date: Wed, 4 May 2005 14:00:09 +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: d185fa790257f526fedfd5d01ed9c976 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 Thanks for all the information on PFS; I wish I had asked when it first arose:-( I have had in mind the RFC2828 definition which includes '(C) Some existing RFCs use the term "perfect forward secrecy" but either do not define it or do not define it precisely. While preparing this Glossary, we tried to find a good definition for that term, but found this to be a muddled area. Experts did not agree. For all practical purposes, the literature defines "perfect forward secrecy" by stating the Diffie-Hellman algorithm.' which I think covers the bases:-) Tom Petch ----- Original Message ----- From: "Randy Presuhn" To: Sent: Tuesday, May 03, 2005 1:43 AM Subject: Re: [Isms] RE: TLA > Hi - > > > From: "Khanh Nguyen (khanhvn)" > > To: "Randy Presuhn" ; > > Sent: Monday, May 02, 2005 4:05 PM > > Subject: RE: [Isms] RE: TLA > ... > > Of course. But the difference is USM keys are re-used repeatedly > > for encryption, while in TLS, for example, the master keys are > > generated dynamically using Diffie-Hellman or RSA key exchange. > > One the session is over, TLS master keys are destroyed - no > > trace left. But in USM, the keys stay in the device > > indefinitely (until someone changes them manually). That's > > why attackers can look back to decrypt past communications. > > > > Again, as I said, this is not USM fault, but a common problem > > for all sessionless methods. > > Let's not confuse PFS with the desire to limit key lifetimes. > One can limit key lifetimes without providing PFS, and one > can have PFS without limiting key lifetimes. > Both are valuable, but they're not the same thing. > > ... > > My point is that USM keys are very > > static. They can be changed manually once in a while, but are > > not dynamically generated as in other session-based methods. > > USM does not limit the frequency of key updates. That's up to the > user/SA. The remaining question is that of limiting key lifetime, > which can be accomplished by far less drastic means than these. > > For example, an automated security administrator could delete > "old" usm user entries. When a user app needed to interact with a > managed system, it could ask the security administrator application > to (re-)create its entry, possibly using 2786 to establish the key(s), > and possibly consulting with some AAA infrastructure. > What would require some thought/discussion is the question of > how the end of a session is detected. For example, users could > be permitted to delete their own usm user entries, or the security > administrator application could do it on their behalf. > > > USM auth/privKeys are generated from the user passwords, and > > people don't change their passwords every hour. > ... > > Passphrases, but I agree with this point inasmuch as it applies to > authentication keys. Encryption keys are a different matter, particularly > in light of how one might use RFC 2786. > > Randy > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 09:37:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTK4D-0007vd-Ll; Wed, 04 May 2005 09:37:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTK4C-0007vT-V3 for isms@megatron.ietf.org; Wed, 04 May 2005 09:37:33 -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 JAA07498 for ; Wed, 4 May 2005 09:37:31 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTKIH-0006gO-Ul for isms@ietf.org; Wed, 04 May 2005 09:52:07 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j44DbUZC020033 for ; Wed, 4 May 2005 09:37:30 -0400 (EDT) Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 04 May 2005 09:37:30 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 04 May 2005 09:37:30 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 May 2005 09:37:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture Date: Wed, 4 May 2005 09:37:28 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032312@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] CALL FOR CONSENSUS: ISMS Architecture Thread-Index: AcVQJqN83oufqIzeT8mGLY9276q2QgAhhlIg From: "Nelson, David" To: "David T. Perkins" X-OriginalArrivalTime: 04 May 2005 13:37:29.0827 (UTC) FILETIME=[6AEB6330:01C550AE] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:82.4442 M:98.0684 P:95.9108 R:95.9108 S:79.5015 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 David Perkins writes... > Reminder... The goal of the charter is to reduce OPERATIONAL > costs, not the coding costs. Actually, I thought the goal was to introduce a method for providing SNMPv3 authentication and privacy that somehow re-used existing authentication services that operator's have already deployed. If the work product of ISMS can directly use the existing authentication services, I think we have met that goal. The re-use of existing infrastructure minimizes operating costs. The costs here are those of deploying and maintaining multiple sets of authentication information, when only one is required. Some folks may desire the ability to use SNMPv3 authentication and privacy without having *any* authentication infrastructure. This seems unlikely to have a realistic and robust solution. Anonymous privacy is certainly possible, but authentication without some database of credentials seems to be a non sequitur. =20 There will be some capital costs of any solution. Operators are going to have to upgrade at least some of the FW and SW they currently use to newer versions that incorporate ISMS features. I see no way around that. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 10:09:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTKZO-0000bQ-OD; Wed, 04 May 2005 10:09:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTKZN-0000bL-8c for isms@megatron.ietf.org; Wed, 04 May 2005 10:09:45 -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 KAA11770 for ; Wed, 4 May 2005 10:09:43 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTKnS-0007fd-Hb for isms@ietf.org; Wed, 04 May 2005 10:24:19 -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 j44E9bXS026620 for ; Wed, 4 May 2005 10:09:38 -0400 (EDT) Message-Id: <200505041409.j44E9bXS026620@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture In-Reply-To: <014f01c5500f$d60f8500$0601a8c0@pc6> 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: Wed, 04 May 2005 10:09:39 -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: 9182cfff02fae4f1b6e9349e01d62f32 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 >Historically I have associated it with Unix platforms but since Microsoft has >made it part of Windows 200x Server, I expect it will become much more widely >known and deployed. So although Wes' survey showed only 10% (from memory) >interest, I expect that to grow. > >But it does require, like any three party system, reliable and rapid >communications at session setup time, which is fine when the agent is an >enterprise server, may not be for the workgroup switch or access router. Rather >than a triangle, our communications may be a fast reliable pipe from security >server to SNMP manager-server but not from manager to agent and even less so >from agent back to security server. SNMPv1 seemed to cater for an really >unreliable network (as opposed to one that was only nominally unreliable) and >that also colours my thinking about how sophisticated session setup should be >for SNMP. As ever, I want a scalable solution. A correction here. Kerberos requires communication _only_ between the manager and the Kerberos server. It requires _zero_ communication between the agent and the Kerberos server (I'm assuming here we're using Kerberos in a "traditional" role, and not anything unusual like having both sides do U2U). The communication isn't even that frequent; you can cache the necessary information on the manager side, so you only need to talk to the Kerberos server once per agent per ticket lifetime. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 10:42:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTL4k-0002Rq-To; Wed, 04 May 2005 10:42:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTL4j-0002Rk-Cc for isms@megatron.ietf.org; Wed, 04 May 2005 10:42:09 -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 KAA16390 for ; Wed, 4 May 2005 10:42:06 -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 1DTLIo-0000In-Uk for isms@ietf.org; Wed, 04 May 2005 10:56:44 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 6C95611D939; Wed, 4 May 2005 07:42:03 -0700 (PDT) From: Wes Hardaker To: Ken Hornstein Subject: Re: [Isms] Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture Organization: Sparta References: <200505041409.j44E9bXS026620@ginger.cmf.nrl.navy.mil> Date: Wed, 04 May 2005 07:41:58 -0700 In-Reply-To: <200505041409.j44E9bXS026620@ginger.cmf.nrl.navy.mil> (Ken Hornstein's message of "Wed, 04 May 2005 10:09:39 -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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Wed, 04 May 2005 10:09:39 -0400, Ken Hornstein said: Ken> It requires _zero_ communication between the agent and the Ken> Kerberos server (I'm assuming here we're using Kerberos in a Ken> "traditional" role, and not anything unusual like having both Ken> sides do U2U). (aside from the initial setup where a shared key between the KDC and the agent gets distributed) -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 11:00:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLMh-000762-I7; Wed, 04 May 2005 11:00:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLMg-00075x-4k for isms@megatron.ietf.org; Wed, 04 May 2005 11:00:42 -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 LAA18242 for ; Wed, 4 May 2005 11:00:39 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTLam-0000n5-1Q for isms@ietf.org; Wed, 04 May 2005 11:15:17 -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 j44F0S2U027564 for ; Wed, 4 May 2005 11:00:28 -0400 (EDT) Message-Id: <200505041500.j44F0S2U027564@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture In-Reply-To: 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: Wed, 04 May 2005 11:00:30 -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: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >Ken> It requires _zero_ communication between the agent and the >Ken> Kerberos server (I'm assuming here we're using Kerberos in a >Ken> "traditional" role, and not anything unusual like having both >Ken> sides do U2U). > >(aside from the initial setup where a shared key between the KDC and >the agent gets distributed) Of couse; I was talking about the protocol exchange. Sadly, nothing is free. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 11:46:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTM54-0004V8-4G; Wed, 04 May 2005 11:46:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTM51-0004Uj-S8 for isms@megatron.ietf.org; Wed, 04 May 2005 11:46: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 LAA22858 for ; Wed, 4 May 2005 11:46:29 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTMJ7-0002Dk-C8 for isms@ietf.org; Wed, 04 May 2005 12:01:07 -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 IAA17821; Wed, 4 May 2005 08:46:16 -0700 (PDT) Received: from XCH-NWBH-02.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 j44FkGm18522; Wed, 4 May 2005 10:46:16 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 08:46:14 -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] RE: Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture Date: Wed, 4 May 2005 08:45:14 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC27E@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] RE: Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture Thread-Index: AcVQGMbWN8a984ALR4eLClMSrX/WLgAC5/VQAAonrbAAHJ8ioA== From: "Fleischman, Eric" To: , "Tom Petch" X-OriginalArrivalTime: 04 May 2005 15:46:14.0712 (UTC) FILETIME=[674F4B80:01C550C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 >From: David B Harrington [mailto:ietfdbh@comcast.net]=20 >I hope ISMS does not try to satisfy all the people all of the time with >one security model, or even one security model architecture. The constraint=20 >that we must choose one architecture, or one proposal, to pursue is all >about what this WG is chartered to do. That does not mean SNMPv3 should >be constrained to have one security model to meet all needs. I personally=20 >would be satisfied to see all three architecural models under discussion,=20 >or all three proposals, implemented and made available for deployment to=20 >supplement the USM security model. If in practice one of the new deployed=20 >security models can be shown to meet everybody's (minimalist) needs, then=20 >we could make that the rerquired-for-interoperability model to replace USM,=20 >but I don't think we should be planning to eliminate USM until another=20 >security model is proven in the field to be more adequate (at least we have=20 >a low bar). I fully agree. I do not view ISMS replacing or eliminating SNMPv1, SNMPv2, or SNMPv3 USM. Rather, I see ISMS supplementing these existing approaches by offering (1) a "more secure alternative" but, more importantly and centrally: (2) an alternative that leverages existing authentication infrastructures that include Kerberos, PKI, and policy servers (e.g., COPS Servers, Radius, Diameter, etc.). _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 11:49:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTM7e-000522-T9; Wed, 04 May 2005 11:49:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTM7e-00051x-5T for isms@megatron.ietf.org; Wed, 04 May 2005 11:49:14 -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 LAA23151 for ; Wed, 4 May 2005 11:49:11 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTMLj-0002K1-Bv for isms@ietf.org; Wed, 04 May 2005 12:03:49 -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 j44FmroF020875; Wed, 4 May 2005 08:48:54 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j44Fmpsf031281; Wed, 4 May 2005 08:48:51 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j44FmpiZ031278; Wed, 4 May 2005 08:48:51 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 4 May 2005 08:48:51 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Nelson, David" Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032312@MAANDMBX2.ets.enterasys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, On the following... On Wed, 4 May 2005, Nelson, David wrote: > David Perkins writes... > > > Reminder... The goal of the charter is to reduce OPERATIONAL > > costs, not the coding costs. > > Actually, I thought the goal was to introduce a method for providing > SNMPv3 authentication and privacy that somehow re-used existing > authentication services that operator's have already deployed. Yes, this by reusing existing authentication services, operational costs is reduced. > If the work product of ISMS can directly use the existing authentication > services, I think we have met that goal. The re-use of existing > infrastructure minimizes operating costs. The costs here are those of > deploying and maintaining multiple sets of authentication information, > when only one is required. Absolutely! I don't follow how the message below has anything to do with reducing operational costs. Only time will tell what the cap-ex will be with a new SNMP security model. More than likely, it will be "nothing" to the network equipment users. For SNMP technology suppliers and network equipment suppliers, I believe that dropping USM and only providing ISMS will cost less over the long run (1 to 2 years). Over the last 5 months, I've added support for SNMPv3/USM to a device, and it would have taken me about 1 month (or less) if I had to provide SNMPv3/ISMS. No kidding. There were CLI commands and pages (many) in the manuals that WOULD NOT have been needed if SNMPv3/ISMS existed. The "break through way of thinking" is that another security system ALREADY exists, and if SNMPv3/ISMS just uses it (unmodified), then the incremental cost is very low for coding and delivering SNMPv3/ISMS. And also, for users, the incremental cost for deploying and using SNMPv3/ISMS is very low compared to SNMPv3/USM. > Some folks may desire the ability to use SNMPv3 authentication and > privacy without having *any* authentication infrastructure. This seems > unlikely to have a realistic and robust solution. Anonymous privacy is > certainly possible, but authentication without some database of > credentials seems to be a non sequitur. > > There will be some capital costs of any solution. Operators are going > to have to upgrade at least some of the FW and SW they currently use to > newer versions that incorporate ISMS features. I see no way around > that. It's a shame that some vendors (including the ones that I have provided support for SNMPv3) have gone through the costs of bulking out the CLI and tech pubs. It's a real shame. (It was a shame that vendors many years ago put in OSI protocols and support for CMIP, only to rip them out (or let them die) when there wasn't enough market demand. However, complaining that the development work has already been done is not going to change the market.) Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 12:22:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMdW-0000Ga-5q; Wed, 04 May 2005 12:22:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMdU-0000GL-Kj for isms@megatron.ietf.org; Wed, 04 May 2005 12:22:08 -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 MAA26130 for ; Wed, 4 May 2005 12:22:05 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTMra-0003H6-95 for isms@ietf.org; Wed, 04 May 2005 12:36:44 -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 j44GLisV029505 for ; Wed, 4 May 2005 12:21:52 -0400 (EDT) Message-Id: <200505041621.j44GLisV029505@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: Wed, 04 May 2005 12:21:46 -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: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Subject: [Isms] Rough Consensus Declaration: ISMS Architecture is EK 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 Dear ISMS WG members, As you all know, there has been a lot of discussion relating to different security architectures. Juergen and I have talked it over, and we both have agreed that there is a _very_ rough consensus for EK as the security architecture for the ISMS WG. Unfortunately, we know this decision will not be popular with a number of WG members. The exact preferences from people who expressed their opinions on the mailing list is as follows (we've included Michael Bear and David Nelson, who sent in their preferences a little bit late): Keying| For | Against | Abstain ------+----------------------+---------+------------- OOB | 13 (9 Yes, 4 Maybes) | 6 No | 3 no comment IB | 12 (9 Yes, 3 Maybe) | 5 No | 5 no comment EK | 14 (7 Yes, 7 Maybe) | 4 No | 3 no comment Key: Y=YES/preference (y=second pref/implied pref) M=MAYBE/second pref (m=implied second pref) N=NO -=no explicit rejection (no comment) OOB | IB | EK | Name (alphabetical by first name) ----+-----+-----+---------------------------------- M | M | Y | David Harrington - | Y | - | David Perkins N | Y | M | Ira McDonald M | - | Y | Juergen Schoenwaelder Y | M | N | Kaushik Narayan Y | - | - | Marcus Leech Y | - | M | Martin Soukup N | Y | M | Robert Story N | y | y | Sam Hartman N | Y | M | Ken Hornstein Y | - | m | Sharon Chisolm Y | - | - | Tom Petch - | Y | Y | Uri Blumenthal N | Y | M | Wes Hardaker - | N | Y | Juergen Quittek m | M | Y | Wayne Kading m | Y | m | Eric Fleischman Y | N | N | Martin Soukup Y | N | N | Keith McCloghrie Y | N | N | Joe Salowey N | Y | M | Michael Baer Y | N | Y | David Nelson Just from looking at the raw numbers, it's a very close call. But from the tone of the discussions, I think that a reasonable majority of the WG can accept EK as the security architecture. We don't expect this decision to satisfy everyone, but sadly I doubt that we will be able to come any closer to a consensus given the way the discussions are going. We believe at this point, we're left with two choices: declare a rough consensus for EK, or decide that the WG has not reached consensus and shut down. We hope everyone can live with this decision and move onto the important work of actually specifying the ISMS protocol. Speaking not as a WG chair, but as a WG participant, I think that the best model for security lies with IBK. I understand the evaluation team's issues with SBSM, but I believe that it would be possible to incorporate an existing IETF protocol as the key exchange protocol instead of SBSM. I understood what the authors of EUSM were trying to do, but since the applicability statements for EAP and IKE placed them off-limits for things like EUSM, I'm not sure what exactly was _left_ for a key exchange protocol, which puts us back in the same spot as SBSM. I'm not a huge fan of the EK approach, but it _is_ well understood and is used by a number of protocols successfully. I am confident that a reasonable protocol can be designed using it and it should be able to meet nearly everyone's needs. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 12:33:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMo0-0003ye-Cx; Wed, 04 May 2005 12:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMnz-0003yU-37 for isms@megatron.ietf.org; Wed, 04 May 2005 12:32:59 -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 MAA26981 for ; Wed, 4 May 2005 12:32:56 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTN25-0003XN-OW for isms@ietf.org; Wed, 04 May 2005 12:47:35 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j44GWLdv009789; Wed, 4 May 2005 09:32:21 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j44GWHIU008853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 May 2005 09:32:18 -0700 (PDT) Message-ID: <4278F911.7080501@qualcomm.com> Date: Wed, 04 May 2005 12:32:17 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: kenh@cmf.nrl.navy.mil Subject: [Fwd: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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, I failed to CC (unintentional) the list last time, so I presume your filters threw it away. But, here is my preference, from below: OOBK, and EK (in the order of preference). But, I think the EK RC still holds. regards, Lakshminath -------- Original Message -------- Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture Date: Thu, 28 Apr 2005 10:36:11 -0400 From: Lakshminath Dondeti Reply-To: ldondeti@qualcomm.com Organization: Qualcomm To: Ken Hornstein References: <200504212017.j3LKHUQO028810@ginger.cmf.nrl.navy.mil> OOBK EK thanks, Lakshminath >- Out of band keying (the architecture used by EUSM) >- In-bakd keying (the architecture used by SBSM) >- Encapsulation keying (the architecture used by TLSM) > > >_______________________________________________ >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 Wed May 04 12:38:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMtL-0006E3-ED; Wed, 04 May 2005 12:38:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMtJ-00069i-KT for isms@megatron.ietf.org; Wed, 04 May 2005 12:38:29 -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 MAA27418 for ; Wed, 4 May 2005 12:38:26 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTN7R-0003gU-FP for isms@ietf.org; Wed, 04 May 2005 12:53:05 -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 j44GcGAK029930 for ; Wed, 4 May 2005 12:38:17 -0400 (EDT) Message-Id: <200505041638.j44GcGAK029930@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Fwd: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture] In-Reply-To: <4278F911.7080501@qualcomm.com> 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: Wed, 04 May 2005 12:38:18 -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: 30ac594df0e66ffa5a93eb4c48bcb014 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 >I failed to CC (unintentional) the list last time, so I presume your >filters threw it away. But, here is my preference, from below: OOBK, >and EK (in the order of preference). My apologies; Juergen was the one who totaled it up, and I guess that I simply forgot about your email. If anyone else is not on the list, please speak up. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 13:34:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTNlh-0006Ya-C5; Wed, 04 May 2005 13:34:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTNlg-0006YR-BJ for isms@megatron.ietf.org; Wed, 04 May 2005 13:34:40 -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 NAA04038 for ; Wed, 4 May 2005 13:34:37 -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 1DTNzn-0005Ua-FO for isms@ietf.org; Wed, 04 May 2005 13:49:16 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 04 May 2005 10:22:54 -0700 X-IronPort-AV: i="3.92,154,1112598000"; d="scan'208"; a="258808453:sNHT1393973532" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j44HMHLL003929; Wed, 4 May 2005 10:22:45 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 10:22:48 -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: [Fwd: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture] Date: Wed, 4 May 2005 10:22:48 -0700 Message-ID: Thread-Topic: [Fwd: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture] Thread-Index: AcVQx+11sE4Yos6hRt6unbmzMD/hDQABUpsA From: "Khanh Nguyen \(khanhvn\)" To: "Ken Hornstein" , X-OriginalArrivalTime: 04 May 2005 17:22:49.0042 (UTC) FILETIME=[E4FFE320:01C550CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 > -----Original Message----- > From: Ken Hornstein >=20 > If anyone else is not on the list, please speak up. I earlier expressed preference for EK/IBK, but I guess it won't affect the result.=20 Khanh >=20 > --Ken >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 14:07:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOH5-0002hr-Sj; Wed, 04 May 2005 14:07:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOH4-0002hm-6v for isms@megatron.ietf.org; Wed, 04 May 2005 14:07:06 -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 OAA08779 for ; Wed, 4 May 2005 14:07:04 -0400 (EDT) Received: from adsl-64-165-72-150.dsl.scrm01.pacbell.net ([64.165.72.150] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTOVB-0006vt-Na for isms@ietf.org; Wed, 04 May 2005 14:21:43 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 450A511D939; Wed, 4 May 2005 11:07:01 -0700 (PDT) From: Wes Hardaker To: Ken Hornstein Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Organization: Sparta References: <200505041621.j44GLisV029505@ginger.cmf.nrl.navy.mil> Date: Wed, 04 May 2005 11:07:00 -0700 In-Reply-To: <200505041621.j44GLisV029505@ginger.cmf.nrl.navy.mil> (Ken Hornstein's message of "Wed, 04 May 2005 12:21:46 -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: 798b2e660f1819ae38035ac1d8d5e3ab Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Wed, 04 May 2005 12:21:46 -0400, Ken Hornstein said: Ken> As you all know, there has been a lot of discussion relating to Ken> different security architectures. Juergen and I have talked it Ken> over, and we both have agreed that there is a _very_ rough Ken> consensus for EK as the security architecture for the ISMS WG. I don't envy being in the WG chair's shoes for having to make this decision. The numbers show that a fair number of people don't find EK their favorite (in fact it's the least of favorites; it wasn't my favorite for instance) but it is one I think everyone can at least settle on. Having now settled on a path forward, is there alternative proposals aside from DTLS to consider? Certainly DTLS is a framework and we'll likely need instantiations of that framework for individual technologies (TLS, SSH, DTLS, ...). Or are there people that have alternative proposals to how DTLS itself is defining the solution space? -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 14:13:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOKk-00030Y-Us; Wed, 04 May 2005 14:10:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOKj-00030L-Ht for isms@megatron.ietf.org; Wed, 04 May 2005 14:10:53 -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 OAA09129 for ; Wed, 4 May 2005 14:10:52 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTOYq-00073T-Uh for isms@ietf.org; Wed, 04 May 2005 14:25:30 -0400 Received: from pc6 (1Cust240.tnt103.lnd4.gbr.da.uu.net [213.116.54.240]) by galaxy.systems.pipex.net (Postfix) with SMTP id 3D469E00013F; Wed, 4 May 2005 19:10:40 +0100 (BST) Message-ID: <01d701c550cb$a75cff00$0601a8c0@pc6> From: "Tom Petch" To: "Wes Hardaker" References: <474EEBD229DF754FB83D256004D021080EC276@XCH-NW-6V1.nw.nos.boeing.com><6.2.0.14.0.20050503102434.04f02a60@email.cisco.com><005201c55013$282bffa0$7f1afea9@oemcomputer> Subject: Re: [Isms] One touch; was CALL FOR CONSENSUS: ISMS Architecture Date: Wed, 4 May 2005 19:06:30 +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: 82c9bddb247d9ba4471160a9a865a5f3 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 Wes What is acceptable? Ken said he could not imagine a zero touch secure system and nor can I. So at the very least, I have to put in a secret of some shape or form when I instal the box, along with IPv4 address, default gateway, sysName, sysContact etc. Whether that happens to be the key for a preinstalled USM user, a secret used for OOBK, the password of root/superuser, it makes no difference, I believe it still has to be done. Of course you also have to prevent its re-entry except under controlled circumstances but that is what we have today (in non-SNMP environments). And with SNMPv3, it could be tied into the input of engine id, so both go in together or not at all. Tom Petch ----- Original Message ----- From: "Wes Hardaker" To: "Randy Presuhn" Cc: Sent: Tuesday, May 03, 2005 10:35 PM Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture > >>>>> On Tue, 3 May 2005 12:05:22 -0700, "Randy Presuhn" said: > > Randy> However, any SNMP stack out there that supports USM should > Randy> provide the ability to use SNMPv3 to set the keys. Rather than > Randy> modifying the SNMP stack, or modifying the existing "OOB > Randy> service", one could use an application acting on behalf of the > Randy> security administrator to talk to the OOB service, and use > Randy> SNMPv3 to set the USM keys. > > The thought had crossed my mind as well, but that still requires > either provisioning of the SNMPv3 service with an initial USM user > (bad IMHO) or requires the service to be run on the same host and a > noAuthNoPriv user with access privileges tied to the loopback address > (or any other form of an internal-to-the-box-trusted-network) which > probably doesn't exist in most implementations today. > > Requiring the setup of just one USM user instead of X is still bad, > IMHO, because operators don't want to do this today either. > > -- > Wes Hardaker > Sparta, Inc. > > _______________________________________________ > 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 Wed May 04 14:13:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOMP-0003Lh-8z; Wed, 04 May 2005 14:12:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOMN-0003LK-Bl for isms@megatron.ietf.org; Wed, 04 May 2005 14:12:35 -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 OAA09420 for ; Wed, 4 May 2005 14:12:33 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTOaU-00077F-FP for isms@ietf.org; Wed, 04 May 2005 14:27:11 -0400 Received: from h-68-165-7-59.snvacaid.dynamic.covad.net ([68.165.7.59] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DTOMJ-00019x-00 for isms@ietf.org; Wed, 04 May 2005 11:12:31 -0700 Message-ID: <001c01c550d5$25b67da0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200505041409.j44E9bXS026620@ginger.cmf.nrl.navy.mil> Subject: Re: [Isms] Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture Date: Wed, 4 May 2005 11:14:43 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Ken Hornstein" > To: > Sent: Wednesday, May 04, 2005 7:09 AM > Subject: Re: [Isms] Kerberos and PKI; was What is Out Of Band Keying;was CALL FOR CONSENSUS: ISMS Architecture ... > A correction here. Kerberos requires communication _only_ between the > manager and the Kerberos server. It requires _zero_ communication > between the agent and the Kerberos server (I'm assuming here we're > using Kerberos in a "traditional" role, and not anything unusual like > having both sides do U2U). The communication isn't even that frequent; > you can cache the necessary information on the manager side, so you > only need to talk to the Kerberos server once per agent per ticket > lifetime. ... This leaves me rather puzzled. Could someone explain how authenticated notification transmission would work? Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 14:13:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOKj-00030Q-Ns; Wed, 04 May 2005 14:10:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOKi-00030G-Fw for isms@megatron.ietf.org; Wed, 04 May 2005 14:10: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 OAA09116 for ; Wed, 4 May 2005 14:10:51 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTOYq-00072W-Ul for isms@ietf.org; Wed, 04 May 2005 14:25:29 -0400 Received: from pc6 (1Cust240.tnt103.lnd4.gbr.da.uu.net [213.116.54.240]) by galaxy.systems.pipex.net (Postfix) with SMTP id 55CA7E0000C5; Wed, 4 May 2005 19:10:37 +0100 (BST) Message-ID: <01d601c550cb$a6412ec0$0601a8c0@pc6> From: "Tom Petch" To: "Fleischman, Eric" References: <474EEBD229DF754FB83D256004D021080EC27A@XCH-NW-6V1.nw.nos.boeing.com> Date: Wed, 4 May 2005 19:01:17 +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: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: [Isms] Re: Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture 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 Eric, mmm ... is your 90% Microsoft a percentage of the entire SNMP engine base, manager and agent, command generator and command responder, etc ? I see a similar figure for the population of workstations and servers, but not when I include network devices (hub, switch, router, NAS, firewall etc) most of which come from another three or four vendors. So if we had a solution that was Microsoft only(!!!!!), perhaps relying on Kerberos, would that meet 90% of your needs? Because another tenet of mine is that the cost of perfection is infinite, so to meet 100% of anything is astronomic and almost always uneconomic, so as an engineer, I need to prioritise and meet a high enough percentage for 'it' to be worthwhile eg if I cannot secure Notification class PDU, that is a loss, but my judgement is that it is not a fatal loss (I think I know who is going to disagree with me on that example :-). Starting at the other end, if we only secure the ability to Set operational and customisation parameters (while meeting the constraints of the isms charter), we would still have a worthwhile enhancement (but I expect you will disagree with that:-( And yes, Wes survey was of operators, not enterprises (which is where most of my experience comes from). To quote " 5 --- 3 Device Vendor 71 Network Operator 2 Research 1 Software Vendor" And the other quote "Which user authentication mechanisms do you use: 39 radius 32 TACACS+ 61 local-accounts 41 ssh-keys 8 kerberos 11 x.509-certificates" Tom Petch ----- Original Message ----- From: "Fleischman, Eric" To: "Tom Petch" Cc: Sent: Wednesday, May 04, 2005 12:10 AM Subject: RE: Kerberos and PKI; was What is Out Of Band Keying;was CALL FOR CONSENSUS: ISMS Architecture >From: Tom Petch [mailto:nwnetworks@dial.pipex.com] >Historically I have associated it [Kerberos] with Unix platforms >but since Microsoft has made it part of Windows 200x >Server, I expect it will become much more widely known >and deployed. So although Wes' survey showed only 10% >(from memory) interest, I expect that to grow. My memory is that Wes' survey occurred at a meeting that was primarily populated by Internet Service Providers (ISP). Having "hung out" with ISPs at the IETF for over a decade, I've concluded that the ISPs' environments are very different from our (very large end users) environments. For example, in our environments more than 90% of the devices use a Microsoft operating system that natively supports Kerberos by default. [Note: this is a statistic -- not a value judgement. Please exclude me from Unix-vs-Microsoft or end-system-vs-intermediate-system flames.] _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 14:23:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOWn-00084p-B6; Wed, 04 May 2005 14:23:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOWl-00084k-Qt for isms@megatron.ietf.org; Wed, 04 May 2005 14:23:19 -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 OAA10871 for ; Wed, 4 May 2005 14:23:18 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTOkt-0007Tt-HP for isms@ietf.org; Wed, 04 May 2005 14:37:56 -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 j44IN9Vp002391 for ; Wed, 4 May 2005 14:23:10 -0400 (EDT) Message-Id: <200505041823.j44IN9Vp002391@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture In-Reply-To: <001c01c550d5$25b67da0$7f1afea9@oemcomputer> 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: Wed, 04 May 2005 14:23:12 -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: e5ba305d0e64821bf3d8bc5d3bb07228 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 >> A correction here. Kerberos requires communication _only_ between the >> manager and the Kerberos server. It requires _zero_ communication >> between the agent and the Kerberos server (I'm assuming here we're >> using Kerberos in a "traditional" role, and not anything unusual like >> having both sides do U2U). The communication isn't even that frequent; >> you can cache the necessary information on the manager side, so you >> only need to talk to the Kerberos server once per agent per ticket >> lifetime. > >This leaves me rather puzzled. Could someone explain how authenticated >notification transmission would work? That was one of those things that I confess I had never really tackled with the KSM implementation I did for Net-SNMP. Some possibilites include: - Simply "punt", and use USM for notifications. - Use the Kerberos authentication context you get from the manager-agent authentication to get the keys used to authenticate/encrypt the notification. - Actually perform a full Kerberos "client" authentication from the agent to talk to the manager. In this case, the agent would need to talk to the Kerberos server to perform the notification (but it could cache it instead of having to talk to the Kerberos server right as it was doing the notification). I think probably the best approach was doing something like the second idea; when you set up the trap, you would say, "Use this key to talk to me". None of the approaches are wonderful, though, but there certainly is _some_ way to do it. But I guess it's all moot now :-) --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 14:30:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOe9-0001kC-0K; Wed, 04 May 2005 14:30:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOe7-0001h8-L0 for isms@megatron.ietf.org; Wed, 04 May 2005 14:30:55 -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 OAA11729 for ; Wed, 4 May 2005 14:30:54 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTOsF-0007hF-BP for isms@ietf.org; Wed, 04 May 2005 14:45:32 -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 j44IUJoF002778; Wed, 4 May 2005 11:30:19 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j44IUGQ2024726; Wed, 4 May 2005 11:30:16 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j44IUG8I024720; Wed, 4 May 2005 11:30:16 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 4 May 2005 11:30:16 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Wes Hardaker Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, I'm glad that a direction has been set to move forward. With this choice, it seems like the next questions are: 1) is it possible to use the same default ports (161 & 162) with DTLS and TLS(SSL)? 2) is it possible to add another mechanism to DTLS and TLS to use the SSH server's key and the SSH client keys, because I believe that would be better than supporting both SSH and DTLS (and TLS) encapsulation. However, I need to consult with some friends that just went through this situation. Back in the fall, there were some discussions about the technical issues in using EK. Ken - do you want a summary, and a list of other technical issues that need to be reviewed and resolved? On Wed, 4 May 2005, Wes Hardaker wrote: > >>>>> On Wed, 04 May 2005 12:21:46 -0400, Ken Hornstein said: > > Ken> As you all know, there has been a lot of discussion relating to > Ken> different security architectures. Juergen and I have talked it > Ken> over, and we both have agreed that there is a _very_ rough > Ken> consensus for EK as the security architecture for the ISMS WG. > > I don't envy being in the WG chair's shoes for having to make this > decision. The numbers show that a fair number of people don't find EK > their favorite (in fact it's the least of favorites; it wasn't my > favorite for instance) but it is one I think everyone can at least > settle on. > > Having now settled on a path forward, is there alternative proposals > aside from DTLS to consider? Certainly DTLS is a framework and we'll > likely need instantiations of that framework for individual > technologies (TLS, SSH, DTLS, ...). Or are there people that have > alternative proposals to how DTLS itself is defining the solution space? > > -- > Wes Hardaker Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 14:32:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOfI-0001t2-MJ; Wed, 04 May 2005 14:32:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOfH-0001sx-Kq for isms@megatron.ietf.org; Wed, 04 May 2005 14:32:07 -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 OAA11837 for ; Wed, 4 May 2005 14:32:06 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTOtP-0007kC-Fm for isms@ietf.org; Wed, 04 May 2005 14:46:44 -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 j44IVvk4002590 for ; Wed, 4 May 2005 14:31:58 -0400 (EDT) Message-Id: <200505041831.j44IVvk4002590@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK In-Reply-To: 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: Wed, 04 May 2005 14:31:59 -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: 30ac594df0e66ffa5a93eb4c48bcb014 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 >Back in the fall, there were some discussions about the >technical issues in using EK. >Ken - do you want a summary, and a list of other technical >issues that need to be reviewed and resolved? Actually, if you wanted to do that, I think that would be a good jumping-off point. So, "yes". --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 14:40:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOnO-0004zS-KF; Wed, 04 May 2005 14:40:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOnN-0004zN-AB for isms@megatron.ietf.org; Wed, 04 May 2005 14:40:29 -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 OAA12879 for ; Wed, 4 May 2005 14:40:27 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTP1U-00080Y-9d for isms@ietf.org; Wed, 04 May 2005 14:55:06 -0400 Received: from h-68-165-6-120.snvacaid.dynamic.covad.net ([68.165.6.120] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DTOnI-0006Wz-00 for isms@ietf.org; Wed, 04 May 2005 11:40:25 -0700 Message-ID: <001201c550d9$0c95db00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200505041823.j44IN9Vp002391@ginger.cmf.nrl.navy.mil> Subject: Re: [Isms] Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture Date: Wed, 4 May 2005 11:42:39 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Ken Hornstein" > To: > Sent: Wednesday, May 04, 2005 11:23 AM > Subject: Re: [Isms] Kerberos and PKI; was What is Out Of Band Keying;was CALL FOR CONSENSUS: ISMS Architecture > > >> A correction here. Kerberos requires communication _only_ between the > >> manager and the Kerberos server. It requires _zero_ communication > >> between the agent and the Kerberos server (I'm assuming here we're > >> using Kerberos in a "traditional" role, and not anything unusual like > >> having both sides do U2U). The communication isn't even that frequent; > >> you can cache the necessary information on the manager side, so you > >> only need to talk to the Kerberos server once per agent per ticket > >> lifetime. > > > >This leaves me rather puzzled. Could someone explain how authenticated > >notification transmission would work? > > That was one of those things that I confess I had never really tackled > with the KSM implementation I did for Net-SNMP. Some possibilites include: > > - Simply "punt", and use USM for notifications. > - Use the Kerberos authentication context you get from the manager-agent > authentication to get the keys used to authenticate/encrypt the > notification. > - Actually perform a full Kerberos "client" authentication from the agent > to talk to the manager. In this case, the agent would need to talk to > the Kerberos server to perform the notification (but it could cache it > instead of having to talk to the Kerberos server right as it was doing > the notification). > > I think probably the best approach was doing something like the second > idea; when you set up the trap, you would say, "Use this key to talk to > me". None of the approaches are wonderful, though, but there certainly > is _some_ way to do it. But I guess it's all moot now :-) ... But this leads to the point of my question: Any solution formulated in terms of "manager" and "agent" will require either such ugliness or a rework of the SNMPv3 architecture. I hate to keep harping on this point, but it's really fundamental. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 14:41:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOnt-0005D5-Or; Wed, 04 May 2005 14:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOns-0005A1-6V for isms@megatron.ietf.org; Wed, 04 May 2005 14:41:00 -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 OAA12920 for ; Wed, 4 May 2005 14:40:58 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTP20-00081p-V0 for isms@ietf.org; Wed, 04 May 2005 14:55:37 -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 j44IeioF005637; Wed, 4 May 2005 11:40:45 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j44Ieg02027487; Wed, 4 May 2005 11:40:42 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j44IefrP027480; Wed, 4 May 2005 11:40:42 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 4 May 2005 11:40:41 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Tom Petch Subject: Re: [Isms] One touch; was CALL FOR CONSENSUS: ISMS Architecture In-Reply-To: <01d701c550cb$a75cff00$0601a8c0@pc6> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, Tom - the goal is not "zero touch for the box", but "zero touch" to add support for SNMP. The ideal is that a box is configured for management without support for SNMP. Then when it is decided to support SNMP, the only thing that is done is to turn on SNMP support for the box. Ideally, if syslog targets have already been set up, then SNMP can use them for notification targets. Ideally, the identities that have been set up for OTHER management activities can be used for SNMP request operations on the box. On Wed, 4 May 2005, Tom Petch wrote: > Wes > > What is acceptable? Ken said he could not imagine a zero touch secure system > and nor can I. So at the very least, I have to put in a secret of some shape or > form when I instal the box, along with IPv4 address, default gateway, sysName, > sysContact etc. > > Whether that happens to be the key for a preinstalled USM user, a secret used > for OOBK, the password of root/superuser, it makes no difference, I believe it > still has > to be done. > > Of course you also have to prevent its re-entry except under controlled > circumstances but that is what we have today (in non-SNMP environments). And > with SNMPv3, it could be tied into the input of engine id, so both go in > together or not at all. > > Tom Petch > > ----- Original Message ----- > From: "Wes Hardaker" > To: "Randy Presuhn" > Cc: > Sent: Tuesday, May 03, 2005 10:35 PM > Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture > > > > >>>>> On Tue, 3 May 2005 12:05:22 -0700, "Randy Presuhn" > said: > > > > Randy> However, any SNMP stack out there that supports USM should > > Randy> provide the ability to use SNMPv3 to set the keys. Rather than > > Randy> modifying the SNMP stack, or modifying the existing "OOB > > Randy> service", one could use an application acting on behalf of the > > Randy> security administrator to talk to the OOB service, and use > > Randy> SNMPv3 to set the USM keys. > > > > The thought had crossed my mind as well, but that still requires > > either provisioning of the SNMPv3 service with an initial USM user > > (bad IMHO) or requires the service to be run on the same host and a > > noAuthNoPriv user with access privileges tied to the loopback address > > (or any other form of an internal-to-the-box-trusted-network) which > > probably doesn't exist in most implementations today. > > > > Requiring the setup of just one USM user instead of X is still bad, > > IMHO, because operators don't want to do this today either. > > > > -- > > Wes Hardaker > > Sparta, Inc. Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 14:49:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOvr-0007JL-LQ; Wed, 04 May 2005 14:49:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOvq-0007JG-G4 for isms@megatron.ietf.org; Wed, 04 May 2005 14:49:14 -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 OAA13630 for ; Wed, 4 May 2005 14:49:12 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTP9z-0008Dz-EU for isms@ietf.org; Wed, 04 May 2005 15:03:51 -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 j44In7dJ002916 for ; Wed, 4 May 2005 14:49:08 -0400 (EDT) Message-Id: <200505041849.j44In7dJ002916@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture In-Reply-To: <001201c550d9$0c95db00$7f1afea9@oemcomputer> 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: Wed, 04 May 2005 14:49:10 -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: 9466e0365fc95844abaf7c3f15a05c7d 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 >> I think probably the best approach was doing something like the second >> idea; when you set up the trap, you would say, "Use this key to talk to >> me". None of the approaches are wonderful, though, but there certainly >> is _some_ way to do it. But I guess it's all moot now :-) >... > >But this leads to the point of my question: Any solution formulated in terms >of "manager" and "agent" will require either such ugliness or a rework of the >SNMPv3 architecture. I hate to keep harping on this point, but it's really >fundamental. "Shrug". All I can say is, in _my extremely limited_ practice it never really was an issue. I personally didn't care about notifications, and the people who used KSM didn't really care either. I'm not saying that we _shouldn't_ care about notifications, I'm just saying that for the security model I devised, the users of it didn't seem to care (maybe they cared, but if they did, they didn't tell me about it). I only chose the terms "manager" and "agent" because in Kerberos, there is a very clearly definied client and server role (the client talks to the KDC, the server does not). Everyone knows that manager means "client" and agent means "server" in the vast majority of SNMP messages. Throwing command generator and command responder in the mix just gets confusing. If you wanted a "pure" solution, the third solution I outlined above would be the right approach. I could have done it in Net-SNMP, but it would have required more code than I was willing to write at the time. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 14:54:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTP16-0000Ki-Ij; Wed, 04 May 2005 14:54:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTP14-0000Js-RA for isms@megatron.ietf.org; Wed, 04 May 2005 14:54: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 OAA14217 for ; Wed, 4 May 2005 14:54:36 -0400 (EDT) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTPFC-0008ML-DA for isms@ietf.org; Wed, 04 May 2005 15:09:15 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j44Irw9D019896; Wed, 4 May 2005 18:53:58 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j44IrcK6013248; Wed, 4 May 2005 18:53:58 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005050411535802441 ; Wed, 04 May 2005 11:53:58 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 11:53:57 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 11:53:57 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 14:53:55 -0400 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] Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture Date: Wed, 4 May 2005 14:53:26 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C59290115AE7F@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture Thread-Index: AcVQ2hk8OBcEPFvmRQORRV5NVsrYeAAABNRQ From: "Blumenthal, Uri" To: "Ken Hornstein" , X-OriginalArrivalTime: 04 May 2005 18:53:55.0894 (UTC) FILETIME=[9F7F4D60:01C550DA] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Why not create a security model that doesn't support notifications, for those who don't really care... After all, if the market doesn't care - why bother... And those who do care, would use a different model (or whatever).=20 =20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Ken Hornstein Sent: Wednesday, May 04, 2005 2:49 PM To: isms@ietf.org Subject: Re: [Isms] Kerberos and PKI; was What is Out Of Band Keying;was CALL FOR CONSENSUS: ISMS Architecture=20 >> I think probably the best approach was doing something like the second >> idea; when you set up the trap, you would say, "Use this key to talk to >> me". None of the approaches are wonderful, though, but there certainly >> is _some_ way to do it. But I guess it's all moot now :-) >... > >But this leads to the point of my question: Any solution formulated in terms >of "manager" and "agent" will require either such ugliness or a rework of the >SNMPv3 architecture. I hate to keep harping on this point, but it's really >fundamental. "Shrug". All I can say is, in _my extremely limited_ practice it never really was an issue. I personally didn't care about notifications, and the people who used KSM didn't really care either. I'm not saying that we _shouldn't_ care about notifications, I'm just saying that for the security model I devised, the users of it didn't seem to care (maybe they cared, but if they did, they didn't tell me about it). I only chose the terms "manager" and "agent" because in Kerberos, there is a very clearly definied client and server role (the client talks to the KDC, the server does not). Everyone knows that manager means "client" and agent means "server" in the vast majority of SNMP messages. Throwing command generator and command responder in the mix just gets confusing. If you wanted a "pure" solution, the third solution I outlined above would be the right approach. I could have done it in Net-SNMP, but it would have required more code than I was willing to write at the time. --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 From isms-bounces@lists.ietf.org Wed May 04 14:55:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTP22-0000em-D4; Wed, 04 May 2005 14:55:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTP21-0000ed-HV for isms@megatron.ietf.org; Wed, 04 May 2005 14:55:37 -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 OAA14304 for ; Wed, 4 May 2005 14:55:35 -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 1DTPG8-0008OX-PU for isms@ietf.org; Wed, 04 May 2005 15:10:14 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 May 2005 11:55:26 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j44ItKhu027368; Wed, 4 May 2005 11:55:21 -0700 (PDT) Received: from [212.254.247.4] (ams-clip-vpn-dhcp4570.cisco.com [10.61.81.217]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j44IjTSr019908; Wed, 4 May 2005 11:45:30 -0700 Message-ID: <42791A96.20301@cisco.com> Date: Wed, 04 May 2005 20:55:18 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Hornstein Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK References: <200505041621.j44GLisV029505@ginger.cmf.nrl.navy.mil> In-Reply-To: <200505041621.j44GLisV029505@ginger.cmf.nrl.navy.mil> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115232331.146837"; x:"432200"; a:"rsa-sha1"; b:"nofws:121"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"HjG/Q5iJFB4eoKFoExtoyCNxfkk94zf//jUiF2VedFC4xYD02NWJt2vZ72tofVOug3gyZqpU" "xPFW0oDe+vTf+2KLQMatlHp4M8kgCS6zz79dJYZzNmG3vVx/+W3vzZ0k5j/1rAeD4+wLYufbL4B" "NNpUaiwylku796ks3t6AX3XQ="; c:"Date: Wed, 04 May 2005 20:55:18 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture i" "s EK" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 Ken, Why doesn't this look to you like a 3 way tie? Not that I like the results, mind you, but then I am up for option (d) which is not on the table. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 14:58:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTP4K-0001BF-GU; Wed, 04 May 2005 14:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTP4I-0001BA-M1 for isms@megatron.ietf.org; Wed, 04 May 2005 14:57:58 -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 OAA14593 for ; Wed, 4 May 2005 14:57:56 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTPIR-0008Ty-F3 for isms@ietf.org; Wed, 04 May 2005 15:12:36 -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 j44IvnoF008930; Wed, 4 May 2005 11:57:49 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j44IvlXB032010; Wed, 4 May 2005 11:57:47 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j44IvkO8032002; Wed, 4 May 2005 11:57:47 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 4 May 2005 11:57:46 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Randy Presuhn Subject: Re: [Isms] Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture In-Reply-To: <001201c550d9$0c95db00$7f1afea9@oemcomputer> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, Randy - would you provide some "pictures" that illustrate your point about the SNMP architecture. On Wed, 4 May 2005, Randy Presuhn wrote: > But this leads to the point of my question: Any solution formulated in terms > of "manager" and "agent" will require either such ugliness or a rework of the > SNMPv3 architecture. I hate to keep harping on this point, but it's really > fundamental. > > Randy Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 14:59:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTP5r-0001ep-Rv; Wed, 04 May 2005 14:59:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTP5q-0001ee-PJ for isms@megatron.ietf.org; Wed, 04 May 2005 14:59:34 -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 OAA14939 for ; Wed, 4 May 2005 14:59:32 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTPJw-00006h-G2 for isms@ietf.org; Wed, 04 May 2005 15:14:12 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA14891; Wed, 4 May 2005 11:59:21 -0700 (PDT) Received: from XCH-NWBH-02.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 j44IxKG24067; Wed, 4 May 2005 13:59:20 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 11:59:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2005 11:58:40 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC280@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture Thread-Index: AcVQ1bLOIxF1CczgRHqXq4/gxol0swAAVkmw From: "Fleischman, Eric" To: "Tom Petch" X-OriginalArrivalTime: 04 May 2005 18:59:05.0682 (UTC) FILETIME=[58253320:01C550DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org Subject: [Isms] RE: Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture 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 >From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 >Eric, mmm ... is your 90% Microsoft a percentage of=20 >the entire SNMP engine base, manager and agent,=20 >command generator and command responder, etc ? =20 >I see a similar figure for the population of workstations=20 >and servers, but not when I include network devices (hub,=20 >switch, router, NAS, firewall etc) most of which come=20 >from another three or four vendors. I expect different enterprises to have different device populations that reflect many internal factors. The numbers I gave you reflect the censii (plural of census?) I have seen about the environment I am most familiar with: roughly 95% of computers Windows, 5% other. Back in the early 90s we had roughly a 20:1 ratio of computers-to-intermediate systems. This, of course, is a reflection of topology, which definitely varies site to site, but I expect the ratio to be higher today. That was the logic behind for the numbers I gave you. >So if we had a solution that was Microsoft only(!!!!!),=20 >perhaps relying on Kerberos, would that meet 90% of your needs? No, it doesn't work that way. Just because I have more of X than I have of Y, doesn't mean that I value X more than Y. Large corporations usually have vastly more PCs than high end servers and more high end servers than mainframes and more mainframes than supercomputers. However, few would doubt the importance of supercomputers or mainframes when compared to PCs. Regardless, businesses need to manage the devices their business is built upon. We strive for a consistent architecture but often have to deal with distinct populations. Different populations sadly have different requirements. This is why I have been emphasizing the need for both PKI and Kerberos for enterprise support as well as policy servers (e.g., Radius, COPS servers). "One size fits all" is not today's reality. >Because another tenet of mine is that the cost=20 >of perfection is infinite, so to meet 100% of=20 >anything is astronomic and almost always uneconomic,=20 >so as an engineer, I need to prioritise and meet a=20 >high enough percentage for 'it' to be worthwhile=20 Amen! I fully agree. But in this case, I believe that our requirement is for flexibility to support diverse authentication systems. TACACS+ is not very important to us but it probably is very important to others. I'd like our WG to strive to support both communities before concluding that we could only support one. If we must only support one (or a few), then get the "big hitters" which I believe to be (1) Kerberos, (2) PKI, (3) Radius, (4) I'm not sure, maybe SSH? It's really hard to know... Of course, if you only care about ISPs, then you could use Wes' survey list. But his list was ISP specific, and we end users represent a significantly larger population to satisfy. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 15:04:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTPB0-0003TP-SK; Wed, 04 May 2005 15:04:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTPAz-0003SA-4J for isms@megatron.ietf.org; Wed, 04 May 2005 15:04:53 -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 PAA15675 for ; Wed, 4 May 2005 15:04:51 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTPP7-0000I5-3T for isms@ietf.org; Wed, 04 May 2005 15:19:30 -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 j44J4U1E003489 for ; Wed, 4 May 2005 15:04:31 -0400 (EDT) Message-Id: <200505041904.j44J4U1E003489@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK In-Reply-To: <42791A96.20301@cisco.com> 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: Wed, 04 May 2005 15:04:33 -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: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >Why doesn't this look to you like a 3 way tie? Not that I like the >results, mind you, but then I am up for option (d) which is not on the >table. I admit, it's close to a three-way tie. But the WG was told that we had to have an architecture picked by the end of April. Given that, we have to pick SOMETHING, or shut down. If people think that shutting down is the appropriate option, let's hear about it. But I don't think we have the opportunity to pick option (d). Juergen and I are of the opinion that EK seems to be the architecture that most people can live with (it had the least number of "no" votes, but again, not by a lot). This is why we decided there was rough consensus for it. It was not easy to make that decision, but .... well, shoot. I'm not sure what else we could have done. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 15:17:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTPN0-00080e-Pw; Wed, 04 May 2005 15:17:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTPMy-00080Z-Ty for isms@megatron.ietf.org; Wed, 04 May 2005 15:17:16 -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 PAA17651 for ; Wed, 4 May 2005 15:17:15 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTPb1-0000ei-Or for isms@ietf.org; Wed, 04 May 2005 15:31:54 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j44JH7ZC005675 for ; Wed, 4 May 2005 15:17:07 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 04 May 2005 15:17:08 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 04 May 2005 15:17:08 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 May 2005 15:17:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Date: Wed, 4 May 2005 15:17:07 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032314@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Thread-Index: AcVQ3Eq2bIB5dfHFQ7q/mh/0WsYdJAAAMIdg From: "Nelson, David" To: "Ken Hornstein" , X-OriginalArrivalTime: 04 May 2005 19:17:08.0241 (UTC) FILETIME=[DD669810:01C550DD] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:84.0661 M:98.8113 P:95.9108 R:95.9108 S:87.6856 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Ken Hornstein writes... > I'm not sure what else we could have done. Given the end-of-April deadline, not much. :-( If more time had been available, you could have knocked out the lowest scoring choice and called a run-off poll between the remaining two. Of course, if the "votes" from the eliminated contender split fairly evenly between the remaining contenders, we'd be in exactly the same position. Given that multiple choices could be selected in the last round of polling, the likelihood that a run-off poll would yield substantially different results is fairly low. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 15:32:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTPc8-0004an-Qq; Wed, 04 May 2005 15:32:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTPc8-0004af-0o for isms@megatron.ietf.org; Wed, 04 May 2005 15:32: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 PAA19711 for ; Wed, 4 May 2005 15:32:54 -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 1DTPqH-000184-8q for isms@ietf.org; Wed, 04 May 2005 15:47:33 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 04 May 2005 12:21:54 -0700 X-IronPort-AV: i="3.92,154,1112598000"; d="scan'208"; a="258894268:sNHT1220768262" Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j44JLl2w016647; Wed, 4 May 2005 12:21:48 -0700 (PDT) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA22977; Wed, 4 May 2005 12:21:52 -0700 (PDT) From: Keith McCloghrie Message-Id: <200505041921.MAA22977@cisco.com> Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK To: kenh@cmf.nrl.navy.mil (Ken Hornstein) Date: Wed, 4 May 2005 12:21:52 -0700 (PDT) In-Reply-To: from "Ken Hornstein" at May 04, 2005 03:04:33 PM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 > >Why doesn't this look to you like a 3 way tie? Not that I like the > >results, mind you, but then I am up for option (d) which is not on the > >table. > > I admit, it's close to a three-way tie. But the WG was told that we > had to have an architecture picked by the end of April. Given that, we > have to pick SOMETHING, or shut down. If people think that shutting > down is the appropriate option, let's hear about it. But I don't think > we have the opportunity to pick option (d). > > Juergen and I are of the opinion that EK seems to be the architecture > that most people can live with (it had the least number of "no" votes, > but again, not by a lot). This is why we decided there was rough > consensus for it. It was not easy to make that decision, but .... > well, shoot. I'm not sure what else we could have done. While there were some inaccuracies in the counts (**), I realise that you are trying to find some decision here. However, the basis on which you've chosen seems to be the least-liked keying mechanism, merely because it also happens to be least-hated keying mechanism. That seems to me to be a recipe for mediocrity. Neverthless, the "vote" just taken was for the keying mechanism; it was not for/against the proposals. So, if your decision is to stand, I respectfully request that the SBSM and EUSM proposals be given the *opportunity* to update their proposals to use Encapsulated Keying as their method of obtaining keys. Keith. ** There were some uncounted votes; it also appears that both "second pref" and "implied pref" were counted as "Yes", but "implied second pref" was counted as "Maybe", eh?? The AD's was counted in the "Yes" for all the proposals !! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 15:45:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTPod-0008P6-3t; Wed, 04 May 2005 15:45:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTPob-0008P1-LR for isms@megatron.ietf.org; Wed, 04 May 2005 15:45:49 -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 PAA21046 for ; Wed, 4 May 2005 15:45:47 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTQ2j-0001Wb-O7 for isms@ietf.org; Wed, 04 May 2005 16:00:27 -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 j44JjdeW004660 for ; Wed, 4 May 2005 15:45:39 -0400 (EDT) Message-Id: <200505041945.j44JjdeW004660@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK In-Reply-To: <200505041921.MAA22977@cisco.com> 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: Wed, 04 May 2005 15:45:41 -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: 97adf591118a232206bdb5a27b217034 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 >While there were some inaccuracies in the counts (**), I realise that >you are trying to find some decision here. However, the basis on which >you've chosen seems to be the least-liked keying mechanism, merely >because it also happens to be least-hated keying mechanism. That seems >to me to be a recipe for mediocrity. To be fair ... EK also got the most number of "Yes" votes (we're counting "maybe" as "yes" here). >Neverthless, the "vote" just taken was for the keying mechanism; it was >not for/against the proposals. So, if your decision is to stand, I >respectfully request that the SBSM and EUSM proposals be given the >*opportunity* to update their proposals to use Encapsulated Keying as >their method of obtaining keys. Absolutely. We haven't even started the protocol design; at this stage, anything could happen. >** There were some uncounted votes; it also appears that both "second >pref" and "implied pref" were counted as "Yes", but "implied second >pref" was counted as "Maybe", eh?? The AD's was counted in the "Yes" >for all the proposals !! I have Sam as "N y y". Are the totals wrong? I hope everyone understands that we're not going by absolute votes; the preference tallying was more of a tool to help us judge consensus, since it wasn't clear from the mailing list discussion. Given the opinions presented on the mailing list, combined with the preference tally, I still feel that EK was the closest thing we had to a rough consensus agreement. (I did go back and check the votes that we missed; they wouldn't have changed the overall ranking). --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 16:02:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQ4n-0006QA-Q8; Wed, 04 May 2005 16:02:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQ4m-0006Pd-Lu for isms@megatron.ietf.org; Wed, 04 May 2005 16:02:32 -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 QAA25918 for ; Wed, 4 May 2005 16:02:30 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTQIs-0003AW-Pr for isms@ietf.org; Wed, 04 May 2005 16:17:10 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B81D6E0063; Wed, 4 May 2005 16:02:25 -0400 (EDT) To: Eliot Lear Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK References: <200505041621.j44GLisV029505@ginger.cmf.nrl.navy.mil> <42791A96.20301@cisco.com> From: Sam Hartman Date: Wed, 04 May 2005 16:02:25 -0400 In-Reply-To: <42791A96.20301@cisco.com> (Eliot Lear's message of "Wed, 04 May 2005 20:55:18 +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: 79899194edc4f33a41f49410777972f8 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Eliot" == Eliot Lear writes: Eliot> Ken, Why doesn't this look to you like a 3 way tie? Not Eliot> that I like the results, mind you, but then I am up for Eliot> option (d) which is not on the table. If you have some alternative path forward by all means present it. I think I'd rather also assume that the consensus call will hold and go forward with the work of designing a solution while listening to other things we could have done from a process standpoint. My goal is not to shut anyone out, simply to make sure that we can try to be efficient. Here are some things I'd like to avoid: 1) Try all three (the IMPP option) 2) Argue for a month about how to make a decision. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 16:04:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQ6y-0007ot-IA; Wed, 04 May 2005 16:04:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQ6x-0007lZ-PV for isms@megatron.ietf.org; Wed, 04 May 2005 16:04: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 QAA26931 for ; Wed, 4 May 2005 16:04:45 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTQL6-0003Ty-1T for isms@ietf.org; Wed, 04 May 2005 16:19:25 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA05237; Wed, 4 May 2005 13:04:36 -0700 (PDT) Received: from XCH-NWBH-02.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 j44K4aN01523; Wed, 4 May 2005 13:04:36 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 13:04:35 -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] Rough Consensus Declaration: ISMS Architecture is EK Date: Wed, 4 May 2005 13:03:38 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC283@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Thread-Index: AcVQ4taXzngOg/JXTUOf7A+fACi4LwAAMJPw From: "Fleischman, Eric" To: "Ken Hornstein" , X-OriginalArrivalTime: 04 May 2005 20:04:35.0513 (UTC) FILETIME=[7E81D290:01C550E4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 I suggest that we accept the result and move on.=20 I recommend this because they are still fighting over my home state's (Washington State) most recent governor election in the courts, since it seems like a great many criminals and dead people voted in our last election. The election itself had three official re-counts before the courts stepped in.=20 I fear that we don't accept this count, what will be the basis to finally end to the resulting re-counts? Let's not go there... _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 16:06:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQ8O-0000Md-R5; Wed, 04 May 2005 16:06:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQ8M-0000Lm-Rk for isms@megatron.ietf.org; Wed, 04 May 2005 16:06:14 -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 QAA27544 for ; Wed, 4 May 2005 16:06:12 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTQMU-0003jN-VQ for isms@ietf.org; Wed, 04 May 2005 16:20:52 -0400 Received: from h-68-165-6-120.snvacaid.dynamic.covad.net ([68.165.6.120] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DTQ8J-0005QV-00 for isms@ietf.org; Wed, 04 May 2005 13:06:11 -0700 Message-ID: <005201c550e5$08945980$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Isms] Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture Date: Wed, 4 May 2005 13:08:26 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David T. Perkins" > To: "Randy Presuhn" > Cc: > Sent: Wednesday, May 04, 2005 11:57 AM > Subject: Re: [Isms] Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture ... > Randy - would you provide some "pictures" that illustrate your point > about the SNMP architecture. ... The ASCII art is in RFC 3411. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 16:07:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQ9i-0001PT-Qj; Wed, 04 May 2005 16:07:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQ9f-0001OQ-Nx for isms@megatron.ietf.org; Wed, 04 May 2005 16:07:37 -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 QAA28320 for ; Wed, 4 May 2005 16:07:33 -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 1DTQNo-0003zq-BS for isms@ietf.org; Wed, 04 May 2005 16:22:13 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 May 2005 13:07:26 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j44K7Mhu017922; Wed, 4 May 2005 13:07:22 -0700 (PDT) Received: from [212.254.247.4] (ams-clip-vpn-dhcp286.cisco.com [10.61.65.30]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j44JvTAR020653; Wed, 4 May 2005 12:57:30 -0700 Message-ID: <42792B77.8020005@cisco.com> Date: Wed, 04 May 2005 22:07:19 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Hornstein Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK References: <200505041904.j44J4U1E003489@ginger.cmf.nrl.navy.mil> In-Reply-To: <200505041904.j44J4U1E003489@ginger.cmf.nrl.navy.mil> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115236652.427580"; x:"432200"; a:"rsa-sha1"; b:"nofws:777"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"mq9EdytIgITesP5wC7ZX6OylWsV9hFmajy9MN6MTi9rhYBpCkpEpkOap1b+Us4CK9TJ+wxBJ" "bH1AQGVhWIjcjuoX4wIsa9yC8iSaFhQ6mb4vsjV5Xbq2KyI0e6lQIbqSoXd7Ent3zgi0NeJk8Qh" "XkMFvZQJGMNx/VWr8vYhDC6o="; c:"Date: Wed, 04 May 2005 22:07:19 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture i" "s EK" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit 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 Ken Hornstein wrote: > I admit, it's close to a three-way tie. But the WG was told that we > had to have an architecture picked by the end of April. Given that, we > have to pick SOMETHING, or shut down. Look, I don't want us to shut down, but I think this isn't right. While it is true that the chairs are given wide latitude when it comes to consensus, I think this violates the spirit of the rule. Can we please all recognize that we really don't have consensus, and that we all need to step back a bit and figure out why not? Often times when this happens different people are trying to solve different problems. And I see some evidence of that in the discussion between David, Wes and Joe, for instance. Maybe we even need two solutions? Maybe we need to get more enterprise/soho/sp operator input? Roadshow, anyone? A few of us including Bert, Andy, and I did this for NETCONF. Wasn't happy with what they told me but at least they told me stuff. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 16:09:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQB9-0002OW-RU; Wed, 04 May 2005 16:09:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQB7-0002ND-NO for isms@megatron.ietf.org; Wed, 04 May 2005 16:09:05 -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 QAA28921 for ; Wed, 4 May 2005 16:09:03 -0400 (EDT) Received: from i867c.i.pppool.de ([85.73.134.124] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTQPG-0004DF-6P for isms@ietf.org; Wed, 04 May 2005 16:23:43 -0400 Received: by boskop.local (Postfix, from userid 501) id 9D5852DACAB; Wed, 4 May 2005 22:08:45 +0200 (CEST) Date: Wed, 4 May 2005 22:08:45 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Message-ID: <20050504200845.GB388@boskop.local> Mail-Followup-To: Wes Hardaker , Ken Hornstein , isms@ietf.org References: <200505041621.j44GLisV029505@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@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, May 04, 2005 at 11:07:00AM -0700, Wes Hardaker wrote: > Having now settled on a path forward, is there alternative proposals > aside from DTLS to consider? Certainly DTLS is a framework and we'll > likely need instantiations of that framework for individual > technologies (TLS, SSH, DTLS, ...). Or are there people that have > alternative proposals to how DTLS itself is defining the solution space? Did you mean s/DTLS/TLSM/g ? I do think if this WG continues, we should try to define a general approach to do EK and than map to concrete protocols, whether that is TLS, DTLS, SSH, ... /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 May 04 16:15:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQHL-00068W-LA; Wed, 04 May 2005 16:15:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQHJ-00067l-Rm for isms@megatron.ietf.org; Wed, 04 May 2005 16:15:29 -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 QAA00485 for ; Wed, 4 May 2005 16:15:27 -0400 (EDT) Received: from i867c.i.pppool.de ([85.73.134.124] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTQVT-0004kz-4u for isms@ietf.org; Wed, 04 May 2005 16:30:07 -0400 Received: by boskop.local (Postfix, from userid 501) id C39702DACEA; Wed, 4 May 2005 22:15:19 +0200 (CEST) Date: Wed, 4 May 2005 22:15:19 +0200 From: Juergen Schoenwaelder To: "Nelson, David" Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Message-ID: <20050504201519.GC388@boskop.local> Mail-Followup-To: "Nelson, David" , Ken Hornstein , isms@ietf.org References: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032314@MAANDMBX2.ets.enterasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032314@MAANDMBX2.ets.enterasys.com> User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, May 04, 2005 at 03:17:07PM -0400, Nelson, David wrote: > If more time had been available, you could have knocked out the lowest > scoring choice and called a run-off poll between the remaining two. Of > course, if the "votes" from the eliminated contender split fairly evenly > between the remaining contenders, we'd be in exactly the same position. This is IMHO an illusion. Having followed this list from the beginning, I hardly see really new contributions. People have different requirements for pretty good reasons and since we have to select one there is little hope to get to a clearer result by just waiting longer and doing more elaborate measures of consensus. We either stop now or we pick a direction. We have already wasted quite some time on this decision and it is time to either move forward or to simply give up. /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 May 04 16:19:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQLJ-0001TJ-Cy; Wed, 04 May 2005 16:19:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQLH-0001T5-I7 for isms@megatron.ietf.org; Wed, 04 May 2005 16:19:35 -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 QAA00948 for ; Wed, 4 May 2005 16:19:33 -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 1DTQZQ-0004uX-Uk for isms@ietf.org; Wed, 04 May 2005 16:34:13 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 04 May 2005 13:09:57 -0700 X-IronPort-AV: i="3.92,154,1112598000"; d="scan'208"; a="258933838:sNHT3649517638" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j44K9mKx002146; Wed, 4 May 2005 13:09:49 -0700 (PDT) Received: from [212.254.247.4] (ams-clip-vpn-dhcp286.cisco.com [10.61.65.30]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j44K03EJ020687; Wed, 4 May 2005 13:00:04 -0700 Message-ID: <42792C10.8000408@cisco.com> Date: Wed, 04 May 2005 22:09:52 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Fleischman, Eric" Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK References: <474EEBD229DF754FB83D256004D021080EC283@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <474EEBD229DF754FB83D256004D021080EC283@XCH-NW-6V1.nw.nos.boeing.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115236804.927632"; x:"432200"; a:"rsa-sha1"; b:"nofws:378"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"PeVO8AM18kiN3ER6RfJalkym3H39BVNfJhZoX7jlzGog66R1syd0JAmIn/hG5S2Ifx+AFMoA" "8QApEzUBo6tuZnPbpthajNb+wCnb4y1r0ybrYK2JeekqXcyubGERY/9C+Dxz02DWpcjiFBNHBa1" "kNbMchEg7ihtPPaTGwoALSnw="; c:"Date: Wed, 04 May 2005 22:09:52 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture i" "s EK" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Eric, > I suggest that we accept the result and move on. > > I recommend this because they are still fighting over my home state's > (Washington State) most recent governor election in the courts, since it > seems like a great many criminals and dead people voted in our last > election. Aside from the fact that it violates the spirit of our own rules, our protocol choice may well outlast your governor and successors. Beyond this, see my other message. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 16:30:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQVa-0007DE-B5; Wed, 04 May 2005 16:30:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQVZ-0007D9-Bc for isms@megatron.ietf.org; Wed, 04 May 2005 16:30:13 -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 QAA01935 for ; Wed, 4 May 2005 16:30:11 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTQji-0005Fw-5G for isms@ietf.org; Wed, 04 May 2005 16:44:51 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 351F4E0063; Wed, 4 May 2005 16:29:35 -0400 (EDT) To: Eliot Lear Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK References: <200505041904.j44J4U1E003489@ginger.cmf.nrl.navy.mil> <42792B77.8020005@cisco.com> From: Sam Hartman Date: Wed, 04 May 2005 16:29:35 -0400 In-Reply-To: <42792B77.8020005@cisco.com> (Eliot Lear's message of "Wed, 04 May 2005 22:07:19 +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: 856eb5f76e7a34990d1d457d8e8e5b7f 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'm very interested in concrete suggestions on how to make forward progress. If you think we don't have consensus, what would you do instead? Be specific. I don't have any good answers myself so I'm quite interested in your input. It is important to me that we have well bounded time for anything we propose. In particular I do not wish to be in the position of continually extending deadlines missing them and then extending them again without a clear understanding of why extending the deadline this time will be different than the previous time. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 16:53:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQsY-0006VT-Re; Wed, 04 May 2005 16:53:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQsW-0006Ug-7O for isms@megatron.ietf.org; Wed, 04 May 2005 16:53: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 QAA04226 for ; Wed, 4 May 2005 16:53:53 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTR6f-0005yn-1t for isms@ietf.org; Wed, 04 May 2005 17:08:34 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id DF93AE0063; Wed, 4 May 2005 16:53:53 -0400 (EDT) To: Eliot Lear Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK References: <474EEBD229DF754FB83D256004D021080EC283@XCH-NW-6V1.nw.nos.boeing.com> <42792C10.8000408@cisco.com> From: Sam Hartman Date: Wed, 04 May 2005 16:53:53 -0400 In-Reply-To: <42792C10.8000408@cisco.com> (Eliot Lear's message of "Wed, 04 May 2005 22:09: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: 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 >>>>> "Eliot" == Eliot Lear writes: Eliot> Eric, >> I suggest that we accept the result and move on. I recommend >> this because they are still fighting over my home state's >> (Washington State) most recent governor election in the courts, >> since it seems like a great many criminals and dead people >> voted in our last election. Eliot> Aside from the fact that it violates the spirit of our own Eliot> rules, our protocol choice may well outlast your governor Eliot> and successors. Beyond this, see my other message. I'd like to speak to a point of process. Sometimes it is far more important to make a decision (no matter what it is) than to make a particular decision. This can be particularly true when several options are very close. The working group may have several acceptable options--options for which there is no rough consensus that choosing the option would be a bad idea. The working group may have a strong consensus that a decision of some kind is important. In such a case it is reasonable for the consensus to make a particular decision to be very rough--possibly even coinflip rough. The strong consensus to make some decision reduces the strength of the consensus required for any particular acceptable option. (As a side note, I've actually been in a working group where a coin flip was used to make a consensus call. A decision was required and no one in the room or on the list cared what the outcome was.) A similar situation is also possible. There are several close options. There may not be agreement that a decision is required or there may not be sufficient consensus that the options are in fact acceptable. In this instance the requirements for consensus for some specific decision are stronger than the previous case. So, even from a spirit of process standpoint a very rough consensus may be OK in some situations and quite problematic in others. It all depends on what the working group needs and on the consensus of the working group about the tradeoff between having a decision vs having the right decision. It was my intent when writing this message to be completely neutral on the question of which situation we're in now. Currently that is the chairs' call not mine. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 18:41:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTSYk-0002nn-GC; Wed, 04 May 2005 18:41:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTSYj-0002ni-RX for isms@megatron.ietf.org; Wed, 04 May 2005 18:41:37 -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 SAA20003 for ; Wed, 4 May 2005 18:41:34 -0400 (EDT) Message-Id: <200505042241.SAA20003@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTSmu-000335-OM for isms@ietf.org; Wed, 04 May 2005 18:56:17 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <200505042241200150007ncue>; Wed, 4 May 2005 22:41:20 +0000 From: "David B Harrington" To: "'Sam Hartman'" , "'Eliot Lear'" Subject: RE: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Date: Wed, 4 May 2005 18:41:13 -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: AcVQ63iNBzY6VmN0RF+YsiB/NDpDmAACN5AQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I am firmly in the camp that some decision must be made. It appears that each of the proposals and architectures have good and bad points, so any of the solutions will require work to reach compromises. Not making a decision means not starting the work, which leaves us with USM only, and operarors have ineicated that is an unacceptable solution. 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, May 04, 2005 4:54 PM > To: Eliot Lear > Cc: isms@ietf.org > Subject: Re: [Isms] Rough Consensus Declaration: ISMS > Architecture is EK > > >>>>> "Eliot" == Eliot Lear writes: > > Eliot> Eric, > > >> I suggest that we accept the result and move on. I recommend > >> this because they are still fighting over my home state's > >> (Washington State) most recent governor election in the courts, > >> since it seems like a great many criminals and dead people > >> voted in our last election. > > Eliot> Aside from the fact that it violates the spirit of our own > Eliot> rules, our protocol choice may well outlast your governor > Eliot> and successors. Beyond this, see my other message. > > > I'd like to speak to a point of process. Sometimes it is far more > important to make a decision (no matter what it is) than to make a > particular decision. This can be particularly true when several > options are very close. The working group may have several acceptable > options--options for which there is no rough consensus that choosing > the option would be a bad idea. The working group may have a strong > consensus that a decision of some kind is important. > > In such a case it is reasonable for the consensus to make a particular > decision to be very rough--possibly even coinflip rough. The strong > consensus to make some decision reduces the strength of the consensus > required for any particular acceptable option. (As a side note, I've > actually been in a working group where a coin flip was used to make a > consensus call. A decision was required and no one in the room or on > the list cared what the outcome was.) > > > A similar situation is also possible. There are several close > options. There may not be agreement that a decision is required or > there may not be sufficient consensus that the options are in fact > acceptable. In this instance the requirements for consensus for some > specific decision are stronger than the previous case. > > So, even from a spirit of process standpoint a very rough consensus > may be OK in some situations and quite problematic in others. It all > depends on what the working group needs and on the consensus of the > working group about the tradeoff between having a decision vs having > the right decision. > > It was my intent when writing this message to be completely neutral on > the question of which situation we're in now. Currently that is the > chairs' call not mine. > > --Sam > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 20:14:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTU0C-0007Ap-HI; Wed, 04 May 2005 20:14:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTU0B-0007Ad-7Y for isms@megatron.ietf.org; Wed, 04 May 2005 20:14: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 UAA29515 for ; Wed, 4 May 2005 20:14:01 -0400 (EDT) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTUEL-0006tz-G6 for isms@ietf.org; Wed, 04 May 2005 20:28:42 -0400 Received: from h-68-165-5-123.snvacaid.dynamic.covad.net ([68.165.5.123] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DTU02-0005Zf-00 for isms@ietf.org; Wed, 04 May 2005 17:13:54 -0700 Message-ID: <000801c55107$a1543b00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200505042241.SAA20003@ietf.org> Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Date: Wed, 4 May 2005 17:15:34 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: "'Sam Hartman'" ; "'Eliot Lear'" > Cc: > Sent: Wednesday, May 04, 2005 3:41 PM > Subject: RE: [Isms] Rough Consensus Declaration: ISMS Architecture is EK > > I am firmly in the camp that some decision must be made. It appears > that each of the proposals and architectures have good and bad points, > so any of the solutions will require work to reach compromises. ... I agree. The evaluation process brought me to the same conclusion, and the subsequent discussion on this mailing list has not led me to change my mind. The co-chairs have chosen a direction based on the expressed preferences of the WG, so let's stop second-guessing and see how we can make it work. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 04 22:48:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTWPP-00075i-96; Wed, 04 May 2005 22:48:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTWPN-00073v-Ki for isms@megatron.ietf.org; Wed, 04 May 2005 22:48:13 -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 WAA12388 for ; Wed, 4 May 2005 22:48:10 -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 1DTWdX-0004xA-Fj for isms@ietf.org; Wed, 04 May 2005 23:02:52 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 23CE711D939; Wed, 4 May 2005 19:47:57 -0700 (PDT) From: Wes Hardaker To: Ken Hornstein Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Organization: Sparta References: <200505041621.j44GLisV029505@ginger.cmf.nrl.navy.mil> <20050504200845.GB388@boskop.local> Date: Wed, 04 May 2005 19:47:55 -0700 In-Reply-To: <20050504200845.GB388@boskop.local> (Juergen Schoenwaelder's message of "Wed, 4 May 2005 22:08:45 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Wed, 4 May 2005 22:08:45 +0200, Juergen Schoenwaelder said: >> Having now settled on a path forward, is there alternative proposals >> aside from DTLS to consider? Certainly DTLS is a framework and we'll >> likely need instantiations of that framework for individual >> technologies (TLS, SSH, DTLS, ...). Or are there people that have >> alternative proposals to how DTLS itself is defining the solution space? Juergen> Did you mean s/DTLS/TLSM/g ? Yes, minus the third one which was correct. Sorry about that. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 02:24:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTZn3-0007xc-0E; Thu, 05 May 2005 02:24:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTZn0-0007tx-N1 for isms@megatron.ietf.org; Thu, 05 May 2005 02:24:50 -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 CAA22689 for ; Thu, 5 May 2005 02:24:49 -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 1DTa1D-0007x8-Nr for isms@ietf.org; Thu, 05 May 2005 02:39:34 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 04 May 2005 23:24:39 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j456OYER009859; Wed, 4 May 2005 23:24:34 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp119.cisco.com [10.61.64.119]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j456EfGQ024479; Wed, 4 May 2005 23:14:42 -0700 Message-ID: <4279BC1F.60809@cisco.com> Date: Thu, 05 May 2005 08:24:31 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK References: <200505041904.j44J4U1E003489@ginger.cmf.nrl.navy.mil> <42792B77.8020005@cisco.com> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115273685.118292"; x:"432200"; a:"rsa-sha1"; b:"nofws:555"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"GSzOyTLCtv2VoEWWXZBx0lPusenOZ7DI1VMu7f69yVygVlFQhnqQQhxSJ6Z2s4Ddv7FFuGAk" "WYGOw0L/OheyUtvORo9fLNsoVTVGjnUGKPkfSNZGLXExMbUmD5Jc1JDeugfVgZ2m3n5BIioTVMQ" "IlDIxPlCb69lA86CbZxddWu4="; c:"Date: Thu, 05 May 2005 08:24:31 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture i" "s EK" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Sam, You think *any* decision is a good decision. I think that's only reasonable if and only if the implementors have bought into that and the decisions are roughly technically equivalent. You need consensus on this point. Otherwise you end up precisely with the IMPP mess because people walk away from the table. As to timelines, you owe us some slack, having thrown the group into turmoil just before MSP. I'm not saying you had no cause, nor am I asking for years, but holding The Sword of Damocles over our heads at this point is premature, and risks repeating technical mistakes you were attempting to correct simply because people are making *any* decision. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 08:07:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTf8Q-0006Vk-Ho; Thu, 05 May 2005 08:07:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTf8P-0006Un-Tw for isms@megatron.ietf.org; Thu, 05 May 2005 08:07:17 -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 IAA18451 for ; Thu, 5 May 2005 08:07:16 -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 1DTfMh-0006bd-2p for isms@ietf.org; Thu, 05 May 2005 08:22:04 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 26188E0063; Thu, 5 May 2005 08:07:16 -0400 (EDT) To: Eliot Lear Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK References: <200505041904.j44J4U1E003489@ginger.cmf.nrl.navy.mil> <42792B77.8020005@cisco.com> <4279BC1F.60809@cisco.com> From: Sam Hartman Date: Thu, 05 May 2005 08:07:16 -0400 In-Reply-To: <4279BC1F.60809@cisco.com> (Eliot Lear's message of "Thu, 05 May 2005 08:24:31 +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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Eliot" == Eliot Lear writes: Eliot> Sam, You think *any* decision is a good decision. I think Eliot> that's only reasonable if and only if the implementors have Eliot> bought into that and the decisions are roughly technically Eliot> equivalent. You need consensus on this point. Otherwise Eliot> you end up precisely with the IMPP mess because people walk Eliot> away from the table. No, I actually think I agree with your statement 100%. If the working group has bought into the idea that making a decision (no matter what it is) is sufficiently important then it is reasonable to make a decision even given a very rough consensus. If the working group has not bought into the idea that a decision is sufficiently important then we do not have consensus. I have tried not to state an opinion (or really to form one to the extent that I can avoid doing so) on whether the working group has bought into the idea that a decision of any kind is sufficiently important. Judging that consensus is the job of the chairs and unless required to do so it would be inappropriate for me to second guess the chairs. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 08:11:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTfCw-0007aT-RG; Thu, 05 May 2005 08:11:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTfCu-0007aI-Un for isms@megatron.ietf.org; Thu, 05 May 2005 08: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 IAA18747 for ; Thu, 5 May 2005 08:11:55 -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 1DTfRD-0006px-1z for isms@ietf.org; Thu, 05 May 2005 08:26:43 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7FB86E0063; Thu, 5 May 2005 08:11:57 -0400 (EDT) To: isms@ietf.org From: Sam Hartman Date: Thu, 05 May 2005 08:11:57 -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: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Subject: [Isms] Thoughts on Encapsulation 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 The following thoughts are presented as an individual. I'm trying to give a background on all the sorts of things you could do with encapsulation for SNMP. I may miss some things and I may over simplify things. So there are several different security technologies you might want to support. I'd argue that you probably want to support more than one. 1) TLS/SASL. The combination of TLS and SASL go well together. You typically use one or both. In one common mode, TLS is used to authenticate the server (responder) to the client. The server has a cert and the client does not. You then use SASL to authenticate the client to the server. TLS is used to protect the session. Another common mode supported by the TLS+SASL option only involves SASL. You use a SASL security layer that provides mutual authentication to provide both data confidentiality and integrity to the session and to authenticate both parties. This SASL-only mode is used by Kerberos. A third mode involves only TLS. Both the client and server have certificates. This actually often looks like the first mode because the SASL external mechanism is used to signal that TLS has provided the client authentication. 2) Ssh. This provides for authentication using public keys, Kerberos and passwords among other options. I'd look at the netconf over ssh document as a starting point for how to do this. 3) DTLS. DTLS is probably going to be important because it provides UDP support. The catch with DTLS is going to be figuring out how to authenticate the client to the server if the client doesn't have credentials. You could use SASL while not supporting security layers but doing so will make the Kerberos camp quite unhappy. I'd also recommend trying to treat notifications as no different than any other message. Try two approaches and see which works out best. The first is to try using the existing security context for notifications. The second is to try treating notifications as their own security context; most of the mechanisms discussed work if you let the notifier be the client/initiator. The party receiving notifications will need credentials but that's actually probably OK. Here are some things I'd recommend against. Note that these recommendations are not things that would cause me to reject a solution so much as things that would cause me as an individual to have a bunch of questions about why you were taking that approach. 1) Supporting TLS and SASL without supporting all three modes as described above. 2) Using ssh keys but not ssh. 3) Assuming that SASL can be used in a datagram-like manner without ordering and reliable delivery. 4) Using Kerberos directly (*) 5) Using/recommending the Kerberos TLS ciphersuites. The Kerberos ssh support is fine though. 6) Using raw public-key operations. 7) Extracting the session key from a SASL mechanism. That's just not supported by SASL implementations. (*) It may be that SASL is not good enough for the datagram case and thus you may want to provide for future extension to GSS. That might look a lot to some like raw Kerberos; it certainly would be complicated. I'm a bit concerned that UDP support is going to end up complicated. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 09:26:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTgNP-0002hz-Fm; Thu, 05 May 2005 09:26:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTgNO-0002ht-J5 for isms@megatron.ietf.org; Thu, 05 May 2005 09:26:50 -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 JAA25229 for ; Thu, 5 May 2005 09:26:48 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTgbh-0001z0-74 for isms@ietf.org; Thu, 05 May 2005 09:41:37 -0400 Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j45DQUY06361 for ; Thu, 5 May 2005 09:26:30 -0400 (EDT) Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61]) by zcars2ky.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j45DQl714504 for ; Thu, 5 May 2005 09:26:47 -0400 (EDT) Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 May 2005 09:26:29 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40348F1AA@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: isms@ietf.org Subject: RE: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Date: Thu, 5 May 2005 09:26:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org hi I think most people recognize that the most likely alternative to accepting the selected architecture is for the working group to continue to thrash until it eventually gets shut down. Most people don't want that and from what I have seen so far on the mailing list are generally interested in making progress on our selected path. Sharon -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Sam Hartman Sent: Thursday, May 05, 2005 8:07 AM To: Eliot Lear Cc: isms@ietf.org Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK >>>>> "Eliot" == Eliot Lear writes: Eliot> Sam, You think *any* decision is a good decision. I think Eliot> that's only reasonable if and only if the implementors have Eliot> bought into that and the decisions are roughly technically Eliot> equivalent. You need consensus on this point. Otherwise Eliot> you end up precisely with the IMPP mess because people walk Eliot> away from the table. No, I actually think I agree with your statement 100%. If the working group has bought into the idea that making a decision (no matter what it is) is sufficiently important then it is reasonable to make a decision even given a very rough consensus. If the working group has not bought into the idea that a decision is sufficiently important then we do not have consensus. I have tried not to state an opinion (or really to form one to the extent that I can avoid doing so) on whether the working group has bought into the idea that a decision of any kind is sufficiently important. Judging that consensus is the job of the chairs and unless required to do so it would be inappropriate for me to second guess the chairs. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 09:45:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTgfq-0007PM-T9; Thu, 05 May 2005 09:45:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTgfp-0007PD-Aw for isms@megatron.ietf.org; Thu, 05 May 2005 09:45:53 -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 JAA27658 for ; Thu, 5 May 2005 09:45:51 -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 1DTgu7-0002vk-Pb for isms@ietf.org; Thu, 05 May 2005 10:00:40 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 May 2005 06:45:43 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j45DjbER011826; Thu, 5 May 2005 06:45:38 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp55.cisco.com [10.61.64.55]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j45DZjMu026503; Thu, 5 May 2005 06:35:46 -0700 Message-ID: <427A2381.5030602@cisco.com> Date: Thu, 05 May 2005 15:45:37 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman Subject: Re: [Isms] Thoughts on Encapsulation References: In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115300147.397350"; x:"432200"; a:"rsa-sha1"; b:"nofws:3385"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"ZzlwgBgKk6PFXSi62AR5Q/UV9ItcXwgo3PsZr3sLvRnwGjd/zsg4JYB9Gk9zPF0xf6J4+2PR" "aWP+EmncIW0TOdUD/XCwO0voSuF+ueonz3RbE6Euvkla85HodtmNUi0dnRZMG+QwqVgm/U+rqU0" "G6qBjqybkEeWS3e1xCXumbQ4="; c:"Date: Thu, 05 May 2005 15:45:37 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] Thoughts on Encapsulation" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Sam, Reading your message and that of others, I have a question for the group as to whether EK implies that the entire SNMP packet will be encapsulated or whether a very simple SASL/TLS dance is done to generate a session key used in a packet that looks just like USM/UDP? There are benefits to either. Encapsulating gets you through firewalls more easily (and some people view this as a drawback), while costs you something in performance. Doing the key dance costs you almost nothing in additional performance but may add some administration complexity given that there are now two connections needed to maintain SNMP connectivity. Eliot Sam Hartman wrote: > The following thoughts are presented as an individual. I'm trying to > give a background on all the sorts of things you could do with > encapsulation for SNMP. I may miss some things and I may over > simplify things. > > > So there are several different security technologies you might want to > support. I'd argue that you probably want to support more than one. > > 1) TLS/SASL. The combination of TLS and SASL go well together. You > typically use one or both. In one common mode, TLS is used to > authenticate the server (responder) to the client. The server has > a cert and the client does not. You then use SASL to authenticate > the client to the server. TLS is used to protect the session. > Another common mode supported by the TLS+SASL option only involves > SASL. You use a SASL security layer that provides mutual > authentication to provide both data confidentiality and integrity > to the session and to authenticate both parties. This SASL-only > mode is used by Kerberos. A third mode involves only TLS. Both > the client and server have certificates. This actually often looks > like the first mode because the SASL external mechanism is used to > signal that TLS has provided the client authentication. > > 2) Ssh. This provides for authentication using public keys, Kerberos > and passwords among other options. I'd look at the netconf over > ssh document as a starting point for how to do this. > > 3) DTLS. DTLS is probably going to be important because it provides > UDP support. The catch with DTLS is going to be figuring out how > to authenticate the client to the server if the client doesn't have > credentials. You could use SASL while not supporting security > layers but doing so will make the Kerberos camp quite unhappy. > > > I'd also recommend trying to treat notifications as no different than > any other message. Try two approaches and see which works out best. > The first is to try using the existing security context for > notifications. The second is to try treating notifications as their > own security context; most of the mechanisms discussed work if you let > the notifier be the client/initiator. The party receiving > notifications will need credentials but that's actually probably OK. > > Here are some things I'd recommend against. Note that these > recommendations are not things that would cause me to reject a > solution so much as things that would cause me as an individual to > have a bunch of questions about why you were taking that approach. > > > 1) Supporting TLS and SASL without supporting all three modes as > described above. > > 2) Using ssh keys but not ssh. > > 3) Assuming that SASL can be used in a datagram-like manner without > ordering and reliable delivery. > > > 4) Using Kerberos directly (*) > > 5) Using/recommending the Kerberos TLS ciphersuites. The Kerberos ssh > support is fine though. > > 6) Using raw public-key operations. > > 7) Extracting the session key from a SASL mechanism. That's just not > supported by SASL implementations. > > (*) It may be that SASL is not good enough for the datagram case and > thus you may want to provide for future extension to GSS. That might > look a lot to some like raw Kerberos; it certainly would be > complicated. I'm a bit concerned that UDP support is going to end up > complicated. > > _______________________________________________ > 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 May 05 10:16:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTh4w-0004B0-3I; Thu, 05 May 2005 10:11:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTh4t-0004Au-Uh for isms@megatron.ietf.org; Thu, 05 May 2005 10:11:48 -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 KAA01142 for ; Thu, 5 May 2005 10:11:45 -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 1DThJC-0004It-0p for isms@ietf.org; Thu, 05 May 2005 10:26:35 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id C0A0411D939; Thu, 5 May 2005 07:11:32 -0700 (PDT) From: Wes Hardaker To: Eliot Lear Subject: Re: [Isms] Thoughts on Encapsulation Organization: Sparta References: <427A2381.5030602@cisco.com> Date: Thu, 05 May 2005 07:11:25 -0700 In-Reply-To: <427A2381.5030602@cisco.com> (Eliot Lear's message of "Thu, 05 May 2005 15:45:37 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 >>>>> On Thu, 05 May 2005 15:45:37 +0200, Eliot Lear said: Eliot> Reading your message and that of others, I have a question for the group Eliot> as to whether EK implies that the entire SNMP packet will be Eliot> encapsulated or whether a very simple SASL/TLS dance is done to generate Eliot> a session key used in a packet that looks just like USM/UDP? If that session key is no longer user during the session (IE, you take it and start using SNMPv3/USM directly) then it's OOB not EK isn't 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 Thu May 05 10:21:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DThEd-0005tB-Gu; Thu, 05 May 2005 10:21:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DThEc-0005t2-RR for isms@megatron.ietf.org; Thu, 05 May 2005 10:21:50 -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 KAA02735 for ; Thu, 5 May 2005 10:21:48 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DThSv-0004lE-3v for isms@ietf.org; Thu, 05 May 2005 10:36:38 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 05 May 2005 07:21:24 -0700 X-IronPort-AV: i="3.92,157,1112598000"; d="scan'208"; a="634399931:sNHT1315272426" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j45ELIER003691; Thu, 5 May 2005 07:21:19 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp55.cisco.com [10.61.64.55]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j45EBQFg026721; Thu, 5 May 2005 07:11:27 -0700 Message-ID: <427A2BDE.80308@cisco.com> Date: Thu, 05 May 2005 16:21:18 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wes Hardaker Subject: Re: [Isms] Thoughts on Encapsulation References: <427A2381.5030602@cisco.com> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115302288.95846"; x:"432200"; a:"rsa-sha1"; b:"nofws:322"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"HniWaw4Lh0uyqB/0OWOrxw9CYlP09PPPwE4PhDtC8ybepOjIj7Hg8J+Ha0KRo7YO5DC4OfYw" "sioF4TiJS7AbifrD82djMFbgU68RrjTvkDfE8ogvauZUG7Pbvpj18OnsijEKfGcX73vsDRmBmWB" "QYMEBkgMA46j2kkkAiYdVOCA="; c:"Date: Thu, 05 May 2005 16:21:18 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] Thoughts on Encapsulation" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit 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 Wes Hardaker wrote: > If that session key is no longer user during the session (IE, you take > it and start using SNMPv3/USM directly) then it's OOB not EK isn't it? Heck I don't know. I've been viewing OOB as a three three party exchange, and EK as a two party exchange. Whether it was a single connection or multiple connections between the two parties was a bit of a different question. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 10:31:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DThNk-00077s-Ku; Thu, 05 May 2005 10:31:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DThNi-00077j-Vn for isms@megatron.ietf.org; Thu, 05 May 2005 10:31:15 -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 KAA03546 for ; Thu, 5 May 2005 10:31:12 -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 1DThc1-0005As-BX for isms@ietf.org; Thu, 05 May 2005 10:46:02 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 4510011D939; Thu, 5 May 2005 07:31:10 -0700 (PDT) From: Wes Hardaker To: Eliot Lear Subject: Re: [Isms] Thoughts on Encapsulation Organization: Sparta References: <427A2381.5030602@cisco.com> <427A2BDE.80308@cisco.com> Date: Thu, 05 May 2005 07:31:06 -0700 In-Reply-To: <427A2BDE.80308@cisco.com> (Eliot Lear's message of "Thu, 05 May 2005 16:21:18 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 >>>>> On Thu, 05 May 2005 16:21:18 +0200, Eliot Lear said: Eliot> Heck I don't know. I've been viewing OOB as a three three party Eliot> exchange, and EK as a two party exchange. Whether it was a single Eliot> connection or multiple connections between the two parties was a bit of Eliot> a different question. I don't think OOB has ever said the number of partys involved are 3. IKE, which many people have been considering as a potential OOB solution, is a 2 party exchange much of the time. As is EAP some of the time as well. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 10:37:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DThU4-0008KS-QH; Thu, 05 May 2005 10:37:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DThU3-0008KI-36 for isms@megatron.ietf.org; Thu, 05 May 2005 10:37: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 KAA04060 for ; Thu, 5 May 2005 10:37:44 -0400 (EDT) Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DThiL-0005QQ-7R for isms@ietf.org; Thu, 05 May 2005 10:52:34 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j45EbYdF000921; Thu, 5 May 2005 14:37:34 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j45EbSKW022075; Thu, 5 May 2005 14:37:34 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005050507373329821 ; Thu, 05 May 2005 07:37:33 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 07:37:33 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 07:37:33 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 10:37:32 -0400 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] Thoughts on Encapsulation Date: Thu, 5 May 2005 10:37:03 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C59290115B33F@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Thoughts on Encapsulation Thread-Index: AcVRfIGzgIghShqZSOOsjMBLgOQfEAAAutnA From: "Blumenthal, Uri" To: "Wes Hardaker" , "Eliot Lear" X-OriginalArrivalTime: 05 May 2005 14:37:32.0121 (UTC) FILETIME=[F8779490:01C5517F] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable 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 I for one don't care how exactly you label it.=20 What seems the most straightforward from SNMP point of view is to create a security model tag that would identify the key exchange SNMP packets, and within those packets encapsulate the information necessary to complete the key exchange (utilizing whatever mechanisms, be it GSS, straight Krb, PKI, ...). Once the keys are computed, any [other] security model can be used to protect the negotiated session. Is this so controversial? -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Wes Hardaker Sent: Thursday, May 05, 2005 10:11 AM To: Eliot Lear Cc: Sam Hartman; isms@ietf.org Subject: Re: [Isms] Thoughts on Encapsulation >>>>> On Thu, 05 May 2005 15:45:37 +0200, Eliot Lear said: Eliot> Reading your message and that of others, I have a question for the group=20 Eliot> as to whether EK implies that the entire SNMP packet will be=20 Eliot> encapsulated or whether a very simple SASL/TLS dance is done to generate=20 Eliot> a session key used in a packet that looks just like USM/UDP? If that session key is no longer user during the session (IE, you take it and start using SNMPv3/USM directly) then it's OOB not EK isn't it? --=20 Wes Hardaker Sparta, Inc. _______________________________________________ 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 May 05 10:53:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DThjg-0002ui-Ud; Thu, 05 May 2005 10:53:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DThjg-0002ud-0l for isms@megatron.ietf.org; Thu, 05 May 2005 10:53: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 KAA06070 for ; Thu, 5 May 2005 10:53:53 -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 1DThxy-0006Oz-Eq for isms@ietf.org; Thu, 05 May 2005 11:08:43 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 05 May 2005 07:35:29 -0700 X-IronPort-AV: i="3.92,157,1112598000"; d="scan'208"; a="260058046:sNHT749629418" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j45EZQPo026510; Thu, 5 May 2005 07:35:26 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp55.cisco.com [10.61.64.55]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j45EPWQL026801; Thu, 5 May 2005 07:25:32 -0700 Message-ID: <427A2F2B.7060707@cisco.com> Date: Thu, 05 May 2005 16:35:23 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wes Hardaker Subject: Re: [Isms] Thoughts on Encapsulation References: <427A2381.5030602@cisco.com> <427A2BDE.80308@cisco.com> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115303133.667455"; x:"432200"; a:"rsa-sha1"; b:"nofws:457"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"a0daz1wZJyZqVqqTq8r1fVfauJhG2MVhmD1dCGCHciv8Wdmt/A152Vl6oHIo3/X/6iIzRXUM" "9QedITT+wY76ZBVbAhSqhT4abn2I4XViSoX5ugRw+QzrrGDDf+Bk87qj3iLvpG3iZkQzwLHDb6i" "EhNTO/SeA6PALqifNOwB4uiY="; c:"Date: Thu, 05 May 2005 16:35:23 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] Thoughts on Encapsulation" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit 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 Wes Hardaker wrote: > I don't think OOB has ever said the number of partys involved are 3. > IKE, which many people have been considering as a potential OOB > solution, is a 2 party exchange much of the time. As is EAP some of > the time as well. Not the way it was discussed in the group, tho. The EAP exchange was between agent and radius server, as I understood it. But look, we've gotten away from my basic question. Was what people intended an augmentation to RFC 3417? Put another way, was anyone else pondering other than an augmentation to RFC 3417? Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 11:01:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DThqs-0004pB-Qz; Thu, 05 May 2005 11:01:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DThqr-0004p4-3i for isms@megatron.ietf.org; Thu, 05 May 2005 11:01: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 LAA06768 for ; Thu, 5 May 2005 11:01:18 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTi58-0006hk-Ic for isms@ietf.org; Thu, 05 May 2005 11:16:08 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id LAA27044 for ; Thu, 5 May 2005 11:02:30 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma027003; Thu, 5 May 05 11:01:57 -0400 Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 05 May 2005 11:00:43 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 05 May 2005 11:00:43 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 May 2005 11:00:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Thoughts on Encapsulation Date: Thu, 5 May 2005 11:00:40 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032317@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Thoughts on Encapsulation Thread-Index: AcVRfIGzgIghShqZSOOsjMBLgOQfEAAAutnAAACpWsA= From: "Nelson, David" To: X-OriginalArrivalTime: 05 May 2005 15:00:43.0475 (UTC) FILETIME=[35C75A30:01C55183] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:99.5996 P:95.9108 R:95.9108 S:99.5381 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Uri Blumenthal writes... > What seems the most straightforward from SNMP point of view is to create > a security model tag that would identify the key exchange SNMP packets, > and within those packets encapsulate the information necessary to > complete the key exchange (utilizing whatever mechanisms, be it GSS, > straight Krb, PKI, ...). Once the keys are computed, any [other] > security model can be used to protect the negotiated session. I might be confused in my thinking, but my understanding of the EK architecture is that the encapsulation protocol (e.g. TLS) provides the session context now missing in SNMPv3 USM. We all understand the need to bind the negotiated keys to the session, and for both end-points to have a consistent view of session state. OBK had the problem of needing to create the session context using existing (e.g. USM) protocol features. This is not impossible, of course. So, one advantage of having chosen the EK architecture is that the session context and session-to-key binding already exists. The only disadvantage of EK is that the actual encapsulation is a bit of overhead. I think that having chosen EK, we need to apply the protocol selection in a straightforward fashion. I think that means we need to encapsulate the SNMP data stream. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 11:15:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTi4u-0007Cx-LB; Thu, 05 May 2005 11:15:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTi4s-0007A8-Sk for isms@megatron.ietf.org; Thu, 05 May 2005 11:15: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 LAA08172 for ; Thu, 5 May 2005 11:15:47 -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 1DTiJB-0007QT-6N for isms@ietf.org; Thu, 05 May 2005 11:30:38 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E0A7AE0063; Thu, 5 May 2005 11:15:54 -0400 (EDT) To: "Blumenthal, Uri" Subject: Re: [Isms] Thoughts on Encapsulation References: <3DEC199BD7489643817ECA151F7C59290115B33F@pysmsx401.amr.corp.intel.com> From: Sam Hartman Date: Thu, 05 May 2005 11:15:54 -0400 In-Reply-To: <3DEC199BD7489643817ECA151F7C59290115B33F@pysmsx401.amr.corp.intel.com> (Uri Blumenthal's message of "Thu, 5 May 2005 10:37:03 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 >>>>> "Blumenthal," == Blumenthal, Uri writes: Blumenthal,> I for one don't care how exactly you label it. What Blumenthal,> seems the most straightforward from SNMP point of Blumenthal,> view is to create a security model tag that would Blumenthal,> identify the key exchange SNMP packets, and within Blumenthal,> those packets encapsulate the information necessary Blumenthal,> to complete the key exchange (utilizing whatever Blumenthal,> mechanisms, be it GSS, straight Krb, PKI, ...). Once Blumenthal,> the keys are computed, any [other] security model can Blumenthal,> be used to protect the negotiated session. Blumenthal,> Is this so controversial? No. However I think it is IBK not encapsulation. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 11:34:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTiMX-0001uM-1R; Thu, 05 May 2005 11:34:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTiMV-0001u0-Mu for isms@megatron.ietf.org; Thu, 05 May 2005 11:34: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 LAA10175 for ; Thu, 5 May 2005 11:34:00 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTiao-0008IT-T5 for isms@ietf.org; Thu, 05 May 2005 11:48:51 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id LAA29361 for ; Thu, 5 May 2005 11:35:13 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma029317; Thu, 5 May 05 11:34:18 -0400 Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 05 May 2005 11:33:04 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 05 May 2005 11:33:04 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 May 2005 11:32:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Thoughts on Encapsulation Date: Thu, 5 May 2005 11:32:44 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032318@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Thoughts on Encapsulation Thread-Index: AcVRhVuotantHKa7Q6+1Q3iJp6z2gAAAOsIQ From: "Nelson, David" To: X-OriginalArrivalTime: 05 May 2005 15:32:45.0678 (UTC) FILETIME=[AF8040E0:01C55187] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:85.5827 M:94.5022 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 It seems to me that ISMS using EK is not going to closely fit into the SNMP Security Model architecture as described in RFC 2571. I say that because an encapsulating security layer typically sits below the application, (roughly) in the socket layer. In RFC 2571 we have the Security Model in the middle of the application protocol stack. I would suggest, however, that we either "just get over it", and make progress, or decide that conformity with the RFC 2571 architecture model is of sufficient importance that we need to revisit the EK decision. I'm suggesting that we make the decision to "just get over it" now, because if we wait until the EK protocol selection and ISMS design phase to deal with this conceptual issue, we run the risk of de-railing again. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 11:37:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTiPV-0002jM-JN; Thu, 05 May 2005 11:37:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTiPU-0002jH-Jb for isms@megatron.ietf.org; Thu, 05 May 2005 11:37:08 -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 LAA10718 for ; Thu, 5 May 2005 11:37:05 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTidn-0008Su-CU for isms@ietf.org; Thu, 05 May 2005 11:51:56 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j45FaYdv026927; Thu, 5 May 2005 08:36:35 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j45FaSlA024858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 May 2005 08:36:29 -0700 (PDT) Message-ID: <427A3D7F.4030503@qualcomm.com> Date: Thu, 05 May 2005 11:36:31 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman , kenh@cmf.nrl.navy.mil, quittek@netlab.nec.de References: <3DEC199BD7489643817ECA151F7C59290115B33F@pysmsx401.amr.corp.intel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: [Isms] Definitions of OOBK, EK, IBK X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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, Ken, Juergen, While the WG has reached a consensus (noted that it is still in discussion) on the argument on OOBK vs. EK vs. IBK, we are still seeing confusion over the terminology (I for one am confident that I can describe the ones that I prefer, OOBK and EK, but not quite sure I can articulate all three of them with a side-by-side comparison). Could that be documented please? Please post the definitions, with some notes comparing them (e.g., EK has this property, while OOBK doesn't etc.). I am sure a discussion will follow, but after that please post the "final" definitions of what they are, so we can all have the same thing in mind when we speak/write. thanks, Lakshminath _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 13:14:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjvV-00011I-U6; Thu, 05 May 2005 13:14:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjvU-000118-7D for isms@megatron.ietf.org; Thu, 05 May 2005 13:14:16 -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 NAA20358 for ; Thu, 5 May 2005 13:14:12 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTk9n-00052B-Qc for isms@ietf.org; Thu, 05 May 2005 13:29:05 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 99D06E0063; Thu, 5 May 2005 13:14:15 -0400 (EDT) To: "Nelson, David" Subject: Re: [Isms] Thoughts on Encapsulation References: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032318@MAANDMBX2.ets.enterasys.com> From: Sam Hartman Date: Thu, 05 May 2005 13:14:15 -0400 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032318@MAANDMBX2.ets.enterasys.com> (David Nelson's message of "Thu, 5 May 2005 11:32:44 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 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 >>>>> "Nelson," == Nelson, David writes: Nelson,> It seems to me that ISMS using EK is not going to closely Nelson,> fit into the SNMP Security Model architecture as Nelson,> described in RFC 2571. I say that because an Nelson,> encapsulating security layer typically sits below the Nelson,> application, (roughly) in the socket layer. In RFC 2571 Nelson,> we have the Security Model in the middle of the Nelson,> application protocol stack. I'd recommend a solution like SASL external. You add a new layer on top of SNMP that does the encapsulation and then add a security model that says you are using encapsulation. If that security model is used in a case where encapsulation is not actually happening then the message fails the security model. So, yes there is a new layer but you also remain consistent with (or nearly consistent with) the security model document --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 13:34:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTkFP-0005SX-1J; Thu, 05 May 2005 13:34:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTkFO-0005SS-5e for isms@megatron.ietf.org; Thu, 05 May 2005 13:34:50 -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 NAA22085 for ; Thu, 5 May 2005 13:34:46 -0400 (EDT) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTkTh-00061o-Te for isms@ietf.org; Thu, 05 May 2005 13:49:39 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j45HYXeA016472; Thu, 5 May 2005 17:34:33 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j45HYCZE025859; Thu, 5 May 2005 17:34:33 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005050510343320009 ; Thu, 05 May 2005 10:34:33 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 10:34:33 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 10:34:32 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 13:34:31 -0400 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] Thoughts on Encapsulation Date: Thu, 5 May 2005 13:34:02 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C59290115B55B@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Thoughts on Encapsulation Thread-Index: AcVRlhEwpJtdriVATcS1RmKvMpGyBQAAi0hQ From: "Blumenthal, Uri" To: "Sam Hartman" , "Nelson, David" X-OriginalArrivalTime: 05 May 2005 17:34:31.0189 (UTC) FILETIME=[B1ECC450:01C55198] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 How would an SNMP engine figure out whether the arriving SNMPv3 packet tagged "encapsulated security model" actually WAS encapsulated? According to SNMPv3 architecture, security is part of SNMP engine. In case of external encapsulation, only the external application might know whether encapsulation/tunneling was set up or not.=20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Sam Hartman Sent: Thursday, May 05, 2005 1:14 PM To: Nelson, David Cc: isms@ietf.org Subject: Re: [Isms] Thoughts on Encapsulation >>>>> "Nelson," =3D=3D Nelson, David writes: Nelson,> It seems to me that ISMS using EK is not going to closely Nelson,> fit into the SNMP Security Model architecture as Nelson,> described in RFC 2571. I say that because an Nelson,> encapsulating security layer typically sits below the Nelson,> application, (roughly) in the socket layer. In RFC 2571 Nelson,> we have the Security Model in the middle of the Nelson,> application protocol stack. I'd recommend a solution like SASL external. You add a new layer on top of SNMP that does the encapsulation and then add a security model that says you are using encapsulation. If that security model is used in a case where encapsulation is not actually happening then the message fails the security model. So, yes there is a new layer but you also remain consistent with (or nearly consistent with) the security model document --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 13:57:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTkbb-0001sO-6v; Thu, 05 May 2005 13:57:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTkba-0001sJ-7E for isms@megatron.ietf.org; Thu, 05 May 2005 13:57: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 NAA24377 for ; Thu, 5 May 2005 13:57:44 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTkpi-000716-2d for isms@ietf.org; Thu, 05 May 2005 14:12:23 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 5D75CE0063; Thu, 5 May 2005 13:57:33 -0400 (EDT) To: "Blumenthal, Uri" Subject: Re: [Isms] Thoughts on Encapsulation References: <3DEC199BD7489643817ECA151F7C59290115B55B@pysmsx401.amr.corp.intel.com> From: Sam Hartman Date: Thu, 05 May 2005 13:57:33 -0400 In-Reply-To: <3DEC199BD7489643817ECA151F7C59290115B55B@pysmsx401.amr.corp.intel.com> (Uri Blumenthal's message of "Thu, 5 May 2005 13:34:02 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: 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 >>>>> "Blumenthal," == Blumenthal, Uri writes: Blumenthal,> How would an SNMP engine figure out whether the Blumenthal,> arriving SNMPv3 packet tagged "encapsulated security Blumenthal,> model" actually WAS encapsulated? Blumenthal,> According to SNMPv3 architecture, security is part of Blumenthal,> SNMP engine. In case of external encapsulation, only Blumenthal,> the external application might know whether Blumenthal,> encapsulation/tunneling was set up or not. IT would need to know that somehow. Why is this harder for SNMP than for IMAP or LDAP? In those cases it is either part of the same process and state is maintained or there is some sort of implementation-specific communications that conveys security encapsulation information. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 13:59:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTkdI-0002N5-QU; Thu, 05 May 2005 13:59:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTkdH-0002Kc-F8 for isms@megatron.ietf.org; Thu, 05 May 2005 13:59: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 NAA24556 for ; Thu, 5 May 2005 13:59:29 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTkrb-00078n-I0 for isms@ietf.org; Thu, 05 May 2005 14:14:20 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 05 May 2005 10:59:21 -0700 Received: from kaushik-w2k03.cisco.com ([171.69.75.179]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j45HxGnD009434; Thu, 5 May 2005 10:59:19 -0700 (PDT) Message-Id: <6.2.0.14.0.20050505105620.039262a8@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 05 May 2005 10:59:11 -0700 To: "Nelson, David" From: Kaushik Narayan Subject: RE: [Isms] Thoughts on Encapsulation In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032318@MAANDMBX2.ets.ent erasys.com> References: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032318@MAANDMBX2.ets.enterasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [171.69.75.179] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi All, The use of TLS to encapsulate all SNMP packets would mean that we had an architecture discussion on keying approaches and the result would be a new transport specification for SNMP. The current SNMP specification provides the option to use SNMPoUDP and SNMPoTCP, the choice of TLS as a transport will definitely have performance implications for SNMPoUDP applications that will probably undermine the reason for these applications to use UDP in the first place. regards, kaushik! At 08:32 AM 5/5/2005, Nelson, David wrote: >It seems to me that ISMS using EK is not going to closely fit into the >SNMP Security Model architecture as described in RFC 2571. I say that >because an encapsulating security layer typically sits below the >application, (roughly) in the socket layer. In RFC 2571 we have the >Security Model in the middle of the application protocol stack. > >I would suggest, however, that we either "just get over it", and make >progress, or decide that conformity with the RFC 2571 architecture model >is of sufficient importance that we need to revisit the EK decision. > >I'm suggesting that we make the decision to "just get over it" now, >because if we wait until the EK protocol selection and ISMS design phase >to deal with this conceptual issue, we run the risk of de-railing again. > > >_______________________________________________ >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 May 05 14:02:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTkg1-0002nK-Ps; Thu, 05 May 2005 14:02:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTkg0-0002nF-2q for isms@megatron.ietf.org; Thu, 05 May 2005 14:02: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 OAA24823 for ; Thu, 5 May 2005 14:02:18 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTkuL-0007H0-9u for isms@ietf.org; Thu, 05 May 2005 14:17:09 -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 j45I25ja010305 for ; Thu, 5 May 2005 14:02:05 -0400 (EDT) Message-Id: <200505051802.j45I25ja010305@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK In-Reply-To: <4279BC1F.60809@cisco.com> 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, 05 May 2005 14:02:07 -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: e5ba305d0e64821bf3d8bc5d3bb07228 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 >You think *any* decision is a good decision. I think that's only >reasonable if and only if the implementors have bought into that and the >decisions are roughly technically equivalent. You need consensus on >this point. Otherwise you end up precisely with the IMPP mess because >people walk away from the table. In fairness, we (the WG chairs) should have made this clearer. We had assumed that by this point, people wanted a decision made and that since (in our opinion) the more recent discussions hadn't really brought anything new to the table, further discussion wasn't going to help. I guess implied in our call for consensus was the idea that we were going to have to make a decision for one of the architectures, but that was not explicitly spelled out. So, to all WG participants: do you feel that we have to make _some_ decision on an architecture at this point? If not, do you think more discussion is useful? If you don't, do you have any suggestions as to how we should reach consensus? Or do you think we should declare no consensus and shut down? Specifically, if you're not happy with how things turned out, we need to hear from you! (I know we've already heard from a few WG participants on this subject; you don't need to resend your email). As a WG member ... I think that the discussions that we've had to date has shown me that people approach SNMP security with very different assumptions and needs and I doubt further discussion will result in anything useful. I do want the WG to go forward, so I feel that any decision at this point is what we need. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 14:07:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTklH-0004M7-FN; Thu, 05 May 2005 14:07:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTklG-0004M2-4O for isms@megatron.ietf.org; Thu, 05 May 2005 14:07: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 OAA25216 for ; Thu, 5 May 2005 14:07:44 -0400 (EDT) Received: from fmr16.intel.com ([192.55.52.70] helo=fmsfmr006.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTkza-0007XD-RS for isms@ietf.org; Thu, 05 May 2005 14:22:35 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j45I7TDZ013193; Thu, 5 May 2005 18:07:29 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j45I7KZ9008679; Thu, 5 May 2005 18:07:29 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005050511072923241 ; Thu, 05 May 2005 11:07:29 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 11:07:29 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 11:07:28 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 14:07:27 -0400 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] Thoughts on Encapsulation Date: Thu, 5 May 2005 14:06:59 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929011958BB@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Thoughts on Encapsulation Thread-Index: AcVRnEJ4Zngk+OXbTk2Egk0XQseH9wAAOOAw From: "Blumenthal, Uri" To: "Kaushik Narayan" , "Nelson, David" X-OriginalArrivalTime: 05 May 2005 18:07:27.0539 (UTC) FILETIME=[4BEBD830:01C5519D] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Perhaps this is the simplest: new transport SNMPoDTLS.=20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Kaushik Narayan Sent: Thursday, May 05, 2005 1:59 PM To: Nelson, David Cc: isms@ietf.org Subject: RE: [Isms] Thoughts on Encapsulation Hi All, The use of TLS to encapsulate all SNMP packets would mean that we had an architecture discussion on keying approaches and the result would be a new transport specification for SNMP. The current SNMP specification provides the option to use SNMPoUDP and SNMPoTCP, the choice of TLS as a transport will definitely have performance implications for SNMPoUDP applications that will probably undermine the reason for these applications to use UDP in the first place. regards, kaushik! At 08:32 AM 5/5/2005, Nelson, David wrote: >It seems to me that ISMS using EK is not going to closely fit into the >SNMP Security Model architecture as described in RFC 2571. I say that >because an encapsulating security layer typically sits below the >application, (roughly) in the socket layer. In RFC 2571 we have the >Security Model in the middle of the application protocol stack. > >I would suggest, however, that we either "just get over it", and make >progress, or decide that conformity with the RFC 2571 architecture model >is of sufficient importance that we need to revisit the EK decision. > >I'm suggesting that we make the decision to "just get over it" now, >because if we wait until the EK protocol selection and ISMS design phase >to deal with this conceptual issue, we run the risk of de-railing again. > > >_______________________________________________ >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 May 05 14:40:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTlH5-0003b3-51; Thu, 05 May 2005 14:40:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTlH3-0003ay-1J for isms@megatron.ietf.org; Thu, 05 May 2005 14:40:37 -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 OAA28581 for ; Thu, 5 May 2005 14:40:35 -0400 (EDT) Received: from moby.atcorp.com ([204.72.172.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTlVN-0000hS-Hs for isms@ietf.org; Thu, 05 May 2005 14:55:26 -0400 Received: from localhost ([127.0.0.1] helo=STRIPER ident=root) by moby.atcorp.com with asmtp (Exim 3.35 #1 (Debian)) id 1DTlGs-0003JR-00; Thu, 05 May 2005 13:40:26 -0500 From: "Wayne Kading" To: "'Ken Hornstein'" Subject: RE: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Date: Thu, 5 May 2005 13:40:25 -0500 Organization: ATC Message-ID: <002701c551a1$e72d0900$84aca8c0@STRIPER> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200505051802.j45I25ja010305@ginger.cmf.nrl.navy.mil> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Ken, My personal view is that the ISMS keying can be accomplished with any of = the three architecture choices and that it is more important to move ahead = with the decision which was made by the WG chairs. I also don't believe that refining the count or prolonging the voting or evaluation will = substantially change my view. However, I did notice a subtle error in your rough consensus summary. There were 8 (vs 7) Maybe votes for EK which would increase the For votes for EK to 15. Wayne -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] = On Behalf Of Ken Hornstein Sent: Thursday, May 05, 2005 1:02 PM To: isms@ietf.org Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK = >You think *any* decision is a good decision. I think that's only=20 >reasonable if and only if the implementors have bought into that and = the=20 >decisions are roughly technically equivalent. You need consensus on=20 >this point. Otherwise you end up precisely with the IMPP mess because=20 >people walk away from the table. In fairness, we (the WG chairs) should have made this clearer. We had assumed that by this point, people wanted a decision made and that since (in our opinion) the more recent discussions hadn't really brought anything new to the table, further discussion wasn't going to help. I guess implied in our call for consensus was the idea that we were going to have to make a decision for one of the architectures, but that was not explicitly spelled out. So, to all WG participants: do you feel that we have to make _some_ decision on an architecture at this point? If not, do you think more discussion is useful? If you don't, do you have any suggestions as to how we should reach consensus? Or do you think we should declare no consensus and shut down? Specifically, if you're not happy with how things turned out, we need to hear from you! (I know we've already heard from a few WG participants on this subject; you don't need to resend your email). As a WG member ... I think that the discussions that we've had to date has shown me that people approach SNMP security with very different assumptions and needs and I doubt further discussion will result in anything useful. I do want the WG to go forward, so I feel that any decision at this point is what we need. --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 From isms-bounces@lists.ietf.org Thu May 05 14:50:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTlQ8-0005Wo-5S; Thu, 05 May 2005 14:50:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTlQ6-0005Wj-Rk for isms@megatron.ietf.org; Thu, 05 May 2005 14:49:58 -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 OAA29185 for ; Thu, 5 May 2005 14:49:56 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTleQ-00019a-Hu for isms@ietf.org; Thu, 05 May 2005 15:04:48 -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 j45InVVd011473 for ; Thu, 5 May 2005 14:49:44 -0400 (EDT) Message-Id: <200505051849.j45InVVd011473@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK In-Reply-To: <002701c551a1$e72d0900$84aca8c0@STRIPER> 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, 05 May 2005 14:49:34 -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: 79899194edc4f33a41f49410777972f8 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 >My personal view is that the ISMS keying can be accomplished with any of the >three architecture choices and that it is more important to move ahead with >the decision which was made by the WG chairs. I also don't believe that >refining the count or prolonging the voting or evaluation will substantially >change my view. However, I did notice a subtle error in your rough >consensus summary. There were 8 (vs 7) Maybe votes for EK which would >increase the For votes for EK to 15. That's definately true; someone else brought that to my attention. If you add up the missed "preferences" (I hate using the word "votes") that people brought up on the mailing list (Lakshminath and Khanh), I get: 14 Yes, 6 No for OOBK 13 Yes, 5 No for IBK 17 Yes, 4 No for EK Which pushes things sligher more toward EK, but again, it's still pretty close. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 16:17:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTmmJ-0005yA-VA; Thu, 05 May 2005 16:16:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTmmI-0005y4-I2 for isms@megatron.ietf.org; Thu, 05 May 2005 16:16:58 -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 QAA08261 for ; Thu, 5 May 2005 16:16:55 -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 1DTn0e-0005IQ-0S for isms@ietf.org; Thu, 05 May 2005 16:31:49 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 05 May 2005 12:54:15 -0700 X-IronPort-AV: i="3.92,157,1112598000"; d="txt'?scan'208"; a="260376055:sNHT3462201640" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j45JriEp026172; Thu, 5 May 2005 12:54:11 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 12:54:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C551AC.34A79D65" Subject: LPSK revisited (was RE: [Isms] Thoughts on Encapsulation) Date: Thu, 5 May 2005 12:54:10 -0700 Message-ID: X-MS-Has-Attach: yes Thread-Topic: LPSK revisited (was RE: [Isms] Thoughts on Encapsulation) Thread-Index: AcVRa+pBPllrQvd6QnKcCjh+4Dhh4gANwI8w From: "Khanh Nguyen \(khanhvn\)" To: "Sam Hartman" , X-OriginalArrivalTime: 05 May 2005 19:54:11.0771 (UTC) FILETIME=[352418B0:01C551AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C551AC.34A79D65 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am glad that Sam provides some concrete options/criteria that we=20 can use as a start for further discussions. =20 Since I proposed LPSK last month, there have been a few persons=20 expressing supports, but otherwise ISMS responses have been pretty=20 mute. So I'd like to take this opportunity to reexamine LPSK to see how it can fit in Sam's options. Please see inline and let me know your comments. I'd rather=20 be criticized than ignored :) > -----Original Message----- > From: Sam Hartman > > So there are several different security technologies you=20 > might want to support. I'd argue that you probably want to=20 > support more than one. >=20 > 1) TLS/SASL. The combination of TLS and SASL go well together. You > typically use one or both. In one common mode, TLS is used to > authenticate the server (responder) to the client. The server has > a cert and the client does not. You then use SASL to authenticate > the client to the server. TLS is used to protect the session... The LPSK proposal can be an instantiation of this approach: + SRP-SASL can be used to do mutual (not just client) authentication so no cert is needed (see http://srp.stanford.edu for more SRP info) + Localized passwords (similar to USM key localization) are used to=20 authenticate the servers. This is an extension of SRP. I discussed=20 this with Thomas Wu (creator of SRP), and he expressed strong support=20 for it. He also made some suggestion about how to do the localization securely for SRP. I included his idea in the revised LPSK proposal=20 (attached below.) >=20 > 2) Ssh. This provides for authentication using public keys, Kerberos > and passwords among other options. I'd look at the netconf over > ssh document as a starting point for how to do this. >=20 > 3) DTLS. DTLS is probably going to be important because it provides > UDP support. The catch with DTLS is going to be figuring out how > to authenticate the client to the server if the client doesn't have > credentials. You could use SASL while not supporting security > layers but doing so will make the Kerberos camp quite unhappy. Again, LPSK authentication is transport-independent so it can be used=20 w/ SSH and DTLS too, in a similar way to SSL/TLS. For more info, please see attachment for the revised LPSK. I'd like to=20 thank Juergen Schoenwaelder, David Harrington, Wayne Kading, Keith=20 McCloghrie, Kaushik Narayan, Thomas Wu, and others who have provided=20 comments, suggestions, and/or supports for this effort. Khanh ------_=_NextPart_001_01C551AC.34A79D65 Content-Type: text/plain; name="LPSK.txt" Content-Description: LPSK.txt Content-Disposition: attachment; filename="LPSK.txt" Content-Transfer-Encoding: base64 TG9jYWxpemVkIFByZS1TaGFyZWQgS2V5IEF1dGhlbnRpY2F0aW9uIChMUFNLKSBmb3IgU05NUHYz DQoJCQkJCQkNCktoYW5oIE5ndXllbiAoa2hhbmh2bkBjaXNjby5jb20pDQpNYXkgMiwgMjAwNQ0K DQoNCjEuIEludHJvZHVjdGlvbg0KLS0tLS0tLS0tLS0tLS0tDQoNClNlY3VyaW5nIGEgY29tbXVu aWNhdGlvbiBzeXN0ZW0gZ2VuZXJhbGx5IHJlcXVpcmVzIHRocmVlIG1haW4gc2VydmljZXM6DQog LSBBdXRoZW50aWNhdGlvbg0KIC0gRGF0YSBDb25maWRlbnRpYWxpdHkgKHByaXZhY3kpDQogLSBE YXRhIEludGVncml0eSAobWVzc2FnZSBhdXRoZW50aWNhdGlvbikNCg0KVGhpcyBwcm9wb3NhbCBs aW1pdHMgaXRzIHNjb3BlIHRvIHRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlIGZvciBTTk1QLg0K VGhlIG90aGVyIHR3byBzZXJ2aWNlcywgY29uZmlkZW50aWFsaXR5IGFuZCBkYXRhIGludGVncml0 eSwgY2FuIGJlIA0KcHJvdmlkZWQgYnkgYSBzZWN1cmUgdHJhbnNwb3J0IGxheWVyLCBzdWNoIGFz IFRTTCBvciBTU0gsIGFzIGRlc2NyaWJlZCANCmluIHRoZSBUTFNNIHByb3Bvc2FsLg0KDQpJbiB0 aGlzIHByb3Bvc2FsLCBTTk1QIGVudGl0aWVzIGFyZSBhdXRoZW50aWNhdGVkIHVzaW5nIHRoZSBs b2NhbGl6ZWQgDQpwcmUtc2hhcmVkIGtleSAoTFBTSykgbWV0aG9kLiAgVGhlIHVzZXIgcGFzc3dv cmRzIG9yIGNvbW11bml0eSBzdHJpbmdzIA0KYXJlIHVzZWQgdG8gZ2VuZXJhdGUgYXV0aGVudGlj YXRpb24gY3JlZGVudGlhbHMuIFRoZXNlIExQU0sgY3JlZGVudGlhbHMNCmFyZSB1c2VkIGluIGNv bmp1Y3Rpb24gd2l0aCBhIHByZS1zaGFyZWQga2V5IChQU0spIHByb3RvY29sIHN1Y2ggYXMgU1JQ IA0KdG8gYXV0aGVudGljYXRlIG5vdCBvbmx5IHVzZXJzIGJ1dCBhbHNvIFNOTVAgYWdlbnRzLiAg Tm8gZXh0ZXJuYWwgDQppbmZyYXN0cnVjdHVyZSAoZS5nLiBjZXJ0aWZpY2F0ZSBtYW5hZ2VtZW50 LCBrZXkgZGlzdHJpYnV0aW9uIHNlcnZlcnMpIA0KaXMgcmVxdWlyZWQuICANCg0KDQoyLiBPYmpl Y3RpdmVzDQotLS0tLS0tLS0tLS0tDQoNClRoZSBwcm9wb3NlZCBhcmNoaXRlY3R1cmUgYWltcyBh dCB0aGUgZm9sbG93aW5nIG9iamVjdGl2ZXM6DQoNCi0gSGlnaGx5IFNlY3VyZQ0KLSBTaW1wbGUg dG8gaW1wbGVtZW50DQotIEVhc3kgdG8gZGVwbG95IGFuZCBvcGVyYXRlLCBlYXN5IHRvIG1pZ3Jh dGUgZnJvbSBTTk1QdjEgYW5kIFVTTQ0KLSBTdXBwb3J0IG11bHRpcGxlIHRyYW5zcG9ydCBzZWN1 cml0eSBvcHRpb25zDQotIFNlbGYtY29udGFpbmVkLCBkbyBub3QgcmVxdWlyZSBleHRlcm5hbCBp bmZyYXN0cnVjdHVyZSBvdGhlciB0aGFuDQogIGJhc2ljIG5ldHdvcmsgc2VydmljZXMNCi0gQ29t cGF0aWJsZSB3aXRoIGJvdGggdmlldy1iYXNlZCBbVkFDTV0gYW5kIGNvbW11bml0eS1iYXNlZCBh Y2Nlc3MgDQogIGNvbnRyb2wgbW9kZWxzDQotIFN1cHBvcnQgQ2VudHJhbGl6ZWQgQUFBDQoNCg0K My4gU2VwYXJhdGluZyBBdXRoZW50aWNhdGlvbiBmcm9tIENvbmZpZGVudGlhbGl0eSBhbmQgRGF0 YSBJbnRlZ3JpdHkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk9mIHRoZSB0aHJlZSBiYXNpYyBzZWN1cml0eSBz ZXJ2aWNlcywgYXV0aGVudGljYXRpb24gaXMgYWJvdXQgdGhlIA0KY29tbXVuaWNhdGluZyBwYXJ0 aWVzICh1c2VycywgZGV2aWNlcywgZXRjLiksIHdoaWxlIGNvbmZpZGVudGlhbGl0eSANCmFuZCBk YXRhIGludGVncml0eSBhcmUgYWJvdXQgdGhlIGNvbW11bmljYXRlZCBkYXRhIChiaXRzIGFuZCBi eXRlcykuICAgDQoNCkF1dGhlbnRpY2F0aW9uIGlzIHZlcnkgYXBwbGljYXRpb24tc3BlY2lmaWMu ICBUaGUgbmF0dXJlcyBvZiB0aGUgDQplbnRpdGllcyB0byBiZSBhdXRoZW50aWNhdGVkIHZhcnkg ZnJvbSBvbmUgYXBwbGljYXRpb24gdG8gYW5vdGhlci4gIA0KT24gdGhlIG90aGVyIGhhbmQsIGNv bmZpZGVudGlhbGl0eSBhbmQgZGF0YSBpbnRlZ3JpdHkgYXJlIG1vcmUgZ2VuZXJpYyANCnNlcnZp Y2VzLiAgQXBwbGljYXRpb25zIG9mdGVuIHNoYXJlIHRoZSBzYW1lIGJhc2ljIG5lZWRzIHRoYXQg dGhlIGJpdHMNCmFuZCBieXRlcyBpbiB0cmFuc2l0IG11c3Qgbm90IGJlIHJlYWQgKGNvbmZpZGVu dGlhbGl0eSkgb3IgYWx0ZXJlZCANCihpbnRlZ3JpdHkpIGJ5IG91dHNpZGVycy4gIA0KDQpCZWNh dXNlIG9mIHRoZSBhYm92ZSBkaWZmZXJlbmNlLCBpdCBpcyB1c2VmdWwgdG8gZGl2aWRlIChhYnN0 cmFjdGx5KQ0KU05NUHYzIHNlY3VyaXR5IHN5c3RlbSBpbnRvIHR3byBzdWItbW9kdWxlczogKDEp IGF1dGhlbnRpY2F0aW9uIGFuZCANCigyKSBjb25maWRlbnRpYWxpdHkgYW5kIGRhdGEgaW50ZWdy aXR5LiAgSW4gdGhpcyBwcm9wb3NhbCwgDQphdXRoZW50aWNhdGlvbiB3aWxsIGJlIGEgd2VsbC1k ZWZpbmVkIHBhcnQgb2YgU05NUCBzZWN1cml0eSBzeXN0ZW0sIA0Kd2hpbGUgY29uZmlkZW50aWFs aXR5IGFuZCBkYXRhIGludGVncml0eSBjYW4gYmUgaGFuZGxlZCBieSBkaWZmZXJlbnQNCnR5cGVz IG9mIHNlY3VyZSB0cmFuc3BvcnRzLg0KICANCkJ5IG1vZHVsYXJpemluZyB0aGUgU05NUHYzIHNl Y3VyaXR5IHN5c3RlbSB0aGlzIHdheSwgd2UgY2FuIG1lZXQgdGhlIA0Kc3BlY2lmaWMgbmVlZHMg b2YgdGhlIFNOTVAgYXBwbGljYXRpb24gd2hpbGUgaGF2aW5nIHRoZSBmbGV4aWJpbGl0eQ0KdG8g dXNlIGRpZmZlcmVudCBjaG9pY2VzIG9mIHNlY3VyZSB0cmFuc3BvcnRzIGFuZCBtYXhpbWl6aW5n IHRoZSB1c2UgDQpvZiBjb21tb24sIG9mZi10aGUtc2hlbHZlIGNvbXBvbmVudHMgc3VjaCBhcyBU TFMvU1NILg0KDQoNCiAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgfCAgIFNOTVB2MyBTZWN1cml0eSBTeXN0ZW0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgfCAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsgIHwNCiAgfCAgfCAgICAgICAgICAgICAgICBMUFNLIEF1dGhlbnRpY2F0aW9u IFNlcnZpY2UgICAgICAgICAgICAgICAgIHwgIHwNCiAgfCAgKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgIHwNCiAgfCAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg IHwNCiAgfCAgKy0tLS0tLS0tLS0tLS0tLS0tLS0rICArLS0tLS0tLS0tLS0tLS0tLS0rICArLS0t LS0tLS0tLS0tLS0tLSsgIHwNCiAgfCAgfCBTZWN1cmUgICAgICAgICAgICB8ICB8IFNlY3VyZSAg ICAgICAgICB8ICB8IEluc2VjdXJlICAgICAgIHwgIHwNCiAgfCAgfCBDb25uZWN0bi1vcmllbnRl ZCB8ICB8IENvbm5lY3Rpb25sZXNzICB8ICB8IFRyYW5zcG9ydCAgICAgIHwgIHwNCiAgfCAgfCBU cmFuc3BvcnQgICAgICAgICB8ICB8IFRyYW5zcG9ydCAgICAgICB8ICB8IChVRFAsVENQKSAgICAg IHwgIHwNCiAgfCAgfCAoVExTL1NTSCkgICAgICAgICB8ICB8IChTZXNzaW9uLWJhc2VkKSB8ICB8 ICAgICAgICAgICAgICAgIHwgIHwNCiAgfCAgKy0tLS0tLS0tLS0tLS0tLS0tLS0rICArLS0tLS0t LS0tLS0tLS0tLS0rICArLS0tLS0tLS0tLS0tLS0tLSsgIHwNCiAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsNCg0KDQo0LiBMb2NhbGl6ZWQgUHJlLVNoYXJlZCBLZXkgKExQU0spIEF1dGhlbnRp Y2F0aW9uIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpUaGlzIGFyY2hpdGVjdHVyZSBwcm9wb3NlcyBhIHNlbGYtY29udGFpbmVkIGF1dGhlbnRp Y2F0aW9uIGZyYW1ld29yayANCmJhc2VkIG9uIHRoZSBQU0sgbWV0aG9kLiBObyBleHRlcm5hbCBj cmVkZW50aWFsIGluZnJhc3RydWN0dXJlIGlzIA0KbmVlZGVkIChvdGhlciB0aGFuIG9uZSB0byBj b25maWd1cmUgdXNlcnMgYW5kL29yIGNvbW11bml0eSBzdHJpbmdzLikgIA0KVGhlIHVzZXIgcGFz c3dvcmRzIGFuZC9vciBjb21tdW5pdHkgc3RyaW5ncyBhcmUgdXNlZCB0byBnZW5lcmF0ZSB0aGUg DQpwcmUtc2hhcmVkIGtleXMgdGhhdCBhdXRoZW50aWNhdGVzIG5vdCBvbmx5IHVzZXJzIGJ1dCBh bHNvIFNOTVAgZW5naW5lcy4NCg0KU2VjdXJlIHRyYW5zcG9ydHMgc3VjaCBhcyBUTFMgb3IgU1NI IGhhdmUgbWFueSBidWlsdC1pbiBhdXRoZW50aWNhdGlvbiANCm1ldGhvZHM6IHB1YmxpYy1rZXkg Y2VydGlmaWNhdGVzLCBLZXJiZXJvcywgaG9zdCBmaWxlcywgZXRjLiAgVGhlIG1haW4gDQpkcmF3 YmFjayBvZiB0aGVzZSBtZXRob2RzIGlzIHRoYXQgdGhleSByZXF1aXJlIGV4dGVybmFsIGluZnJh c3RydWN0dXJlIA0KKGUuZy4gY2VydGlmaWNhdGUgYXV0aG9yaXR5LCBjZW50cmFsaXplZCBrZXkg ZGlzdHJpYnV0aW9uIGNlbnRlciwgZXRjLikgDQp0aGF0IG5lZWQgc2lnbmlmaWNhbnQgZWZmb3J0 cyB0byBkZXBsb3kgYW5kIG9wZXJhdGUuDQoNClByZS1zaGFyZWQga2V5IChQU0spIGlzIGNvbW1v bmx5IHVzZWQgdG8gcGVyZm9ybSBtdXR1YWwgYXV0aGVudGljYXRpb24uDQpUaGUgbWFqb3Igd2Vh a25lc3Mgb2YgY29udmVudGlvbmFsIFBTSyBhdXRoZW50aWNhdGlvbiBpcyB0aGF0IHRoZSBzaGFy ZWQgDQprZXlzIGFyZSBrbm93biBieSBtYW55IGVudGl0aWVzLiAgSW4gU05NUCBlbnZpcm9ubWVu dHMsIHdoaWNoIGNhbiBoYXZlIA0KbGFyZ2UgbnVtYmVycyBvZiBjb21tdW5pY2F0aW5nIGVudGl0 aWVzLCB0aGlzIGNhbiBiZSBhIHByb2JsZW06IGlmIG9uZSANCmVudGl0eSBpcyBjb21wcm9taXNl ZCAoZS5nLiBhIGRldmljZSBpcyBzdG9sZW4pLCB0aGUgd2hvbGUgc3lzdGVtIG1heSANCmJlIHZ1 bG5lcmFibGUuDQoNClRvIGFkZHJlc3MgdGhhdCBpc3N1ZSwgdGhpcyBwcm9wb3NhbCB1c2VzIGEg bG9jYWxpemF0aW9uIHNjaGVtZSBzaW1pbGFyIA0KdG8gdGhhdCBvZiB0aGUgVVNNIG1vZGVsLiAg VGhlIHVzZXIgSUQsIHVzZXIgcGFzc3dvcmQsIGFuZCBTTk1QIEVuZ2luZQ0KSUQgYXJlIGNvbWJp bmVkIHRvIGdlbmVyYXRlIGEgbG9jYWxpemVkIFBTSy4gIFRoZSBMUFNLIHZhbHVlcywgbm90IHRo ZQ0KcGFzc3dvcmRzLCBhcmUgc3RvcmVkIGluIHRoZSBkZXZpY2UgYW5kIHNlcnZlIGFzIGJvdGgg dGhlIGRldmljZSANCmNyZWRlbnRpYWwgKGZvciBkZXZpY2UgYXV0aGVudGljYXRpb24pIGFzIHdl bGwgYXMgdGhlIHBhc3N3b3JkIA0KYXV0aGVudGljYXRvciAoZm9yIHVzZXIgYXV0aGVudGljYXRp b24uKSAgRm9yIGV4YW1wbGUsIHRoZSBMUFNLIHZhbHVlDQppcyBnZW5lcmF0ZWQgYXMgYmVsb3c6 DQoNCglMUFNLID0gTUQ1KHVzZXJJRCArIE1ENSh1c2VyIHBhc3N3b3JkKSArIHNubXBFbmdpbmVJ RCkNCg0KVGhlIHJlYXNvbiB0aGUgaW5uZXIgTUQ1IGlzIHVzZWQgaXMgdG8gcHJvdGVjdCB0aGUg cGFzc3dvcmQgZHVyaW5nIHVzZXIgDQpjb25maWd1cmF0aW9uLiAgU2VlIHNlY3Rpb24gNyAoQ29u ZmlndXJhdGlvbnMpIGJlbG93IGZvciBtb3JlIGRldGFpbHMuDQpNRDUgaXMgdXNlZCBhcyBhbiBl eGFtcGxlLiAgQW5vdGhlciBzZWN1cmUgaGFzaCBmdW5jdGlvbiBzdWNoIGFzIFNIQSANCmNhbiBh bHNvIGJlIHVzZWQuDQoNCk9uY2UgTFBTSyB2YWx1ZXMgYXJlIGRlZmluZWQsIHRoZXkgY2FuIGJl IHVzZWQgaW4gY29uanVuY3Rpb24gd2l0aCBhIA0KUFNLIHByb3RvY29sIHRvIG11dHVhbGx5IGF1 dGhlbnRpY2F0ZSB1c2VycyBhbmQgZGV2aWNlcy4gIFRoZXJlIGFyZSANCm1hbnkgUFNLIGF1dGhl bnRpY2F0aW9uIG1ldGhvZHMuICBUaGUgU2VjdXJlIFJlbW90ZSBQYXNzd29yZCAoU1JQKSANCnBy b3RvY29sIGlzIG9uZSBvZiB0aGVtLiAgT25lIHdheSB0byBpbXBsZW1lbnQgTFBTSyBsb2NhbGl6 YXRpb24gDQpmb3IgU1JQIGlzIHRvIGxvY2FsaXplIHRoZSBTUlAgc2FsdCB2YWx1ZSB3aXRoIHRo ZSBzZXJ2ZXJJRDoNCg0KCXNhbHQgPSA8dG9wIDY0IGJpdHMgb2YgU0hBKHNubXBFbmdpbmVJRCk+ IHwgPHJhbmRvbSAxNiBiaXRzPg0KDQpUaGUgY2xpZW50IHdpbGwgdXNlIHRoZSBsb2NhbGl6ZWQg c2FsdCB0byBjb25maXJtIHRoZSBzZXJ2ZXIgaWRlbnRpdHkgDQpkdXJpbmcgdGhlIFNSUCBhdXRo ZW50aWNhdGlvbiBwcm9jZXNzLiAgU2VlIFJGQy0yOTQ1IGZvciBtb3JlIGluZm8uDQoNClNSUCBp cyBhbiBhYnN0cmFjdCBwcm90b2NvbHMgd2l0aCBtdWx0aXBsZSBpbXBsZW1lbnRhdGlvbnMuICBU aGVyZSBpcyANCmFuIElGVEYgcHJvcG9zYWwgdG8gYWRkIFNSUCBhdXRoZW50aWNhdGlvbiB0byBU U0wgW1RMUy1TUlBdLiAgQnV0IHRvIA0KYXZvaWQgZGVwZW5kZW5jeSBvbiBhIHNwZWNpZmljIHRy YW5zcG9ydCwgaXQgbWF5IGJlIGRlc2lyYWJsZSB0byB1c2UgDQphbiBhcHBsaWNhdGlvbi1sZXZl bCBpbXBsZW1lbmF0aW9uIG9mIFNSUC4gIE9uZSBzdWNoIGFsdGVybmF0aXZlIGlzIHRvIA0KaW1w bGVtZW50IFNSUCB1c2luZyBzbm1wR2V0IGFuZC9vciBzbm1wU2V0IG1lc3NhZ2VzLiAgQSBzbWFs bCBNSUIgY2FuDQpiZSBkZWZpbmVkIGZvciB0aGlzIHB1cnBvc2UuICBBbm90aGVyIGFsdGVybmF0 aXZlIGlzIHRvIHVzZSBbU0FTTC1TUlBdLg0KDQoNCjUuIEludGVncmF0aW9uIHdpdGggdGhlIFRy YW5zcG9ydHMgTGF5ZXINCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KQXMgbWVudGlvbmVkIGVhcmxpZXIsIHRoZSBMUFNLIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBj YW4gYmUgdXNlZCB3aXRoDQpkaWZmZXJlbnQgdHlwZXMgb2Ygc2VjdXJlIHRyYW5zcG9ydHMgdGhh dCBwcm92aWRlIGVuY3J5cHRpb24gYW5kIA0KZGF0YSBpbnRlZ3JpdHkuICBEZXBlbmQgb24gdGhl IHNwZWNpZmljIHRyYW5zcG9ydCB1c2VkLCBkaWZmZXJlbnQNCm1ldGhvZHMgZm9yIGNyeXB0b2dy YXBoaWMgYmluZGluZyBiZXR3ZWVuIHRoZSBhdXRoZW50aWNhdGlvbiBwcm90b2NvbCANCmFuZCB0 aGUgdHJhbnNwb3J0IHByb3RvY29sIGNhbiBiZSB1c2VkIHRvIHByZXZlbnQgbWFuLWluLXRoZS1t aWRkbGUgDQphdHRhY2tzLg0KDQoNCjUuMSBTZWN1cmUgQ29ubmVjdGlvbi1vcmllbnRlZCBUcmFu c3BvcnQgKGUuZy4gVExTKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpMUFNLIGF1dGhlbnRpY2F0aW9uIGNhbiBiZSBkb25lIGFzIGFuIGludGVn cmF0ZWQgcGFydCBvZiBhIHNlY3VyZQ0KdHJhbnNwb3J0IChlLmcuIFRMUy1TUlApLiAgQ3J5cHRv Z3JhcGhpYyBiaW5kaW5nIHdpbGwgYmUgZG9uZSANCnRyYW5zcGFyZW50bHkgYnkgdGhlIHRyYW5z cG9ydC4gDQoNCklmIExQU0sgYXV0aGVudGljYXRpb24gaXMgZG9uZSBzZXBhcmF0ZWx5IGZyb20g dGhlIHNlY3VyZSB0cmFuc3BvcnQsIA0Kc29tZSBjcnlwdG9ncmFwaGljIGJpbmRpbmcgYmV0d2Vl biBMUFNLIGFuZCB0aGUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gaXMgDQpuZWVkZWQuICBPbmUgc2lt cGxlIHdheSB0byBkbyB0aGlzIGlzIHRvIHVzZSB0aGUgc2hhcmVkIGtleSBnZW5lcmF0ZWQgDQpi eSBMUFNLIGFzIHRoZSBtYXN0ZXIga2V5IGZvciB0aGUgdHJhbnNwb3J0IHNlc3Npb24uICBJZiBh IGRpZmZlcmVudCANCmtleSBhZ3JlZW1lbnQgbWV0aG9kIGlzIGFscmVhZHkgdXNlZCAoZS5nLiBE aWZmaWUtSGVsbG1hbiBvciBSU0EpLCANCnNvbWUga2V5LWJpbmRpbmcgbWV0aG9kcyBzaW1pbGFy IHRvIGRyYWZ0LXB1dGhlbmt1bGFtLWVhcC1iaW5kaW5nLTA0IA0KY2FuIGJlIHVzZWQuDQoNCg0K NS4yIFNlY3VyZSBDb25uZWN0aW9uLWxlc3MsIFNlc3Npb24tYmFzZWQgVHJhbnNwb3J0IA0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGUgc2Ft ZSBMUFNLIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBjYW4gYmUgdXNlZCB3aXRoIGEgc2Vzc2lvbi1i YXNlZCwNCmNvbm5lY3Rpb24tbGVzcyB0cmFuc3BvcnQuICBJbiB0aGlzIGNhc2UsIHRoZSBzaGFy ZWQga2V5IGdlbmVyYXRlZCBieSANCkxQU0sgYXV0aGVudGljYXRpb24gY2FuIGJlIHVzZWQgYXMg dGhlIHNlc3Npb24ga2V5IGZvciB0aGUgc2VjdXJlIA0KdHJhbnNwb3J0Lg0KDQoNCjUuMyBJbnNl Y3VyZSBUcmFuc3BvcnQNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQpMUFNLIGNhbiBhbHNvIHJ1 biBvbiB0b3Agb2YgYW4gaW5zZWN1cmUgdHJhbnNwb3J0IChwbGFpbiBUQ1Agb3IgVURQKS4gIA0K SW4gdGhpcyBjYXNlIGl0IHdpbGwgcHJvdmlkZSBhbiCTQXV0aE5vUHJpdpQgbGV2ZWwgb2Ygc2Vy dmljZS4NCg0KDQo3LiBDb25maWd1cmF0aW9ucw0KLS0tLS0tLS0tLS0tLS0tLS0NCg0KU2luY2Ug dGhlIG1vZGVsIHVzZXMgU05NUCB1c2VyIHBhc3N3b3JkIGFuZC9vciBjb21tdW5pdHkgc3RyaW5n cyB0byANCmdlbmVyYXRlIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzLCBjb25maWd1cmF0aW9u IGlzIHNpbXBsaWZpZWQuICBUaGUgDQpMUFNLIHZhbHVlcyBhcmUgY29uZmlndXJlZCBvbiB0aGUg U05NUCBkZXZpY2UgYXQgdGhlIHNhbWUgdGltZSB0aGUgDQp1c2VycyBhcmUgY29uZmlndXJlZCBv biB0aGF0IGRldmljZS4gIEFzIHBhcnQgb2YgYSB1c2VyIGNvbmZpZ3VyYXRpb24sIA0KdGhlIHVz ZXIgcGFzc3dvcmQgaXMgdXNlZCB0byBnZW5lcmF0ZSB0aGUgTFBTSyB2YWx1ZSBhc3NvY2lhdGVk IHdpdGggDQp0aGF0IHVzZXIuICBUaGUgTFBTSyB2YWx1ZXMsIG5vdCB0aGUgcGFzc3dvcmQsIHdp bGwgYmUgc3RvcmVkIGluIHRoZSANCmRldmljZS4NCg0KQXMgbWVudGlvbmVkIGVhcmxpZXIsIHRo ZSBpbm5lciBNRDUgaGFzaCBmdW5jdGlvbiBpcyB1c2VkIHRvIHByb3RlY3QgDQp0aGUgcGFzc3dv cmQgZHVyaW5nIExQU0sgY29uZmlndXJhdGlvbi4gIFRvIGNvbmZpZ3VyZSBhIG5ldyB1c2VyIG9u IGEgDQpkZXZpY2UsIHRoZSBhZG1pbmlzdHJhdG9yL3N1cGVyLXVzZXIgb25seSBuZWVkcyB0byBr bm93IHRoZSBoYXNoIHZhbHVlIA0Kb2YgdGhlIHBhc3N3b3JkLCBub3QgdGhlIHBsYWluLXRleHQg cGFzc3dvcmQgaXRzZWxmLiAgDQoNClRvIG1pZ3JhdGUgdG8gdGhlIG5ldyBMUFNLIG1vZGVsIGZy b20gVVNNIG9yIFNOTVB2MSwgYW4gYXV0b21hdGVkIA0Kc2NyaXB0IGNhbiBiZSB1c2VkIHRvIGNv bnZlcnQgdGhlIHBhc3N3b3JkcyBvciBjb21tdW5pdHkgc3RyaW5nIHN0b3JlZCANCmluIHRoZSBT Tk1QIGRldmljZXMgdG8gTFBTSyB2YWx1ZXMuDQoNCkZvciBjZW50cmFsaXplZCBBQUEgc29sdXRp b25zLCB0aGUgTFBTSyB2YWx1ZXMgKG9yIHRoZSBwYXNzd29yZHMgdG8gDQpnZW5lcmF0ZSB0aGVt KSBjYW4gYmUgc3RvcmVkIGluIGEgcmVtb3RlIHNlcnZlciBpbnN0ZWFkIG9mIGxvY2FsbHkuICAN CkFsbCBvdGhlciBhc3BlY3RzIG9mIHRoZSBhdXRoZW50aWNhdGlvbiBwcm9jZXNzIHJlbWFpbiB0 aGUgc2FtZS4NCg0KDQo4LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KU2VjdXJlIHRyYW5zcG9ydHMgc3VjaCBhcyBUTFMvU1NIIGFscmVhZHkg cHJvdmlkZSBzdHJvbmcgcHJvdGVjdGlvbiBmb3IgDQpkYXRhIGNvbmZpZGVudGlhbGl0eSBhbmQg aW50ZWdyaXR5LiAgQnkgcnVubmluZyBMUFNLIGF1dGhlbnRpY2F0aW9uIG9uIA0KdG9wIG9mIHN1 Y2ggc2VjdXJlIHRyYW5zcG9ydCwgd2UgY2FuIGhhdmUgYSBjb21wbGV0ZSBzZWN1cml0eSBzb2x1 dGlvbiANCnRhaWxvcmVkIHRvIHRoZSBuZWVkcyBvZiBTTk1QIGFwcGxpY2F0aW9ucy4NCg0KTGlr ZSBvdGhlciBwcmUtc2hhcmVkIGtleSBtZXRob2RzLCB0aGVyZSBhcmUgcmlza3MgdGhhdCB0aGUg cHJlLXNoYXJlZCANCmtleXMgYXJlIGNvbXByb21pc2VkLiAgSW4gTFBTSyBlbnZpcm9ubWVudHMs IHRoZSB2dWxuZXJhYmlsaXR5IHdpbGwgYmUgDQpsaW1pdGVkOg0KDQorIElmIGEgZGV2aWNlIGlz IGNvbXByb21pc2VkLCBpdHMgTFBTSyB2YWx1ZXMgY2FuIG5vdCBiZSB1c2VkIHRvIGFzc3VtZSAN CmZhbHNlIGlkZW50aXR5IG9mIGFub3RoZXIgZGV2aWNlLg0KDQorIElmIGEgZGV2aWNlIGlzIGNv bXByb21pc2VkLCBpdHMgTFBTSyB2YWx1ZXMgY2FuIG5vdCBiZSB1c2VkIHRvIGxvZ2luIA0KdG8g b3RoZXIgZGV2aWNlcw0KDQorIFNOTVAgbWFuYWdlcnMgbWF5IG5vdCBuZWVkIHRvIHN0b3JlIExQ U0sgdmFsdWVzLiAgVGhlIExQU0tzIGNhbiBiZSANCmdlbmVyYXRlIG9uIHRoZSBmbHkgd2hlbiB1 c2VycyBsb2dpbi4NCg0KDQo5LiBTdW1tYXJ5DQotLS0tLS0tLS0tDQpVc2luZyBMUFNLIGF1dGhl bnRpY2F0aW9uIGNhbiBzaW1wbGlmeSBTTk1QIHNlY3VyaXR5IG1vZGVsIHdoaWxlIA0KYWRkcmVz c2luZyBtYW55IGxpbWl0YXRpb25zIG9mIHRoZSBjdXJyZW50IFVTTSBtb2RlbC4gIFRvZ2V0aGVy IHdpdGggDQpzZWN1cmUgdHJhbnNwb3J0cyBzdWNoIGFzIFRMUy9TU0gsIExQU0sgYXV0aGVudGlj YXRpb24gY2FuIHByb3ZpZGVzIGEgDQpjb21wcmVoZW5zaXZlIGFuZCBzdHJvbmcgc2VjdXJpdHkg c29sdXRpb24gdGhhdCBpcyBlYXN5IHRvIGRlcGxveSBhbmQgDQpvcGVyYXRlIGFuZCBmbGV4aWJs ZSB0byBhY2NvbW1vZGF0ZSBmdXR1cmUgZW5jcnlwdGlvbiB0ZWNobm9sb2d5LiAgDQoNCg0KUmVm ZXJlbmNlcw0KLS0tLS0tLS0tLQ0KDQpBbiBBcmNoaXRlY3R1cmUgZm9yIERlc2NyaWJpbmcgU2lt cGxlIE5ldHdvcmsgTWFuYWdlbWVudCBQcm90b2NvbCANCihTTk1QKSBNYW5hZ2VtZW50IEZyYW1l d29ya3MsIFJGQyAzNDExLCBEZWNlbWJlciAyMDAyLg0KDQpVc2VyLWJhc2VkIFNlY3VyaXR5IE1v ZGVsIChVU00pIGZvciB2ZXJzaW9uIDMgb2YgdGhlIFNpbXBsZSBOZXR3b3JrIA0KTWFuYWdlbWVu dCBQcm90b2NvbCAoU05NUHYzKSwgUkZDIDM0MTQsIERlY2VtYmVyIDIwMDIuDQoNClZpZXctYmFz ZWQgQWNjZXNzIENvbnRyb2wgTW9kZWwgKFZBQ00pIGZvciB0aGUgU2ltcGxlIE5ldHdvcmsgDQpN YW5hZ2VtZW50IFByb3RvY29sIChTTk1QKSwgUkZDIDM0MTUsIERlY2VtYmVyIDIwMDIuDQoNClRy YW5zcG9ydCBNYXBwaW5nIFNlY3VyaXR5IE1vZGVsIChUTFNNKSBmb3IgU05NUHYzLCANCmRyYWZ0 LXNjaG9lbnctc25tcC10bHNtLTAxLnR4dCwgT2N0b2JlciAyMDA0DQoNClRoZSBUTFMgUHJvdG9j b2wgVmVyc2lvbiAxLjAsIFJGQyAyMjQ2LCBKYW51YXJ5IDE5OTkNCg0KVGhlIFNSUCBBdXRoZW50 aWNhdGlvbiBhbmQgS2V5IEV4Y2hhbmdlIFN5c3RlbSwgUkZDIDI5NDUsIFNlcHRlbWJlciAyMDAw DQoNCltUTFMtU1JQXSBVc2luZyBTUlAgZm9yIFRMUyBBdXRoZW50aWNhdGlvbiwgZHJhZnQtaWV0 Zi10bHMtc3JwLTA5LnR4dCwgDQpNYXJjaCAxNywgMjAwNQ0KDQpbU0FTTC1TUlBdIFNlY3VyZSBS ZW1vdGUgUGFzc3dvcmQgU0FTTCBNZWNoYW5pc20sIA0KZHJhZnQtYnVyZGlzLWNhdC1zcnAtc2Fz bC0wMywgU2VwIDEyLCAyMDAwDQoNClByZS1TaGFyZWQgS2V5IENpcGhlcnN1aXRlcyBmb3IgVExT LCBkcmFmdC1pZXRmLXRscy1wc2stMDcudHh0LCANCk1hciAxNCwgMjAwNQ0KDQpUaGUgQ29tcG91 bmQgQXV0aGVudGljYXRpb24gQmluZGluZyBQcm9ibGVtLA0KZHJhZnQtcHV0aGVua3VsYW0tZWFw LWJpbmRpbmctMDQudHh0LCBPY3QuIDI3IDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg== ------_=_NextPart_001_01C551AC.34A79D65 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms ------_=_NextPart_001_01C551AC.34A79D65-- From isms-bounces@lists.ietf.org Thu May 05 16:33:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTn2E-0000Wt-Lz; Thu, 05 May 2005 16:33:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTn2C-0000Wf-JF for isms@megatron.ietf.org; Thu, 05 May 2005 16:33:24 -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 QAA10658 for ; Thu, 5 May 2005 16:33:21 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTnGX-0006Gp-Mv for isms@ietf.org; Thu, 05 May 2005 16:48:14 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2B350E0063; Thu, 5 May 2005 16:33:18 -0400 (EDT) To: "Khanh Nguyen (khanhvn)" References: From: Sam Hartman Date: Thu, 05 May 2005 16:33:18 -0400 In-Reply-To: (Khanh Nguyen's message of "Thu, 5 May 2005 12:54:10 -0700") 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: isms@ietf.org Subject: [Isms] Re: LPSK revisited 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 >>>>> "Khanh" == Khanh Nguyen (khanhvn) writes: Khanh> I am glad that Sam provides some concrete options/criteria Khanh> that we can use as a start for further discussions. Khanh> Since I proposed LPSK last month, there have been a few Khanh> persons expressing supports, but otherwise ISMS responses Khanh> have been pretty mute. So I'd like to take this Khanh> opportunity to reexamine LPSK to see how it can fit in Khanh> Sam's options. What are the IPR issues with LPSK? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 16:35:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTn46-00012O-MT; Thu, 05 May 2005 16:35:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTn45-000124-8Q for isms@megatron.ietf.org; Thu, 05 May 2005 16:35: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 QAA11088 for ; Thu, 5 May 2005 16:35:13 -0400 (EDT) Message-Id: <200505052035.QAA11088@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTnIL-0006Sp-VT for isms@ietf.org; Thu, 05 May 2005 16:50:07 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <200505052035000150070l56e>; Thu, 5 May 2005 20:35:01 +0000 From: "David B Harrington" To: "'Khanh Nguyen \(khanhvn\)'" , "'Sam Hartman'" , Subject: RE: LPSK revisited (was RE: [Isms] Thoughts on Encapsulation) Date: Thu, 5 May 2005 16:34:53 -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: AcVRa+pBPllrQvd6QnKcCjh+4Dhh4gANwI8wAAOfTkA= X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 > The LPSK proposal can be an instantiation of this approach: > > + SRP-SASL can be used to do mutual (not just client) authentication > so no cert is needed (see http://srp.stanford.edu for more SRP info) I have a concern about the use of SRP, since it is encumbered by intellectual property issues. I infer from the Cisco IPR statement that implementers of an SRP-based ISMS solution might be subject to licensing fees. I don't think it is wise to build a standard atop encumbered protocols. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 16:52:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTnKe-0000N8-Ey; Thu, 05 May 2005 16:52:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTnKc-0000MW-Fr for isms@megatron.ietf.org; Thu, 05 May 2005 16:52:26 -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 QAA15987 for ; Thu, 5 May 2005 16:52:23 -0400 (EDT) Message-Id: <200505052052.QAA15987@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTnYy-0008PD-1w for isms@ietf.org; Thu, 05 May 2005 17:07:17 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <20050505205215015006ujsqe>; Thu, 5 May 2005 20:52:15 +0000 From: "David B Harrington" To: "'Nelson, David'" , Subject: RE: [Isms] Thoughts on Encapsulation Date: Thu, 5 May 2005 16:52:09 -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: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032318@MAANDMBX2.ets.enterasys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVRhVuotantHKa7Q6+1Q3iJp6z2gAAAOsIQAAsIw7A= X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 David, The current RFC for the SNMPv3 architecture is RFC3411; the RFC257x series has been replaced by the RFC341x series. RFC3411 is about the overall architecture, including the transport mapping, not just the security model architecture. The TLSM document describes in reasonable detail an EK architecture can fit into the RFC3411 architecture by describing the flow that connects the transport mapping of an encapsulating transport with the expected output of a security model, which is later used for SNMP applications and access control. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Nelson, David > Sent: Thursday, May 05, 2005 11:33 AM > To: isms@ietf.org > Subject: RE: [Isms] Thoughts on Encapsulation > > It seems to me that ISMS using EK is not going to closely fit into the > SNMP Security Model architecture as described in RFC 2571. I say that > because an encapsulating security layer typically sits below the > application, (roughly) in the socket layer. In RFC 2571 we have the > Security Model in the middle of the application protocol stack. > > I would suggest, however, that we either "just get over it", and make > progress, or decide that conformity with the RFC 2571 > architecture model > is of sufficient importance that we need to revisit the EK decision. > > I'm suggesting that we make the decision to "just get over it" now, > because if we wait until the EK protocol selection and ISMS > design phase > to deal with this conceptual issue, we run the risk of > de-railing again. > > > _______________________________________________ > 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 May 05 16:59:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTnRZ-0004LR-2X; Thu, 05 May 2005 16:59:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTnRU-0004L1-RN for isms@megatron.ietf.org; Thu, 05 May 2005 16:59:34 -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 QAA16783 for ; Thu, 5 May 2005 16:59:29 -0400 (EDT) Message-Id: <200505052059.QAA16783@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTnfq-0000Pk-IH for isms@ietf.org; Thu, 05 May 2005 17:14:23 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005050520592101400g260ke>; Thu, 5 May 2005 20:59:22 +0000 From: "David B Harrington" To: , "'Sam Hartman'" , , Subject: RE: [Isms] Definitions of OOBK, EK, IBK Date: Thu, 5 May 2005 16:59:14 -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: <427A3D7F.4030503@qualcomm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVRiF5VfLa3tz3eQ0maMpLodUrY0QALB4ow X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I have never liked the "EK" label (encapsulated keying) chosen by the chairs. As I understand it, our architecture discussion was supposed to be about the architectures utilized by the three proposals. The architecture used by the TLSM proposal is not about encapsulating the keys, but about using external protocols to encapsulate the SNMP data stream (e.g. at the transport layer). I don't think any of the proposals explicitly discussed encapsulating just the keys. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Lakshminath Dondeti > Sent: Thursday, May 05, 2005 11:37 AM > To: Sam Hartman; kenh@cmf.nrl.navy.mil; quittek@netlab.nec.de > Cc: isms@ietf.org > Subject: [Isms] Definitions of OOBK, EK, IBK > > Hi Sam, Ken, Juergen, > > While the WG has reached a consensus (noted that it is still in > discussion) on the argument on OOBK vs. EK vs. IBK, we are > still seeing > confusion over the terminology (I for one am confident that I can > describe the ones that I prefer, OOBK and EK, but not quite > sure I can > articulate all three of them with a side-by-side comparison). Could > that be documented please? Please post the definitions, with some > notes comparing them (e.g., EK has this property, while OOBK doesn't > etc.). I am sure a discussion will follow, but after that > please post > the "final" definitions of what they are, so we can all have the same > thing in mind when we speak/write. > > thanks, > Lakshminath > > _______________________________________________ > 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 May 05 17:05:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTnWp-0005iX-Px; Thu, 05 May 2005 17:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTnWo-0005iB-S3 for isms@megatron.ietf.org; Thu, 05 May 2005 17:05:02 -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 RAA17362 for ; Thu, 5 May 2005 17:04:59 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTnlA-0000iD-L3 for isms@ietf.org; Thu, 05 May 2005 17:19:53 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id RAA26061 for ; Thu, 5 May 2005 17:06:09 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma026041; Thu, 5 May 05 17:05:39 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 05 May 2005 17:04:25 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 05 May 2005 17:04:24 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 May 2005 17:04:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Thoughts on Encapsulation Date: Thu, 5 May 2005 17:04:23 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103231B@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Thoughts on Encapsulation Thread-Index: AcVRhVuotantHKa7Q6+1Q3iJp6z2gAAAOsIQAAsIw7AAANIo0A== From: "Nelson, David" To: , X-OriginalArrivalTime: 05 May 2005 21:04:24.0874 (UTC) FILETIME=[045898A0:01C551B6] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:92.2131 M:98.9607 P:95.9108 R:95.9108 S:74.6946 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 David Harrington writes... > The TLSM document describes in reasonable detail an EK architecture > can fit into the RFC3411 architecture by describing the flow that > connects the transport mapping of an encapsulating transport with the > expected output of a security model, which is later used for SNMP > applications and access control. OK, I'll read it again, more carefully this time. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 17:16:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTni8-0000Xq-EL; Thu, 05 May 2005 17:16:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTni6-0000Xi-Hd for isms@megatron.ietf.org; Thu, 05 May 2005 17:16:42 -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 RAA18532 for ; Thu, 5 May 2005 17:16:39 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTnwS-0001J0-Bn for isms@ietf.org; Thu, 05 May 2005 17:31:33 -0400 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id E9CD11BAC4D; Thu, 5 May 2005 23:16:30 +0200 (CEST) Date: Thu, 05 May 2005 23:16:45 +0200 From: Juergen Quittek To: Eliot Lear , Sam Hartman Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Message-ID: <0575656A4ECB966864789082@[192.168.0.112]> In-Reply-To: <4279BC1F.60809@cisco.com> References: <200505041904.j44J4U1E003489@ginger.cmf.nrl.navy.mil> <42792B77.8020005@cisco.com> <4279BC1F.60809@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Eliot, Not *any* decision is a good decision. But please consider that there was (not just rough but) full consensus at the last meeting on making a decision on the architecture first. We also agreed at that time on limiting the discussion by the end of April. At the end of April, I could see a clear consensus on the mailing list for making a decision in time. However, the consensus on what to decide was not obvious. In that situation Ken and I clearly preferred to make a decision based on the past discussions instead of giving up and closing the WG. And in fact we considered the implementer's situation and we do not think that implementers would have fundamental problems with the EK approach. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 5/5/2005 8:24 AM +0200 Eliot Lear wrote: > Sam, > > You think *any* decision is a good decision. I think that's only > reasonable if and only if the implementors have bought into that and > the decisions are roughly technically equivalent. You need consensus > on this point. Otherwise you end up precisely with the IMPP mess > because people walk away from the table. > > As to timelines, you owe us some slack, having thrown the group into > turmoil just before MSP. I'm not saying you had no cause, nor am I > asking for years, but holding The Sword of Damocles over our heads > at this point is premature, and risks repeating technical mistakes > you were attempting to correct simply because people are making > *any* decision. > > Eliot > > _______________________________________________ > 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 May 05 17:29:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTnuV-00043y-SP; Thu, 05 May 2005 17:29:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTnuU-00043e-LL for isms@megatron.ietf.org; Thu, 05 May 2005 17:29:30 -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 RAA20735 for ; Thu, 5 May 2005 17:29:27 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTo8p-0002HJ-Ap for isms@ietf.org; Thu, 05 May 2005 17:44:20 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 05 May 2005 14:29:18 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j45LSYno007278; Thu, 5 May 2005 14:29:16 -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); Thu, 5 May 2005 14:29:16 -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: LPSK revisited (was RE: [Isms] Thoughts on Encapsulation) Date: Thu, 5 May 2005 14:29:14 -0700 Message-ID: Thread-Topic: LPSK revisited (was RE: [Isms] Thoughts on Encapsulation) Thread-Index: AcVRa+pBPllrQvd6QnKcCjh+4Dhh4gANwI8wAAOfTkAAAbEYIA== From: "Khanh Nguyen \(khanhvn\)" To: , "Sam Hartman" , X-OriginalArrivalTime: 05 May 2005 21:29:16.0041 (UTC) FILETIME=[7D269F90:01C551B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 That's a valid concern. Fortunately, Stanford U., which owns the=20 IPR of the SRP method, has released a world-wide, royalty-free=20 license for commercial and non-commercial use of SRP: http://srp.stanford.edu/license.txt I am not aware of the Cisco statement you mentioned, but I think=20 it involves some specific implementation of SRP, not SRP itself. Khanh > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net]=20 > > I have a concern about the use of SRP, since it is encumbered=20 > by intellectual property issues. > I infer from the Cisco IPR statement that implementers of an=20 > SRP-based ISMS solution might be subject to licensing fees. I=20 > don't think it is wise to build a standard atop encumbered protocols. >=20 > David Harrington > dbharrington@comcast.net >=20 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 17:30:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTnvo-0004Ue-BB; Thu, 05 May 2005 17:30:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQON-0002Ya-C3 for isms@megatron.ietf.org; Wed, 04 May 2005 16:22: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 QAA01177 for ; Wed, 4 May 2005 16:22:45 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTQcW-00051l-Od for isms@ietf.org; Wed, 04 May 2005 16:37:25 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 3BB62E0063; Wed, 4 May 2005 16:22:45 -0400 (EDT) To: isms@ietf.org From: Sam Hartman Date: Wed, 04 May 2005 16:22:45 -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: d8ae4fd88fcaf47c1a71c804d04f413d X-Mailman-Approved-At: Thu, 05 May 2005 17:30:51 -0400 Cc: Subject: [Isms] Thoughts on encapsulation 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 The following thoughts are presented as an individual. I'm trying to give a background on all the sorts of things you could do with encapsulation for SNMP. I may miss some things and I may over simplify things. So there are several different security technologies you might want to support. I'd argue that you probably want to support more than one. 1) TLS/SASL. The combination of TLS and SASL go well together. You typically use one or both. In one common mode, TLS is used to authenticate the server (responder) to the client. The server has a cert and the client does not. You then use SASL to authenticate the client to the server. TLS is used to protect the session. Another common mode supported by the TLS+SASL option only involves SASL. You use a SASL security layer that provides mutual authentication to provide both data confidentiality and integrity to the session and to authenticate both parties. This SASL-only mode is used by Kerberos. A third mode involves only TLS. Both the client and server have certificates. This actually often looks like the first mode because the SASL external mechanism is used to signal that TLS has provided the client authentication. 2) Ssh. This provides for authentication using public keys, Kerberos and passwords among other options. I'd look at the netconf over ssh document as a starting point for how to do this. 3) DTLS. DTLS is probably going to be important because it provides UDP support. The catch with DTLS is going to be figuring out how to authenticate the client to the server if the client doesn't have credentials. You could use SASL while not supporting security layers but doing so will make the Kerberos camp quite unhappy. I'd also recommend trying to treat notifications as no different than any other message. Try two approaches and see which works out best. The first is to try using the existing security context for notifications. The second is to try treating notifications as their own security context; most of the mechanisms discussed work if you let the notifier be the client/initiator. The party receiving notifications will need credentials but that's actually probably OK. Here are some things I'd recommend against. Note that these recommendations are not things that would cause me to reject a solution so much as things that would cause me as an individual to have a bunch of questions about why you were taking that approach. 1) Supporting TLS and SASL without supporting all three modes as described above. 2) Using ssh keys but not ssh. 3) Assuming that SASL can be used in a datagram-like manner without ordering and reliable delivery. 4) Using Kerberos directly (*) 5) Using/recommending the Kerberos TLS ciphersuites. The Kerberos ssh support is fine though. 6) Using raw public-key operations. 7) Extracting the session key from a SASL mechanism. That's just not supported by SASL implementations. (*) It may be that SASL is not good enough for the datagram case and thus you may want to provide for future extension to GSS. That might look a lot to some like raw Kerberos; it certainly would be complicated. I'm a bit concerned that UDP support is going to end up complicated. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 17:33:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTnyf-0007Hi-71; Thu, 05 May 2005 17:33:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTnye-0007Ha-6p for isms@megatron.ietf.org; Thu, 05 May 2005 17:33:48 -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 RAA21688 for ; Thu, 5 May 2005 17:33:45 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DToD0-0002gu-9U for isms@ietf.org; Thu, 05 May 2005 17:48:39 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 05 May 2005 14:33:46 -0700 X-IronPort-AV: i="3.92,157,1112598000"; d="scan'208"; a="634559827:sNHT493924882" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j45LXBEp000733; Thu, 5 May 2005 14:33:41 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 14:33:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 May 2005 14:33:42 -0700 Message-ID: Thread-Topic: LPSK revisited Thread-Index: AcVRsb+I9ffd1PMkSDq/JNPrein+AAAB9iSQ From: "Khanh Nguyen \(khanhvn\)" To: "Sam Hartman" X-OriginalArrivalTime: 05 May 2005 21:33:43.0546 (UTC) FILETIME=[1C98A5A0:01C551BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org Subject: [Isms] RE: LPSK revisited 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 > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 >=20 > >>>>> "Khanh" =3D=3D Khanh Nguyen (khanhvn) = writes: >=20 > Khanh> I am glad that Sam provides some concrete options/criteria > Khanh> that we can use as a start for further discussions. >=20 > Khanh> Since I proposed LPSK last month, there have been a few > Khanh> persons expressing supports, but otherwise ISMS responses > Khanh> have been pretty mute. So I'd like to take this > Khanh> opportunity to reexamine LPSK to see how it can fit in > Khanh> Sam's options. >=20 >=20 > What are the IPR issues with LPSK? Pretty much none. Key localization idea is borrowed from USM, and=20 SRP has a worldwide, royalty-free license from Stanford. Khanh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 18:55:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTpFV-00088h-1n; Thu, 05 May 2005 18:55:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTpFT-00088M-V7 for isms@megatron.ietf.org; Thu, 05 May 2005 18:55:16 -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 SAA03530 for ; Thu, 5 May 2005 18:55:11 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTpTp-0007Tj-Ts for isms@ietf.org; Thu, 05 May 2005 19:10:07 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j45MrPVf011991; Thu, 5 May 2005 15:53:25 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 5 May 2005 15:53:26 -0700 Message-ID: From: "McDonald, Ira" To: "'Ken Hornstein'" , isms@ietf.org Subject: RE: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Date: Thu, 5 May 2005 15:53:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On > Behalf Of Ken Hornstein > Sent: Thursday, May 05, 2005 2:02 PM > To: isms@ietf.org > Subject: Re: [Isms] Rough Consensus Declaration: ISMS > Architecture is EK > > <...snip...> > > So, to all WG participants: do you feel that we have to make _some_ > decision on an architecture at this point? If not, do you think more > discussion is useful? If you don't, do you have any suggestions as to > how we should reach consensus? Or do you think we should declare no > consensus and shut down? Specifically, if you're not happy with how > things turned out, we need to hear from you! > > --Ken > I agree that _some_ decision on an architecture is needed now. I do not think more discussion before choosing an architecture is useful. I agree with David Harrington that the term "EK" is a very poor description of application protocol encapsulation by a transport-level security layer. I'd like to remind folks that assymetrical authentication (server-side via TLS, client-side via some 'higher' layer) has been and is failing every day in the real world. I would urge the many disgruntled WG participants to consider the stark alternatives: (1) Go forward with the ISMS WG based on the rough concensus decision of our WG chairs. (2) Watch SNMPv3 (now an IETF full Standard) wither rapidly and be replaced by a bunch of essentially proprietary network management protocols (e.g., the current crop of loosely XML-based ones from the standards organization of your choice). Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 19:37:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTpuM-0007xV-Ch; Thu, 05 May 2005 19:37:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTpuK-0007un-Fe for isms@megatron.ietf.org; Thu, 05 May 2005 19:37:28 -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 TAA08146 for ; Thu, 5 May 2005 19:37: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 1DTq8h-0001y8-NI for isms@ietf.org; Thu, 05 May 2005 19:52:20 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 6FA8CE0063; Thu, 5 May 2005 19:37:18 -0400 (EDT) To: "McDonald, Ira" Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK References: From: Sam Hartman Date: Thu, 05 May 2005 19:37:17 -0400 In-Reply-To: (Ira McDonald's message of "Thu, 5 May 2005 15:53:25 -0700") 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 >>>>> "McDonald," == McDonald, Ira writes: McDonald,> I'd like to remind folks that assymetrical McDonald,> authentication (server-side via TLS, client-side via McDonald,> some 'higher' layer) has been and is failing every day McDonald,> in the real world. How is it failing? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 20:22:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTqbR-0008Je-VA; Thu, 05 May 2005 20:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTqbQ-0008J4-3T for isms@megatron.ietf.org; Thu, 05 May 2005 20:22:00 -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 UAA10810 for ; Thu, 5 May 2005 20:21:57 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTqpn-0004YD-6f for isms@ietf.org; Thu, 05 May 2005 20:36:52 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j460LXPU020026; Thu, 5 May 2005 17:21:33 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 5 May 2005 17:21:34 -0700 Message-ID: From: "McDonald, Ira" To: "'Sam Hartman'" , "McDonald, Ira" Subject: RE: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Date: Thu, 5 May 2005 17:21:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, It's failing because of the man-in-the-middle attacks with freely available hacker tools. If the authenticated security identities of both parties are not bound into the same protocol layer, then man-in-the-middle attacks are easy. This has been noted in the past on the ISMS WG mailing list, but I wanted to remind people again not to make this mistake. This is specifically why using HTTP Digest for client auth after doing server auth at the TLS layer is inherently unsafe (as I'm sure you know). Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Thursday, May 05, 2005 7:37 PM > To: McDonald, Ira > Cc: 'Ken Hornstein'; isms@ietf.org > Subject: Re: [Isms] Rough Consensus Declaration: ISMS > Architecture is EK > > > >>>>> "McDonald," == McDonald, Ira writes: > > McDonald,> I'd like to remind folks that assymetrical > McDonald,> authentication (server-side via TLS, client-side via > McDonald,> some 'higher' layer) has been and is failing every day > McDonald,> in the real world. > > How is it failing? > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 20:31:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTqkY-0001YU-TD; Thu, 05 May 2005 20:31:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTqkX-0001YP-Dy for isms@megatron.ietf.org; Thu, 05 May 2005 20:31:25 -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 UAA11736 for ; Thu, 5 May 2005 20:31:23 -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 1DTqyu-000597-1d for isms@ietf.org; Thu, 05 May 2005 20:46:18 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 325D7E0063; Thu, 5 May 2005 20:31:18 -0400 (EDT) To: "McDonald, Ira" Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK References: From: Sam Hartman Date: Thu, 05 May 2005 20:31:18 -0400 In-Reply-To: (Ira McDonald's message of "Thu, 5 May 2005 17:21:26 -0700") 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: 97adf591118a232206bdb5a27b217034 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 >>>>> "McDonald," == McDonald, Ira writes: McDonald,> Hi, It's failing because of the man-in-the-middle McDonald,> attacks with freely available hacker tools. If the McDonald,> authenticated security identities of both parties are McDonald,> not bound into the same protocol layer, then McDonald,> man-in-the-middle attacks are easy. McDonald,> This has been noted in the past on the ISMS WG mailing McDonald,> list, but I wanted to remind people again not to make McDonald,> this mistake. This is specifically why using HTTP McDonald,> Digest for client auth after doing server auth at the McDonald,> TLS layer is inherently unsafe (as I'm sure you know). So, I really hate to be defending this practice as I'm normally the one who is decrying the practice of not binding authentication. However SASL doesn't currently provide a way of binding authentication to TLS. So if we support SASL, then we are vulnerable to this issue. Note that it is not actually a problem if you verify TLS certificates. So it's not so much that you are vulnerable to a man-in-the-middle attack as that you need to deploy a different authentication infrastructure for client to server than for server to client. If both of these infrastructures work ande are correctly configured then things are secure. At one level I think that is a bad design and hope not to repeat the mistake in future protocols. To the extent that it is reasonable to do I'll make sure that ISMS does not make this mistake. At another level, though, many people do want the combination of SASL and TLS. It is sometimes a bigger mistake to prevent people from using their deployed infrastructure. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 21:48:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTrxC-0000gp-CO; Thu, 05 May 2005 21:48:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTrxA-0000gh-Bu for isms@megatron.ietf.org; Thu, 05 May 2005 21:48:32 -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 VAA18661 for ; Thu, 5 May 2005 21:48:29 -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 1DTsBZ-0001mE-A0 for isms@ietf.org; Thu, 05 May 2005 22:03:25 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 05 May 2005 18:33:23 -0700 X-IronPort-AV: i="3.92,158,1112598000"; d="scan'208"; a="260706603:sNHT2700313052" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j461X7Q4009359; Thu, 5 May 2005 18:33:20 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 18:33:16 -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: Authentication Binding (was RE: [Isms] Rough Consensus Declaration: ISMS Architecture is EK) Date: Thu, 5 May 2005 18:33:15 -0700 Message-ID: Thread-Topic: Authentication Binding (was RE: [Isms] Rough Consensus Declaration: ISMS Architecture is EK) Thread-Index: AcVR02M2QINR35w3Q6KSBOMlFrL/fwAApDhg From: "Khanh Nguyen \(khanhvn\)" To: "Sam Hartman" , "McDonald, Ira" X-OriginalArrivalTime: 06 May 2005 01:33:16.0779 (UTC) FILETIME=[93B5F3B0:01C551DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 > -----Original Message----- > From: Sam Hartman >=20 > >>>>> "McDonald," =3D=3D McDonald, Ira = writes: >=20 > McDonald,> Hi, It's failing because of the man-in-the-middle > McDonald,> attacks with freely available hacker tools. If the > McDonald,> authenticated security identities of both parties are > McDonald,> not bound into the same protocol layer, then > McDonald,> man-in-the-middle attacks are easy. >=20 > McDonald,> This has been noted in the past on the ISMS WG mailing > McDonald,> list, but I wanted to remind people again not to make > McDonald,> this mistake. This is specifically why using HTTP > McDonald,> Digest for client auth after doing server auth at the > McDonald,> TLS layer is inherently unsafe (as I'm sure you know). >=20 > So, I really hate to be defending this practice as I'm=20 > normally the one who is decrying the practice of not binding=20 > authentication. > However SASL doesn't currently provide a way of binding=20 > authentication to TLS. So if we support SASL, then we are=20 > vulnerable to this issue. We can use TLS built-in password auth methods (e.g. TLS-SRP or draft-ietf-tls-psk-07.txt) instead of SASL. Binding will be=20 done transparently by TLS. The disadvantage of this is that=20 SNMP auth will be tightly coupled with a specific transport. Using SASL makes authentication more transport-independent, but=20 some binding will need to be done, as Juergen S. pointed out=20 earlier. draft-puthenkulam-eap-binding-04.txt has some good=20 discussions about the solutions for this. >=20 > Note that it is not actually a problem if you verify TLS certificates. I agree. Once you can bind the server auth to the session, there is no need to bind the client because man-in-the-middle=20 attacks require fooling both sides. IMHO, the problem w/=20 asymetric auth is not really about security (if done properly), but rather about the difficulty to deploy/manage server=20 credentials (e.g. certs) in distributed environments such as SNMP. Khanh > So it's not so much that you are vulnerable to a=20 > man-in-the-middle attack as that you need to deploy a=20 > different authentication infrastructure for client to server=20 > than for server to client. If both of these infrastructures=20 > work ande are correctly configured then things are secure. >=20 > At one level I think that is a bad design and hope not to=20 > repeat the mistake in future protocols. To the extent that=20 > it is reasonable to do I'll make sure that ISMS does not make=20 > this mistake. >=20 > At another level, though, many people do want the combination=20 > of SASL and TLS. It is sometimes a bigger mistake to prevent=20 > people from using their deployed infrastructure. >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 05 22:32:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTsdn-0000PK-TZ; Thu, 05 May 2005 22:32:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTsdn-0000PC-78 for isms@megatron.ietf.org; Thu, 05 May 2005 22:32:35 -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 WAA22992 for ; Thu, 5 May 2005 22:32:32 -0400 (EDT) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTssC-0004eu-HC for isms@ietf.org; Thu, 05 May 2005 22:47:28 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j462WOeA007574; Fri, 6 May 2005 02:32:24 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j462WNgm014452; Fri, 6 May 2005 02:32:24 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005050519322307518 ; Thu, 05 May 2005 19:32:23 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 19:32:23 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 19:32:23 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 22:32:21 -0400 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: LPSK revisited (was RE: [Isms] Thoughts on Encapsulation) Date: Thu, 5 May 2005 22:31:49 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C592901195B48@pysmsx401.amr.corp.intel.com> Thread-Topic: LPSK revisited (was RE: [Isms] Thoughts on Encapsulation) Thread-Index: AcVRa+pBPllrQvd6QnKcCjh+4Dhh4gANwI8wAAOfTkAAAbEYIAAK0oSw From: "Blumenthal, Uri" To: "Khanh Nguyen \(khanhvn\)" , , "Sam Hartman" , X-OriginalArrivalTime: 06 May 2005 02:32:21.0811 (UTC) FILETIME=[D4B6E830:01C551E3] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 There were FUD issues risen around SRP patent, as some were claiming that EKE patent is broad enough to cover SRP too. Since Stanford isn't likely to defend SRP users in court if, say, Lucent chooses to enforce its IPR on EKE... =20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Khanh Nguyen (khanhvn) Sent: Thursday, May 05, 2005 5:29 PM To: ietfdbh@comcast.net; Sam Hartman; isms@ietf.org Subject: RE: LPSK revisited (was RE: [Isms] Thoughts on Encapsulation) That's a valid concern. Fortunately, Stanford U., which owns the=20 IPR of the SRP method, has released a world-wide, royalty-free=20 license for commercial and non-commercial use of SRP: http://srp.stanford.edu/license.txt I am not aware of the Cisco statement you mentioned, but I think=20 it involves some specific implementation of SRP, not SRP itself. Khanh > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net]=20 > > I have a concern about the use of SRP, since it is encumbered=20 > by intellectual property issues. > I infer from the Cisco IPR statement that implementers of an=20 > SRP-based ISMS solution might be subject to licensing fees. I=20 > don't think it is wise to build a standard atop encumbered protocols. >=20 > David Harrington > dbharrington@comcast.net >=20 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 06 02:57:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTwmY-0003zd-DC; Fri, 06 May 2005 02:57:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTwmW-0003zW-2z for isms@megatron.ietf.org; Fri, 06 May 2005 02:57: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 CAA06900 for ; Fri, 6 May 2005 02:57:50 -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 1DTx0x-0004Lv-4T for isms@ietf.org; Fri, 06 May 2005 03:12:48 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 05 May 2005 23:41:37 -0700 X-IronPort-AV: i="3.92,158,1112598000"; d="scan'208"; a="261050650:sNHT5025359798" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j466fXPo028679; Thu, 5 May 2005 23:41:34 -0700 (PDT) Received: from [212.254.247.6] (ams-clip-vpn-dhcp158.cisco.com [10.61.64.158]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j466Va2X001845; Thu, 5 May 2005 23:31:37 -0700 Message-ID: <427B119A.9060704@cisco.com> Date: Fri, 06 May 2005 08:41:30 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK References: <200505041904.j44J4U1E003489@ginger.cmf.nrl.navy.mil> <42792B77.8020005@cisco.com> <4279BC1F.60809@cisco.com> <0575656A4ECB966864789082@[192.168.0.112]> In-Reply-To: <0575656A4ECB966864789082@[192.168.0.112]> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115361098.326744"; x:"432200"; a:"rsa-sha1"; b:"nofws:406"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"ek+FMsGQjE2iVD6FqkalEXHO+QIKFL3JGPCq+ajFqgiS/1NFmPZA5tOkEPMUEgd+qW3BhlLn" "LH/8smqY5Gj33ALGbYayj1tdji7CrJury+C4FJmSDfzFrKWDBdT7XbUpqpW3cbKqtTP0C1YeEVL" "Wd1pWNre/PncWhErDfyLS52s="; c:"Date: Fri, 06 May 2005 08:41:30 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture i" "s EK" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit 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 Juergen Quittek wrote: > But please consider that there was (not just rough but) full consensus > at the last meeting on making a decision on the architecture first. No, we were ordered to do so. > We also agreed at that time on limiting the discussion by the end of > April. At the end of April, I could see a clear consensus on the > mailing list for making a decision in time. However, the consensus > on what to decide was not obvious. No, we were ordered to have consensus by May 1 or disband. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 06 04:53:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTyaZ-00078e-H9; Fri, 06 May 2005 04:53:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTyaX-00078V-AY for isms@megatron.ietf.org; Fri, 06 May 2005 04:53:37 -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 EAA16638 for ; Fri, 6 May 2005 04:53:34 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTyoz-0003Jw-D1 for isms@ietf.org; Fri, 06 May 2005 05:08:34 -0400 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 10C1815133; Fri, 6 May 2005 10:59:02 +0200 (CEST) Received: from [10.1.1.171] ([10.1.1.171]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 10:53:26 +0200 Date: Fri, 06 May 2005 10:53:42 +0200 From: Juergen Quittek To: Eliot Lear Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Message-ID: In-Reply-To: <427B119A.9060704@cisco.com> References: <427B119A.9060704@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 06 May 2005 08:53:26.0609 (UTC) FILETIME=[11323410:01C55219] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Eliot, --On 5/6/2005 8:41 AM +0200 Eliot Lear wrote: > Juergen Quittek wrote: >> But please consider that there was (not just rough but) full consensus >> at the last meeting on making a decision on the architecture first. > > No, we were ordered to do so. We we got the strong recommendation by our ADs not to use EAP. But when we discussed how to proceed facing this situation, there was full consensus on rather deciding on the architecture first instead of modifying the proposed solutions and having another round of protocol evaluation. >> We also agreed at that time on limiting the discussion by the end of >> April. At the end of April, I could see a clear consensus on the >> mailing list for making a decision in time. However, the consensus >> on what to decide was not obvious. > > No, we were ordered to have consensus by May 1 or disband. Certainly, we have an obligation to specify time limits at the IETF. But this was not an ordered deadline. We decided at our last meeting to limit this discussion by the end of April (you were there). We could also have chosen another month say May or June, but this would probably have been a waste of time and resources. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de > Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 06 09:26:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU2r3-0006Af-MH; Fri, 06 May 2005 09:26:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU2r1-0006AU-Pi for isms@megatron.ietf.org; Fri, 06 May 2005 09:26:55 -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 JAA14354 for ; Fri, 6 May 2005 09:26:53 -0400 (EDT) Message-Id: <200505061326.JAA14354@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU35V-0004RW-0k for isms@ietf.org; Fri, 06 May 2005 09:41:55 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <20050506132643013004o07qe>; Fri, 6 May 2005 13:26:44 +0000 From: "David B Harrington" To: "'Eliot Lear'" , Subject: RE: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Date: Fri, 6 May 2005 09:26: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 In-Reply-To: <427B119A.9060704@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVSCRYqvisyZPhLSZqto5m0hbYdFgANI4Sg X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Eliot, I notice that you didn't express an opinion on which architecture you prefer. I'm having trouble understanding what you are attempting to accomplish with your line of argument. Are you trying to force the WG to not reach consensus by the deadline (i.e. reject the chairs statement of rough consensus), and thus force the WG to disband? If not that, what resolution are you shooting for? Thanks, David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Eliot Lear > Sent: Friday, May 06, 2005 2:42 AM > To: Juergen Quittek > Cc: Sam Hartman; isms@ietf.org > Subject: Re: [Isms] Rough Consensus Declaration: ISMS > Architecture is EK > > > > Juergen Quittek wrote: > > But please consider that there was (not just rough but) > full consensus > > at the last meeting on making a decision on the architecture first. > > No, we were ordered to do so. > > > We also agreed at that time on limiting the discussion by the end of > > April. At the end of April, I could see a clear consensus on the > > mailing list for making a decision in time. However, the consensus > > on what to decide was not obvious. > > No, we were ordered to have consensus by May 1 or disband. > > Eliot > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 06 10:14:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU3bR-0004fD-5x; Fri, 06 May 2005 10:14:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU3bP-0004f8-7N for isms@megatron.ietf.org; Fri, 06 May 2005 10:14: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 KAA19095 for ; Fri, 6 May 2005 10:14:48 -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 1DU3pu-0007Ob-2e for isms@ietf.org; Fri, 06 May 2005 10:29:51 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B7B4DE0063; Fri, 6 May 2005 10:14:43 -0400 (EDT) To: Eliot Lear Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK References: <200505041904.j44J4U1E003489@ginger.cmf.nrl.navy.mil> <42792B77.8020005@cisco.com> <4279BC1F.60809@cisco.com> <0575656A4ECB966864789082@[192.168.0.112]> <427B119A.9060704@cisco.com> From: Sam Hartman Date: Fri, 06 May 2005 10:14:43 -0400 In-Reply-To: <427B119A.9060704@cisco.com> (Eliot Lear's message of "Fri, 06 May 2005 08:41:30 +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: ea4ac80f790299f943f0a53be7e1a21a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Eliot" == Eliot Lear writes: Eliot> Juergen Quittek wrote: >> But please consider that there was (not just rough but) full >> consensus at the last meeting on making a decision on the >> architecture first. Eliot> No, we were ordered to do so. Ordered by whom? A working group member (not me) came up with the idea of the architecture discussion and the consensus of the room was to go that path. You certainly weren't ordered by me and I don't think you were ordered by the WG chairs. >> We also agreed at that time on limiting the discussion by the >> end of April. At the end of April, I could see a clear >> consensus on the mailing list for making a decision in time. >> However, the consensus on what to decide was not obvious. Eliot> No, we were ordered to have consensus by May 1 or disband. No, you committed to a milestone. The milestone was agreed by the area director and chair as is our process. I would have been happy with any set of milestones that got us to a protocol proposal by Paris. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 06 11:24:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU4ga-0006q7-O5; Fri, 06 May 2005 11:24:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU4gZ-0006q2-DX for isms@megatron.ietf.org; Fri, 06 May 2005 11:24:15 -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 LAA27704 for ; Fri, 6 May 2005 11:24:12 -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 1DU4v3-0003kn-O1 for isms@ietf.org; Fri, 06 May 2005 11:39:16 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 May 2005 08:00:02 -0700 X-IronPort-AV: i="3.92,162,1112598000"; d="scan'208"; a="261445545:sNHT2838888078" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j46ExuO3012883; Fri, 6 May 2005 07:59:57 -0700 (PDT) Received: from [212.254.247.6] (ams-clip-vpn-dhcp4428.cisco.com [10.61.81.75]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j46Eo0Zn004195; Fri, 6 May 2005 07:50:01 -0700 Message-ID: <427B866C.9030202@cisco.com> Date: Fri, 06 May 2005 16:59:56 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK References: <200505041904.j44J4U1E003489@ginger.cmf.nrl.navy.mil> <42792B77.8020005@cisco.com> <4279BC1F.60809@cisco.com> <0575656A4ECB966864789082@[192.168.0.112]> <427B119A.9060704@cisco.com> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115391003.321445"; x:"432200"; a:"rsa-sha1"; b:"nofws:1511"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"JNJ64OIbImTxMTBGhDxVcfziiI01cpkJ68GWogPvVSc6b+sdPjSCffdivbkawLDMOjvXHfmF" "zwLxoh6gFPA38AYUFvZjWwp6QDuh7o2v+gLmLJGJCJy3QEe+Z+cl0ry3fV0AWG2JfItjsjKi3oB" "PteTCXdZKL94XiyS7jpxgTio="; c:"Date: Fri, 06 May 2005 16:59:56 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture i" "s EK" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 This is my last message on the subject as I get the impression no one agrees with my position. I was in the room and I know what I heard, and I remember objecting - LOUDLY - at the time. Sam Hartman wrote: > Ordered by whom? A working group member (not me) came up with the > idea of the architecture discussion and the consensus of the room was > to go that path. There was no other path to go because you had foreclosed other paths. See below. > No, you committed to a milestone. The milestone was agreed by the > area director and chair as is our process. Because you threatened the group with being shut down days after throwing out the progress the group had made. Again, I'm not saying you didn't have good reason. This may sound odd, but sometimes it takes a bit to digest your actions, which by the way, thoroughly frustrated a number of participants. > > I would have been happy with any set of milestones that got us to a > protocol proposal by Paris. You weren't. You specifically precluded protocol proposals. Instead we held a vote. Let me ask you this: did YOU know how OOB could be implemented without EAP in a reasonable period of time? I don't. We probably could have figured something- for instance, Wes suggests that the use of TLS I mentioned was in fact OOB. Now the vote is behind us. I suggest the vote is meaningless and that there is really no consensus. If you want to call another question, that's fine, but please let's not make more of what we got than what we got. By the way, in answer to Dave, I'm on record on this list for preferring something akin to EK. But I still don't like how we got here, and I think other proposals should be entertained if they substantially meet your security concerns, because otherwise I'm concerned that those people will refuse to participate in the process again, and with good reason. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 06 12:17:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU5W7-0002zc-5a; Fri, 06 May 2005 12:17:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU5W5-0002zX-Ky for isms@megatron.ietf.org; Fri, 06 May 2005 12:17:29 -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 MAA06229 for ; Fri, 6 May 2005 12:17:26 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU5kc-00080k-FV for isms@ietf.org; Fri, 06 May 2005 12:32:30 -0400 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id BD97015126; Fri, 6 May 2005 18:22:59 +0200 (CEST) Received: from [10.1.1.171] ([10.1.1.171]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 18:17:19 +0200 Date: Fri, 06 May 2005 18:17:35 +0200 From: Juergen Quittek To: Eliot Lear , Sam Hartman Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Message-ID: <4EF354173C9288708E9FC016@[10.1.1.171]> In-Reply-To: <427B866C.9030202@cisco.com> References: <427B866C.9030202@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 06 May 2005 16:17:19.0799 (UTC) FILETIME=[13D07C70:01C55257] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org --On 5/6/2005 4:59 PM +0200 Eliot Lear wrote: > This is my last message on the subject as I get the impression no one > agrees with my position. I was in the room and I know what I heard, and > I remember objecting - LOUDLY - at the time. > > Sam Hartman wrote: > >> Ordered by whom? A working group member (not me) came up with the >> idea of the architecture discussion and the consensus of the room was >> to go that path. > > There was no other path to go because you had foreclosed other paths. > See below. Actually, there was. Initially I suggested to go immediately through another round of proposal submission and evaluation under the new discovered constraints. But the WG (without any objection) preferred having the architecture discussion first. >> No, you committed to a milestone. The milestone was agreed by the >> area director and chair as is our process. > > Because you threatened the group with being shut down days after > throwing out the progress the group had made. Again, I'm not saying you > didn't have good reason. This may sound odd, but sometimes it takes a > bit to digest your actions, which by the way, thoroughly frustrated a > number of participants. Still, milestone and process were chosen by the group, not by the AD. >> >> I would have been happy with any set of milestones that got us to a >> protocol proposal by Paris. > > You weren't. You specifically precluded protocol proposals. Instead we > held a vote. Let me ask you this: did YOU know how OOB could be > implemented without EAP in a reasonable period of time? I don't. We > probably could have figured something- for instance, Wes suggests that > the use of TLS I mentioned was in fact OOB. > > Now the vote is behind us. I suggest the vote is meaningless and that > there is really no consensus. If you want to call another question, > that's fine, but please let's not make more of what we got than what we got. > > By the way, in answer to Dave, I'm on record on this list for preferring > something akin to EK. But I still don't like how we got here, and I > think other proposals should be entertained if they substantially meet > your security concerns, because otherwise I'm concerned that those > people will refuse to participate in the process again, and with good > reason. Do you really think that frustration would be less if follow your suggestion and decide that we cannot achieve rough consensus? > Eliot Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 06 12:46:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU5yQ-0000EC-L3; Fri, 06 May 2005 12:46:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU5yP-0000E4-Ta for isms@megatron.ietf.org; Fri, 06 May 2005 12:46: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 MAA08763 for ; Fri, 6 May 2005 12:46:42 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU6Cv-0001SL-3y for isms@ietf.org; Fri, 06 May 2005 13:01:47 -0400 Received: from pc6 (1Cust221.tnt108.lnd4.gbr.da.uu.net [62.188.170.221]) by blaster.systems.pipex.net (Postfix) with SMTP id 8EE27E0002C2; Fri, 6 May 2005 17:46:28 +0100 (BST) Message-ID: <05c301c55252$39d23300$0601a8c0@pc6> From: "Tom Petch" To: "Juergen Quittek" References: <427B119A.9060704@cisco.com> Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Date: Fri, 6 May 2005 17:19:15 +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: 97adf591118a232206bdb5a27b217034 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: "Juergen Quittek" To: "Eliot Lear" Cc: Sent: Friday, May 06, 2005 10:53 AM Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK > Eliot, > > Certainly, we have an obligation to specify time limits at the IETF. > But this was not an ordered deadline. We decided at our last meeting to > limit this discussion by the end of April (you were there). Weeeell, those of you that were there at the meeting decided:-) According to the minutes, "The WG has to decide on an architecture until April and on a new charter until August. the milestones in the current charter will be updated accordingly" I was taken by surprise by the post on 29th April to the effect that there were some 40 hours left in which to decide on an architecture; the call for consensus on 21st April omitted this deadline. I think that that could have been handled better. But, for all the imperfections in process, I would like now to concentrate on EK, first of all understanding just what it is (as opposed to the I-D that floated the idea first) to see if it will fly. > > Juergen _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 06 12:48:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU5zx-0000Xk-Kg; Fri, 06 May 2005 12:48:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU5zw-0000XH-2t for isms@megatron.ietf.org; Fri, 06 May 2005 12:48: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 MAA08971 for ; Fri, 6 May 2005 12:48:16 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU6ES-0001Uo-7J for isms@ietf.org; Fri, 06 May 2005 13:03:21 -0400 Received: from pc6 (1Cust221.tnt108.lnd4.gbr.da.uu.net [62.188.170.221]) by blaster.systems.pipex.net (Postfix) with SMTP id 37014E0000C8 for ; Fri, 6 May 2005 17:48:09 +0100 (BST) Message-ID: <05ef01c55252$73355c80$0601a8c0@pc6> From: "Tom Petch" References: <3DEC199BD7489643817ECA151F7C59290115B33F@pysmsx401.amr.corp.intel.com> <427A3D7F.4030503@qualcomm.com> Subject: Re: [Isms] Definitions of OOBK, EK, IBK Date: Fri, 6 May 2005 17:44:04 +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: c1c65599517f9ac32519d043c37c5336 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 To quote from Ken again, "Encapsulation keying" This is the approach taken by TLSM. An encapsulation protocol (such as TLS) is used to "wrap" SNMP payloads. A traditional USM could be run underneath this protocol. - Likely requires no changes to SNMP protocol. - Is used by a number of other protocols with a great deal of success. - _May_ require the use of TCP. - Traditional TLS only performs authentication for some mechanisms, may require additional work to support other authentication schemes. Tom Petch ----- Original Message ----- From: "Lakshminath Dondeti" To: "Sam Hartman" ; ; Cc: Sent: Thursday, May 05, 2005 5:36 PM Subject: [Isms] Definitions of OOBK, EK, IBK > Hi Sam, Ken, Juergen, > > While the WG has reached a consensus (noted that it is still in > discussion) on the argument on OOBK vs. EK vs. IBK, we are still seeing > confusion over the terminology (I for one am confident that I can > describe the ones that I prefer, OOBK and EK, but not quite sure I can > articulate all three of them with a side-by-side comparison). Could > that be documented please? Please post the definitions, with some > notes comparing them (e.g., EK has this property, while OOBK doesn't > etc.). I am sure a discussion will follow, but after that please post > the "final" definitions of what they are, so we can all have the same > thing in mind when we speak/write. > > thanks, > Lakshminath > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 06 13:59:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU76b-0002zp-0I; Fri, 06 May 2005 13:59:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU76a-0002zk-7N for isms@megatron.ietf.org; Fri, 06 May 2005 13:59:16 -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 NAA15067 for ; Fri, 6 May 2005 13:59:14 -0400 (EDT) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU7L6-00066f-P9 for isms@ietf.org; Fri, 06 May 2005 14:14:18 -0400 Received: from localhost ([127.0.0.1] helo=aud) by hosting.revelstone.com with smtp (Exim 4.50) id 1DU76T-00030o-IZ; Fri, 06 May 2005 13:59:09 -0400 Date: Fri, 6 May 2005 13:59:07 -0400 From: Robert Story To: Eliot Lear Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Message-ID: <20050506135907.0ae59c36@aud> In-Reply-To: <427B866C.9030202@cisco.com> References: <200505041904.j44J4U1E003489@ginger.cmf.nrl.navy.mil> <42792B77.8020005@cisco.com> <4279BC1F.60809@cisco.com> <0575656A4ECB966864789082@[192.168.0.112]> <427B119A.9060704@cisco.com> <427B866C.9030202@cisco.com> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit 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 On Fri, 06 May 2005 16:59:56 +0200 Eliot wrote: EL> There was no other path to go because you had foreclosed other paths. EL> Because you threatened the group with being shut down days after EL> throwing out the progress the group had made. Not true. He just threw out EAP, which was part of the one OOB proposal submitted. As the rough consensus has shown, there is no guarantee that OOB would have been chosen even if EAP was left in the picture. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 06 19:16:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUC3Y-0003iX-T2; Fri, 06 May 2005 19:16:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUC3X-0003hN-LL for isms@megatron.ietf.org; Fri, 06 May 2005 19:16:28 -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 TAA21309 for ; Fri, 6 May 2005 19:16:24 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUCI7-0000gz-9Q for isms@ietf.org; Fri, 06 May 2005 19:31:32 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 06 May 2005 16:16:17 -0700 X-IronPort-AV: i="3.92,163,1112598000"; d="scan'208"; a="634829673:sNHT28811608" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j46NFlQC007375; Fri, 6 May 2005 16:16:14 -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); Fri, 6 May 2005 16:16:10 -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: LPSK revisited (was RE: [Isms] Thoughts on Encapsulation) Date: Fri, 6 May 2005 16:16:10 -0700 Message-ID: Thread-Topic: LPSK revisited (was RE: [Isms] Thoughts on Encapsulation) Thread-Index: AcVRa+pBPllrQvd6QnKcCjh+4Dhh4gANwI8wAAOfTkAAAbEYIAAK0oSwACih0SA= From: "Khanh Nguyen \(khanhvn\)" To: "Blumenthal, Uri" , , "Sam Hartman" , X-OriginalArrivalTime: 06 May 2005 23:16:10.0761 (UTC) FILETIME=[9708F790:01C55291] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 > From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 >=20 > There were FUD issues risen around SRP patent, as some were=20 > claiming that EKE patent is broad enough to cover SRP too.=20 > Since Stanford isn't likely to defend SRP users in court if,=20 > say, Lucent chooses to enforce its IPR on EKE... As far as I know, Lucent has never formally claimed any IPR on SRP. The FUD issue came up a few years ago when someone said Lucent was=20 looking at the *possibility* of their EKE patents covering some=20 aspects of SRP. Lucent later issued a statement saying they didn't=20 intent to do that. =20 Anyway, LPSK is an abstract method that can work with many PSK auth methods. I picked SRP as an example because it's secure, relatively simple and widely used, but other PSK methods (e.g. CHAP) can be=20 used too. CHAP and older PSK methods do not provide protection=20 against off-line dictionary attacks, but that can be alleviated by=20 enforcing some minimum password length, etc. BTW, USM does not=20 provide dictionary attack protection neither (except by min passwd=20 length, etc.) and people don't see that as a big deal. In the end, we can select not one but a few PSK methods for LPSK implementation. For example, iSCSI (RFC3720) supports both SRP and=20 CHAP. BTW, the iSCSI WG already examined SRP IPR issues pretty thoughoutly. Khanh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 06 20:56:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUDcb-0005lH-FF; Fri, 06 May 2005 20:56:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUDcZ-0005lC-QS for isms@megatron.ietf.org; Fri, 06 May 2005 20:56: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 UAA29140 for ; Fri, 6 May 2005 20:56:41 -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 1DUDrB-0005In-9m for isms@ietf.org; Fri, 06 May 2005 21:11:49 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 06 May 2005 17:56:35 -0700 Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j470uWPo022841 for ; Fri, 6 May 2005 17:56:32 -0700 (PDT) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA18125 for isms@ietf.org; Fri, 6 May 2005 17:56:32 -0700 (PDT) From: Keith McCloghrie Message-Id: <200505070056.RAA18125@cisco.com> Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK To: isms@ietf.org Date: Fri, 6 May 2005 17:56:32 -0700 (PDT) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Apparently, the people who voted for (including the maybe's and the not-against's) EK, believe that they voted not only for encapsulating the keying but also for encapsulating SNMP messages. Assuming this is true, then it seems to me that if one is forced to pay the price of TLS in order to have secure SNMP, then I no longer see any benefit in running SNMP over UDP. There are both advantages and disadvantages of running SNMP over TCP; the advantages include larger messages and flow control. For the disadvantages, all but one of them are inherent in encapsulating SNMP messages in TLS; the remaining one is the minor issue that both SNMP and TCP have reliability mechanisms, i.e., SNMP engines should avoid having SNMP's retransmission timers fire before TCP's retransmission timers (see page 2 of RFC 3430). That one remaining disadvantage is negligible compared to larger messages and flow-control. Therefore, to define SNMP-over-DTLS-over-UDP is silly; the only sensible way of using TLS is to define SNMP-over-TLS-over-TCP. So, I believe the WG's choice of EK discards the perceived wisdom of the last 15+ years that UDP was the preferred transport mapping. Nevertheless, given that the WG has decided to do this, I think it should be made explicit by: - putting RFC 3430 on the standards track, - starting an update to remove the word "preferred" from RFC 3417, - not wasting any time on defining a SNMP-over-DTLS-over-UDP, Keith. PS. As a further observation, I will note that this has occurred in a Security Area Working Group. How sad this all is. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat May 07 00:28:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUGvE-0001Pm-9Z; Sat, 07 May 2005 00:28:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUGvC-0001Pg-Iz for isms@megatron.ietf.org; Sat, 07 May 2005 00:28:10 -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 AAA12411 for ; Sat, 7 May 2005 00:28:07 -0400 (EDT) Message-Id: <200505070428.AAA12411@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.89]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUH9p-0004eS-N6 for isms@ietf.org; Sat, 07 May 2005 00:43:18 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <200505070428000140084v57e>; Sat, 7 May 2005 04:28:00 +0000 From: "David B Harrington" To: "'Keith McCloghrie'" , Subject: RE: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Date: Sat, 7 May 2005 00:27:55 -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: <200505070056.RAA18125@cisco.com> Thread-Index: AcVSn9b7laQ4+ra5TDawYrtQaHrOlAAG6IZg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 Keith, I am well aware of the UDP vs TCP debate, and understand your concerns. Personally, I think a UDP transport is, and has always been, important for troubleshooting broken networks. However, network robustness has changed dramatically since the late 80s. SNMP has also changed in terms of its use cases. MIB modules originally provided limited amounts of information. But now tables have grown in size, and MIB modules provide more information than earlier MIB modules. Much more management/monitoring is done for well-functioning networks. I think the advantages of larger messages and flow control are warranted for this type of management. I still believe a UDP transport will be important for troubleshooting. This could be provided by also having USM (with maybe a single root user), but supporting a DTLS transport to supplement a TLS transport would seem to make more sense, if TLS and DTLS can share a security infrastructure. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Keith McCloghrie > Sent: Friday, May 06, 2005 8:57 PM > To: isms@ietf.org > Subject: Re: [Isms] Rough Consensus Declaration: ISMS > Architecture is EK > > Apparently, the people who voted for (including the maybe's and the > not-against's) EK, believe that they voted not only for encapsulating > the keying but also for encapsulating SNMP messages. Assuming this is > true, then it seems to me that if one is forced to pay the > price of TLS > in order to have secure SNMP, then I no longer see any benefit in > running SNMP over UDP. There are both advantages and disadvantages of > running SNMP over TCP; the advantages include larger messages and flow > control. For the disadvantages, all but one of them are inherent in > encapsulating SNMP messages in TLS; the remaining one is the > minor issue > that both SNMP and TCP have reliability mechanisms, i.e., SNMP engines > should avoid having SNMP's retransmission timers fire before TCP's > retransmission timers (see page 2 of RFC 3430). That one remaining > disadvantage is negligible compared to larger messages and > flow-control. > Therefore, to define SNMP-over-DTLS-over-UDP is silly; the only > sensible way of using TLS is to define SNMP-over-TLS-over-TCP. > > So, I believe the WG's choice of EK discards the perceived wisdom > of the last 15+ years that UDP was the preferred transport mapping. > Nevertheless, given that the WG has decided to do this, I think it > should be made explicit by: > > - putting RFC 3430 on the standards track, > - starting an update to remove the word "preferred" from RFC 3417, > - not wasting any time on defining a SNMP-over-DTLS-over-UDP, > > Keith. > > PS. As a further observation, I will note that this has occurred in a > Security Area Working Group. How sad this all is. > > _______________________________________________ > 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 Sat May 07 00:39:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUH5t-0002oG-B7; Sat, 07 May 2005 00:39:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUH5q-0002oB-Bs for isms@megatron.ietf.org; Sat, 07 May 2005 00:39:10 -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 AAA13375 for ; Sat, 7 May 2005 00:39:06 -0400 (EDT) Message-Id: <200505070439.AAA13375@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.89]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUHKT-00058W-MQ for isms@ietf.org; Sat, 07 May 2005 00:54:18 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <200505070439000140086000e>; Sat, 7 May 2005 04:39:00 +0000 From: "David B Harrington" To: , "'Keith McCloghrie'" , Subject: RE: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Date: Sat, 7 May 2005 00:38:55 -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: <200505070428.AAA12411@ietf.org> Thread-Index: AcVSn9b7laQ4+ra5TDawYrtQaHrOlAAG6IZgAAC4mEA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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, If DTLS has significant session setup requirements, then the USM/UDP might still be a better choice for troubleshooting. We should consider the applicability of various solutions for troubleshooting a broken network, and for managing a non-broken network. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington > Sent: Saturday, May 07, 2005 12:28 AM > To: 'Keith McCloghrie'; isms@ietf.org > Subject: RE: [Isms] Rough Consensus Declaration: ISMS > Architecture is EK > > Hi Keith, > > I am well aware of the UDP vs TCP debate, and understand your > concerns. > > Personally, I think a UDP transport is, and has always been, important > for troubleshooting broken networks. However, network robustness has > changed dramatically since the late 80s. > > SNMP has also changed in terms of its use cases. MIB modules > originally provided limited amounts of information. But now tables > have grown in size, and MIB modules provide more information than > earlier MIB modules. Much more management/monitoring is done for > well-functioning networks. I think the advantages of larger messages > and flow control are warranted for this type of management. > > I still believe a UDP transport will be important for troubleshooting. > This could be provided by also having USM (with maybe a single root > user), but supporting a DTLS transport to supplement a TLS transport > would seem to make more sense, if TLS and DTLS can share a security > infrastructure. > > David Harrington > dbharrington@comcast.net > > > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Keith McCloghrie > > Sent: Friday, May 06, 2005 8:57 PM > > To: isms@ietf.org > > Subject: Re: [Isms] Rough Consensus Declaration: ISMS > > Architecture is EK > > > > Apparently, the people who voted for (including the maybe's and the > > not-against's) EK, believe that they voted not only for > encapsulating > > the keying but also for encapsulating SNMP messages. Assuming this > is > > true, then it seems to me that if one is forced to pay the > > price of TLS > > in order to have secure SNMP, then I no longer see any benefit in > > running SNMP over UDP. There are both advantages and disadvantages > of > > running SNMP over TCP; the advantages include larger messages and > flow > > control. For the disadvantages, all but one of them are inherent in > > encapsulating SNMP messages in TLS; the remaining one is the > > minor issue > > that both SNMP and TCP have reliability mechanisms, i.e., SNMP > engines > > should avoid having SNMP's retransmission timers fire before TCP's > > retransmission timers (see page 2 of RFC 3430). That one remaining > > disadvantage is negligible compared to larger messages and > > flow-control. > > Therefore, to define SNMP-over-DTLS-over-UDP is silly; the only > > sensible way of using TLS is to define SNMP-over-TLS-over-TCP. > > > > So, I believe the WG's choice of EK discards the perceived wisdom > > of the last 15+ years that UDP was the preferred transport mapping. > > Nevertheless, given that the WG has decided to do this, I think it > > should be made explicit by: > > > > - putting RFC 3430 on the standards track, > > - starting an update to remove the word "preferred" from RFC 3417, > > - not wasting any time on defining a SNMP-over-DTLS-over-UDP, > > > > Keith. > > > > PS. As a further observation, I will note that this has occurred in > a > > Security Area Working Group. How sad this all is. > > > > _______________________________________________ > > 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 Sat May 07 12:36:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUSHh-00081D-A9; Sat, 07 May 2005 12:36:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUSHg-000818-0S for isms@megatron.ietf.org; Sat, 07 May 2005 12:36:08 -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 MAA26441 for ; Sat, 7 May 2005 12:36:03 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUSWN-00064G-Cm for isms@ietf.org; Sat, 07 May 2005 12:51:19 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id j47GjR80027774 for ; Sat, 7 May 2005 09:45:27 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j47GcKvO010543 for ; Sat, 7 May 2005 11:38:21 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Sat, 7 May 2005 12:36:01 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF23810771C7C3@ma19exm01.e6.bcs.mot.com> From: Donati Andrew-MGIA0477 To: "'ietfdbh@comcast.net'" , "'Keith McCloghrie'" , isms@ietf.org Subject: RE: [Isms] Rough Consensus Declaration: ISMS Architecture is EK - Larger messages and flow control Date: Sat, 7 May 2005 12:36:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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 All, I follow this message board, but normally do not participate. I apologize if this in not the proper way to respond to the list or if this may be considered a bit off topic, but David and Keith brought up an excellent point that should be emphasized IMHO: >SNMP has also changed in terms of its use cases. MIB modules originally provided limited amounts of information. >But now tables have grown in size, and MIB modules provide more information than earlier MIB modules. Much more >management/monitoring is done for well-functioning networks. I think the advantages of larger messages >and flow control are warranted for this type of management. Having worked with SNMP for nearly 11 years a have to agree strongly about these points. More recently, network management has extended it reach from managing devices such as network routers, and switches at businesses to managing devices at residential areas (cable modems, FTTH PONs) that not only include data, but voice, and video as well. Also, the voice, video, and data contain detailed information such as usage statistics that are used for reports and billing. As a result, there is a need to update the SNMP protocol to handle more information. IMHO, a future security infrastructure should also be able to work with a future SNMP mechanism that can handle more information than it currently does. Thanks, Andy adonati@motorola.com -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Saturday, May 07, 2005 12:28 AM To: 'Keith McCloghrie'; isms@ietf.org Subject: RE: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Hi Keith, I am well aware of the UDP vs TCP debate, and understand your concerns. Personally, I think a UDP transport is, and has always been, important for troubleshooting broken networks. However, network robustness has changed dramatically since the late 80s. SNMP has also changed in terms of its use cases. MIB modules originally provided limited amounts of information. But now tables have grown in size, and MIB modules provide more information than earlier MIB modules. Much more management/monitoring is done for well-functioning networks. I think the advantages of larger messages and flow control are warranted for this type of management. I still believe a UDP transport will be important for troubleshooting. This could be provided by also having USM (with maybe a single root user), but supporting a DTLS transport to supplement a TLS transport would seem to make more sense, if TLS and DTLS can share a security infrastructure. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Keith McCloghrie > Sent: Friday, May 06, 2005 8:57 PM > To: isms@ietf.org > Subject: Re: [Isms] Rough Consensus Declaration: ISMS > Architecture is EK > > Apparently, the people who voted for (including the maybe's and the > not-against's) EK, believe that they voted not only for encapsulating > the keying but also for encapsulating SNMP messages. Assuming this is > true, then it seems to me that if one is forced to pay the > price of TLS > in order to have secure SNMP, then I no longer see any benefit in > running SNMP over UDP. There are both advantages and disadvantages of > running SNMP over TCP; the advantages include larger messages and flow > control. For the disadvantages, all but one of them are inherent in > encapsulating SNMP messages in TLS; the remaining one is the minor > issue that both SNMP and TCP have reliability mechanisms, i.e., SNMP engines > should avoid having SNMP's retransmission timers fire before TCP's > retransmission timers (see page 2 of RFC 3430). That one remaining > disadvantage is negligible compared to larger messages and > flow-control. Therefore, to define SNMP-over-DTLS-over-UDP is silly; > the only sensible way of using TLS is to define > SNMP-over-TLS-over-TCP. > > So, I believe the WG's choice of EK discards the perceived wisdom > of the last 15+ years that UDP was the preferred transport mapping. > Nevertheless, given that the WG has decided to do this, I think it > should be made explicit by: > > - putting RFC 3430 on the standards track, > - starting an update to remove the word "preferred" from RFC 3417, > - not wasting any time on defining a SNMP-over-DTLS-over-UDP, > > Keith. > > PS. As a further observation, I will note that this has occurred in a > Security Area Working Group. How sad this all is. > > _______________________________________________ > 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 Sat May 07 14:35:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUU9G-0005Q6-T5; Sat, 07 May 2005 14:35:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUU9F-0005Px-Ar for isms@megatron.ietf.org; Sat, 07 May 2005 14:35:33 -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 OAA04672 for ; Sat, 7 May 2005 14:35:31 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUUNz-00022O-Lx for isms@ietf.org; Sat, 07 May 2005 14:50:48 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j47IZL7u029667 for ; Sat, 7 May 2005 11:35:21 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sat, 7 May 2005 11:35:21 -0700 Message-ID: From: "McDonald, Ira" To: isms@ietf.org Subject: RE: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Date: Sat, 7 May 2005 11:35:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, Keith is apparently distorting the EK picture in order to push back on the rough concensus decision of the ISMS WG chairs. Just like plain UDP, DTLS does _not_ do packet reordering for application data. DLTS only ensures ordering during the session startup handshake. DTLS does ensure the data integrity of each application data packet. The SNMP application layer mechanism for detecting misordered packets would still be necessary. But, by design, DTLS _does_ share the same security mechanisms with TLS. It's worth noting that one of the co-editors of DTLS (Eric Rescorla) is also one of the co-editors of RFC2246bis (TLS/1.1) now being developed by the TLS WG and is also one of the co-chairs of the TLS WG. The TLS WG is now developing TLS with native SRP authentication (which solves the problem of assymetric client/server authentication across different protocol layers recently mentioned on this mailing list). Using SRP-6 (see the draft) this is accomplished _without_ modifying the order of the normal TLS handshake. The most recent TLS with SRP draft is (March 2005). A new SNMP security model for SNMP over TLS over TCP could also easily support SNMP over DTLS over UDP. The ISMS WG has frittered away eight months coming to a fragile architecture concensus. It's unreasonable to expect that the ISMS WG will define and move onto the IETF standards track any new SNMP security model any faster than the fairly mature DTLS and TLS with SRP definitions can be completed. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On > Behalf Of Keith McCloghrie > Sent: Friday, May 06, 2005 8:57 PM > To: isms@ietf.org > Subject: Re: [Isms] Rough Consensus Declaration: ISMS > Architecture is EK > > > Apparently, the people who voted for (including the maybe's and the > not-against's) EK, believe that they voted not only for encapsulating > the keying but also for encapsulating SNMP messages. Assuming this is > true, then it seems to me that if one is forced to pay the > price of TLS > in order to have secure SNMP, then I no longer see any benefit in > running SNMP over UDP. There are both advantages and disadvantages of > running SNMP over TCP; the advantages include larger messages and flow > control. For the disadvantages, all but one of them are inherent in > encapsulating SNMP messages in TLS; the remaining one is the > minor issue > that both SNMP and TCP have reliability mechanisms, i.e., SNMP engines > should avoid having SNMP's retransmission timers fire before TCP's > retransmission timers (see page 2 of RFC 3430). That one remaining > disadvantage is negligible compared to larger messages and > flow-control. > Therefore, to define SNMP-over-DTLS-over-UDP is silly; the only > sensible way of using TLS is to define SNMP-over-TLS-over-TCP. > > So, I believe the WG's choice of EK discards the perceived wisdom > of the last 15+ years that UDP was the preferred transport mapping. > Nevertheless, given that the WG has decided to do this, I think it > should be made explicit by: > > - putting RFC 3430 on the standards track, > - starting an update to remove the word "preferred" from RFC 3417, > - not wasting any time on defining a SNMP-over-DTLS-over-UDP, > > Keith. > > PS. As a further observation, I will note that this has occurred in a > Security Area Working Group. How sad this all is. > > _______________________________________________ > 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 Sat May 07 15:12:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUUiW-00027C-RI; Sat, 07 May 2005 15:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUUiU-000277-T5 for isms@megatron.ietf.org; Sat, 07 May 2005 15:11:58 -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 PAA08199 for ; Sat, 7 May 2005 15:11:57 -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 1DUUxF-0003TR-RK for isms@ietf.org; Sat, 07 May 2005 15:27:14 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 07 May 2005 12:11:49 -0700 X-IronPort-AV: i="3.92,164,1112598000"; d="scan'208"; a="261906088:sNHT66070988" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j47JBjPo016067; Sat, 7 May 2005 12:11:45 -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); Sat, 7 May 2005 12:11:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Date: Sat, 7 May 2005 12:11:41 -0700 Message-ID: Thread-Topic: [Isms] Rough Consensus Declaration: ISMS Architecture is EK Thread-Index: AcVTM8WBMSY2E0IxRFeJzS7v7RhdWgAAqurw From: "Khanh Nguyen \(khanhvn\)" To: "McDonald, Ira" , X-OriginalArrivalTime: 07 May 2005 19:11:42.0265 (UTC) FILETIME=[9A57DA90:01C55338] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 I think you misunderstood Keith. He didn't try to push back on the consensus in his last message. In fact, he did acknowledge the advantages of TLS over TCP. It was DTLS over UDP that he=20 found problems with, and he made some good points about that. Anyway, we may have many disagreements here, but let's not take them personally :) We all are here for a common goal, so let's work this out in a positive way. Khanh=20 > -----Original Message----- > From: McDonald, Ira >=20 > Hi, >=20 > Keith is apparently distorting the EK picture in order to=20 > push back on the rough concensus decision of the ISMS WG chairs. >=20 > Just like plain UDP, DTLS does _not_ do packet reordering for=20 > application data.=20 > DLTS only ensures ordering during the session startup=20 > handshake. DTLS does ensure the data integrity of each=20 > application data packet. The SNMP application layer=20 > mechanism for detecting misordered packets would still be necessary. >=20 > But, by design, DTLS _does_ share the same security=20 > mechanisms with TLS. =20 >=20 > It's worth noting that one of the co-editors of DTLS (Eric=20 > Rescorla) is also one of the co-editors of RFC2246bis=20 > (TLS/1.1) now being developed by the TLS WG and is also one=20 > of the co-chairs of the TLS WG. >=20 > The TLS WG is now developing TLS with native SRP=20 > authentication (which solves the problem of assymetric=20 > client/server authentication across different protocol layers=20 > recently mentioned on this mailing list). Using SRP-6 (see the > draft) > this is accomplished _without_ modifying the order of the=20 > normal TLS handshake. > The most recent TLS with SRP draft is=20 > (March 2005). >=20 > A new SNMP security model for SNMP over TLS over TCP could=20 > also easily support SNMP over DTLS over UDP. >=20 > The ISMS WG has frittered away eight months coming to a=20 > fragile architecture concensus. It's unreasonable to expect=20 > that the ISMS WG will define and move onto the IETF standards=20 > track any new SNMP security model any faster than the fairly=20 > mature DTLS and TLS with SRP definitions can be completed. >=20 > Cheers, > - Ira =20 >=20 > Ira McDonald (Musician / Software Architect) Blue Roof Music=20 > / High North Inc PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com >=20 > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org]On > > Behalf Of Keith McCloghrie > > Sent: Friday, May 06, 2005 8:57 PM > > To: isms@ietf.org > > Subject: Re: [Isms] Rough Consensus Declaration: ISMS=20 > Architecture is=20 > > EK > >=20 > >=20 > > Apparently, the people who voted for (including the maybe's and the > > not-against's) EK, believe that they voted not only for=20 > encapsulating=20 > > the keying but also for encapsulating SNMP messages. =20 > Assuming this is=20 > > true, then it seems to me that if one is forced to pay the price of=20 > > TLS in order to have secure SNMP, then I no longer see any=20 > benefit in=20 > > running SNMP over UDP. There are both advantages and=20 > disadvantages of=20 > > running SNMP over TCP; the advantages include larger=20 > messages and flow=20 > > control. For the disadvantages, all but one of them are=20 > inherent in=20 > > encapsulating SNMP messages in TLS; the remaining one is the minor=20 > > issue that both SNMP and TCP have reliability mechanisms,=20 > i.e., SNMP=20 > > engines should avoid having SNMP's retransmission timers=20 > fire before=20 > > TCP's retransmission timers (see page 2 of RFC 3430). That one=20 > > remaining disadvantage is negligible compared to larger=20 > messages and=20 > > flow-control. > > Therefore, to define SNMP-over-DTLS-over-UDP is silly; the only=20 > > sensible way of using TLS is to define SNMP-over-TLS-over-TCP. > >=20 > > So, I believe the WG's choice of EK discards the perceived=20 > wisdom of=20 > > the last 15+ years that UDP was the preferred transport mapping. > > Nevertheless, given that the WG has decided to do this, I think it=20 > > should be made explicit by: > >=20 > > - putting RFC 3430 on the standards track, > > - starting an update to remove the word "preferred" from RFC 3417, > > - not wasting any time on defining a SNMP-over-DTLS-over-UDP, > >=20 > > Keith. > >=20 > > PS. As a further observation, I will note that this has=20 > occurred in a=20 > > Security Area Working Group. How sad this all is. > >=20 > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat May 07 16:08:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUVai-0001oC-TD; Sat, 07 May 2005 16:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUVae-0001nu-W1 for isms@megatron.ietf.org; Sat, 07 May 2005 16:07:59 -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 QAA13093 for ; Sat, 7 May 2005 16:07:55 -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 1DUVpQ-0005lI-OG for isms@ietf.org; Sat, 07 May 2005 16:23:13 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id A4C91E0063; Sat, 7 May 2005 16:07:51 -0400 (EDT) To: ietfdbh@comcast.net References: <200505070439.AAA13375@ietf.org> From: Sam Hartman Date: Sat, 07 May 2005 16:07:51 -0400 In-Reply-To: <200505070439.AAA13375@ietf.org> (David B. Harrington's message of "Sat, 7 May 2005 00:38:55 -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: 7d33c50f3756db14428398e2bdedd581 Cc: isms@ietf.org Subject: [Isms] Wehn the network doesn't. 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, If DTLS has significant session setup requirements, David> then the USM/UDP might still be a better choice for David> troubleshooting. We should consider the applicability of David> various solutions for troubleshooting a broken network, and David> for managing a non-broken network. I'd really like it if someone would work on some requirements for SNMP security when the network is down/broken. What do you want to be able to do? Is being able to push out updates for a few users while the network is functioning enough? Is keeping long-lived sessions alive enough? I honestly have no idea, but I'm quite sure I cannot provide useful suggestions for security protocols until you decide what the requirements are. I think guessing at the requirements for working networks will probably yield acceptable results but I think the security community needs significant help from the management community on requirements for broken networks. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat May 07 16:41:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUW6z-0006B5-Cp; Sat, 07 May 2005 16:41:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUW6w-0006Aw-W1 for isms@megatron.ietf.org; Sat, 07 May 2005 16:41:19 -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 QAA15920 for ; Sat, 7 May 2005 16:41:17 -0400 (EDT) Received: from ib1e8.i.pppool.de ([85.73.177.232] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUWLh-000735-Rw for isms@ietf.org; Sat, 07 May 2005 16:56:35 -0400 Received: by boskop.local (Postfix, from userid 501) id BADE12DC6EA; Sat, 7 May 2005 22:40:56 +0200 (CEST) Date: Sat, 7 May 2005 22:40:56 +0200 From: Juergen Schoenwaelder To: Sam Hartman Subject: Re: [Isms] Wehn the network doesn't. Message-ID: <20050507204056.GA4382@boskop.local> Mail-Followup-To: Sam Hartman , isms@ietf.org References: <200505070439.AAA13375@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Sat, May 07, 2005 at 04:07:51PM -0400, Sam Hartman wrote: > I think guessing at the requirements for working > networks will probably yield acceptable results but I think the > security community needs significant help from the management > community on requirements for broken networks. The management community may have different opinions on this and thus the question is rather difficult to answer. Almost all bigger networks I am familiar with run management traffic on a logically separate network, sometimes even physically separate. The degree of separation of the management network from the production network has impact on how concerned you are about running SNMP over a broken network... A related question is to what extend SNMP tools are used in situations where the network is broken to debug and repair things. I know many networks where SNMP is used to collect statistics and to some extend to spot problems but once there is real trouble, people either resort to the CLI to repair things (which requires TCP of course) or they pick up the phone to instruct some human being to do what needs to be done. /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 Sun May 08 00:30:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUdQc-0005mc-N1; Sun, 08 May 2005 00:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUdQb-0005mI-1j for isms@megatron.ietf.org; Sun, 08 May 2005 00:30:05 -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 AAA17711 for ; Sun, 8 May 2005 00:30:02 -0400 (EDT) Message-Id: <200505080430.AAA17711@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUdfQ-0000Ci-3Y for isms@ietf.org; Sun, 08 May 2005 00:45:25 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005050804295301400fuqnee>; Sun, 8 May 2005 04:29:54 +0000 From: "David B Harrington" To: "'Sam Hartman'" Date: Sun, 8 May 2005 00:29:47 -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: Thread-Index: AcVTQH9gjFTRPCNaSCexEOIrdbvfQgAQ5v2w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: [Isms] RE: Wehn the network doesn't. 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 think the strength of security for SNMP in a broken network needs to be fairly equivalent to the strength of security provided in a non-broken network. There are a few assumptions about working in a broken network, if SNMP is in-band (run over the broken network) rather than out of band: 1) security should not be dependent on a third party who may not be reachable via the broken network, 2) it is desirable to receive some packets from the managed system, so at least partial status can be deterined, even if all packets cannot be delivered, and packets may not be delivered in order, and 3) it is acceptable to have only a limited numbers of users able to be authenticated, e.g. root, instead of a large number of users, when the network is broken. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Saturday, May 07, 2005 4:08 PM > To: ietfdbh@comcast.net > Cc: 'Keith McCloghrie'; isms@ietf.org > Subject: Wehn the network doesn't. > > >>>>> "David" == David B Harrington writes: > > David> Hi, If DTLS has significant session setup requirements, > David> then the USM/UDP might still be a better choice for > David> troubleshooting. We should consider the applicability of > David> various solutions for troubleshooting a broken network, and > David> for managing a non-broken network. > > I'd really like it if someone would work on some requirements for SNMP > security when the network is down/broken. What do you want to be able > to do? Is being able to push out updates for a few users while the > network is functioning enough? Is keeping long-lived sessions alive > enough? > > I honestly have no idea, but I'm quite sure I cannot provide useful > suggestions for security protocols until you decide what the > requirements are. I think guessing at the requirements for working > networks will probably yield acceptable results but I think the > security community needs significant help from the management > community on requirements for broken networks. > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun May 08 06:33:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUj5v-0008FF-Dy; Sun, 08 May 2005 06:33:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUj5t-0008Ce-MQ for isms@megatron.ietf.org; Sun, 08 May 2005 06:33:05 -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 GAA02208 for ; Sun, 8 May 2005 06:33:03 -0400 (EDT) Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUjKl-0002Wx-NC for isms@ietf.org; Sun, 08 May 2005 06:48:29 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j48AWsLs021923; Sun, 8 May 2005 10:32:54 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j48AWmhU027704; Sun, 8 May 2005 10:32:54 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005050803325318956 ; Sun, 08 May 2005 03:32:53 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 8 May 2005 03:32:53 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 8 May 2005 03:32:53 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 8 May 2005 06:32:52 -0400 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] Wehn the network doesn't. Date: Sun, 8 May 2005 06:32:17 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C592901196200@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Wehn the network doesn't. Thread-Index: AcVTQKVOKuP0j2N5QAaavL+O8HFFhwAeAOSg From: "Blumenthal, Uri" To: "Sam Hartman" , X-OriginalArrivalTime: 08 May 2005 10:32:52.0457 (UTC) FILETIME=[49F1DD90:01C553B9] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 David> Hi, If DTLS has significant session setup requirements, David> then the USM/UDP might still be a better choice for David> troubleshooting. We should consider the applicability of David> various solutions for troubleshooting a broken network, and David> for managing a non-broken network. > I'd really like it if someone would work on some requirements for SNMP > security when the network is down/broken.=20 Let me mention that the original SNMP design was based on the concept of "got to deal with broken networks". It's precisely the network reliability and usage of SNMP for non-firefighting purposes that (IMHO) allows this WG to exist. > What do you want to be able to do?=20 Probably access devices in trouble[d location] securely, ask it questions, MAYBE also set some simple parameters - but today it's usually done via CLI in the unlikely case network turns ugly... > Is being able to push out updates for a few users > while the network is functioning enough?=20 I think - quite enough. > Is keeping long-lived sessions alive enough? I think - enough. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun May 08 06:42:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUjFT-0000oR-SY; Sun, 08 May 2005 06:42:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUjFS-0000oH-Rb for isms@megatron.ietf.org; Sun, 08 May 2005 06:42:58 -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 GAA02716 for ; Sun, 8 May 2005 06:42:56 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUjUM-0002eY-39 for isms@ietf.org; Sun, 08 May 2005 06:58:22 -0400 Received: from pc6 (1Cust202.tnt15.lnd4.gbr.da.uu.net [62.188.144.202]) by astro.systems.pipex.net (Postfix) with SMTP id 0CB80E000129; Sun, 8 May 2005 11:42:44 +0100 (BST) Message-ID: <00bb01c553b1$bc46cac0$0601a8c0@pc6> From: "Tom Petch" To: "'Sam Hartman'" References: <200505080430.AAA17711@ietf.org> Subject: Re: [Isms] RE: Wehn the network doesn't. Date: Sun, 8 May 2005 11:37:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 see people resorting to Telnet in a broken network only because SNMP set operations do not have the necessary security; secure SNMP and the Telnet will diminish. But the session setup, including any security exhanges, needs to be simple enough to work in a less than reliable network ie an 8-way handshake (eg) is likely to fail. I think the weakness of TCP is that it does things we do not need (sequencing, flow control), does not do what we need (security) and taken together we may need an excessive number of messages before anything useful can happen. We need sessions - that has been axiomatic for months - but that does not mean TCP; as has been pointed out before, our session needs could be achieved by suitable data in the PDU header, suitable secured. Tom Petch ----- Original Message ----- From: "David B Harrington" To: "'Sam Hartman'" Cc: Sent: Sunday, May 08, 2005 6:29 AM Subject: [Isms] RE: Wehn the network doesn't. > Hi Sam, > > I think the strength of security for SNMP in a broken network needs to > be fairly equivalent to the strength of security provided in a > non-broken network. > > There are a few assumptions about working in a broken network, if SNMP > is in-band (run over the broken network) rather than out of band: > 1) security should not be dependent on a third party who may not be > reachable via the broken network, > 2) it is desirable to receive some packets from the managed system, so > at least partial status can be deterined, even if all packets cannot > be delivered, and packets may not be delivered in order, and > 3) it is acceptable to have only a limited numbers of users able to be > authenticated, e.g. root, instead of a large number of users, when the > network is broken. > > David Harrington > dbharrington@comcast.net > > > -----Original Message----- > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > Sent: Saturday, May 07, 2005 4:08 PM > > To: ietfdbh@comcast.net > > Cc: 'Keith McCloghrie'; isms@ietf.org > > Subject: Wehn the network doesn't. > > > > >>>>> "David" == David B Harrington writes: > > > > David> Hi, If DTLS has significant session setup requirements, > > David> then the USM/UDP might still be a better choice for > > David> troubleshooting. We should consider the applicability of > > David> various solutions for troubleshooting a broken network, > and > > David> for managing a non-broken network. > > > > I'd really like it if someone would work on some requirements for > SNMP > > security when the network is down/broken. What do you want to be > able > > to do? Is being able to push out updates for a few users while the > > network is functioning enough? Is keeping long-lived sessions alive > > enough? > > > > I honestly have no idea, but I'm quite sure I cannot provide useful > > suggestions for security protocols until you decide what the > > requirements are. I think guessing at the requirements for working > > networks will probably yield acceptable results but I think the > > security community needs significant help from the management > > community on requirements for broken networks. > > > > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun May 08 06:43:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUjFX-0000op-1D; Sun, 08 May 2005 06:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUjFT-0000oM-O3 for isms@megatron.ietf.org; Sun, 08 May 2005 06:42:59 -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 GAA02721 for ; Sun, 8 May 2005 06:42:57 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUjUM-0002ec-4N for isms@ietf.org; Sun, 08 May 2005 06:58:23 -0400 Received: from pc6 (1Cust202.tnt15.lnd4.gbr.da.uu.net [62.188.144.202]) by astro.systems.pipex.net (Postfix) with SMTP id 29A6DE0000A5 for ; Sun, 8 May 2005 11:42:49 +0100 (BST) Message-ID: <00bc01c553b1$bd2a25e0$0601a8c0@pc6> From: "Tom Petch" To: References: Date: Sun, 8 May 2005 11:38:10 +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: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] A picture is worth a 1000 words 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 would find it most helpful at this stage to have a picture of the way TLSM/TMSM fits in with the architecture of SNMP (as in RFC 3411 s3.1.3) ie a follow up to "TODO: Insert drawing here..." from SNMPv3 Transport Mapping Security Model section 3.2 Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun May 08 13:09:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUpHM-0005cm-LU; Sun, 08 May 2005 13:09:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUpHL-0005ch-Ik for isms@megatron.ietf.org; Sun, 08 May 2005 13:09:19 -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 NAA29974 for ; Sun, 8 May 2005 13:09:16 -0400 (EDT) Message-Id: <200505081709.NAA29974@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUpWH-0000z1-4M for isms@ietf.org; Sun, 08 May 2005 13:24:46 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <20050508170908013004p88de>; Sun, 8 May 2005 17:09:08 +0000 From: "David B Harrington" To: "'Tom Petch'" , Subject: RE: [Isms] A picture is worth a 1000 words Date: Sun, 8 May 2005 13:09:02 -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: <00bc01c553b1$bd2a25e0$0601a8c0@pc6> Thread-Index: AcVTuwSIFOCCZIMiSjSiM3IxgSZWfwAJl7kA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab 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, I hate doing ASCII art, but here you go. USM approach: The security model is encapsulated by the messaging model, because the messaging model needs to (for incoming messages) 1) decode the ASN.1 (messaging model) 2) determine the SNMP security model and parameters (messaging model) 3) decrypt the encrypted portions of the message (security model) 4) translate parameters to model-independent parameters (security model) 5) determine which application should get the decrypted portions (messaging model), and 6) pass on the decrypted portions with model-independent parameters. This is largely dependent on having SNMP-specific message security and parameters. -------------------------------------------------- | | | --------------------- ------------------ | | | SNMP applications | <--> | access control | | | --------------------- ------------------ | | ^ | | | v | --------------------------------------------- | | ------------------ | | SNMP messaging <--> | decryption + | | | | translation | | | ------------------ | | --------------------------------------------- | | ^ | | | v | -----------------------------------------------| | | transport mapping | | -----------------------------------------------| | ^ | | | v | -----------------------------------------------| | | transport layer | | -----------------------------------------------| TLSM approach: The order of the steps differ and may be handled by different subsystems: 1) decrypt the encrypted portions of the message (transport layer) 2) determine the SNMP security model and parameters (transport mapping) 3*) translate parameters to model-independent parameters (transport mapping) 4) decode the ASN.1 (messaging model) 5) determine which application should get the decrypted portions (messaging model) 6*) translate parameters to model-independent parameters (security model) 7) pass on the decrypted portions with model-independent security parameters This is largely based on having non-SNMP-specific message security and parameters. The transport mapping model might provide the translation from (e.g.) TLS user to securityName in step 3, OR The TLS user might be passed to the messaging model to pass to a TLSM/TMSM security model to do the translation in step 6, if the WG decides all translations should use the same translation table (e.g. the USM MIB). -------------------------------------------------- | | | --------------------- ------------------ | | | SNMP applications | <--> | access control | | | --------------------- ------------------ | | ^ | | | v | --------------------------------------------- | | ------------------ | | SNMP messaging <--> | translation* | | | ------------------ | |---------------------------------------------- | | ^ | | | v | -----------------------------------------------| | ------------------ | | transport mapping <--> | translation* | | | ------------------ | | -----------------------------------------------| | ^ | | | v | -----------------------------------------------| | ------------------ | | transport layer <--> | decryption | | | ------------------ | | -----------------------------------------------| Hope this helps, David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Tom Petch > Sent: Sunday, May 08, 2005 5:38 AM > To: isms@ietf.org > Subject: [Isms] A picture is worth a 1000 words > > I would find it most helpful at this stage to have a picture > of the way > TLSM/TMSM fits in with the > architecture of SNMP (as in RFC 3411 s3.1.3) ie a follow up to > > "TODO: Insert drawing here..." > > from > > SNMPv3 Transport Mapping Security Model section 3.2 > > Tom Petch > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun May 08 16:28:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUsO7-000597-Jx; Sun, 08 May 2005 16:28:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUsO6-00057b-Ih for isms@megatron.ietf.org; Sun, 08 May 2005 16:28:30 -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 QAA28329 for ; Sun, 8 May 2005 16:28:28 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUsd4-0007pM-Pi for isms@ietf.org; Sun, 08 May 2005 16:43:59 -0400 Received: from pc6 (1Cust224.tnt14.lnd4.gbr.da.uu.net [62.188.143.224]) by astro.systems.pipex.net (Postfix) with SMTP id A22FFE000087; Sun, 8 May 2005 21:28:18 +0100 (BST) Message-ID: <04c801c55403$88590e60$0601a8c0@pc6> From: "Tom Petch" To: , References: <20050508170910.E6515E000086@duelling.systems.pipex.net> Subject: Re: [Isms] A picture is worth a 1000 words Date: Sun, 8 May 2005 21:24: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: 0.1 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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 Many thanks for a most prompt response, and for the ASCII; I didn't say but it was my preference. Tom Petch ----- Original Message ----- From: "David B Harrington" To: "'Tom Petch'" ; Sent: Sunday, May 08, 2005 7:09 PM Subject: RE: [Isms] A picture is worth a 1000 words > Hi, > > I hate doing ASCII art, but here you go. > > USM approach: > > The security model is encapsulated by the messaging model, because the > messaging model needs to (for incoming messages) > 1) decode the ASN.1 (messaging model) > 2) determine the SNMP security model and parameters (messaging model) > 3) decrypt the encrypted portions of the message (security model) > 4) translate parameters to model-independent parameters (security > model) > 5) determine which application should get the decrypted portions > (messaging model), and > 6) pass on the decrypted portions with model-independent parameters. > This is largely dependent on having SNMP-specific message security and > parameters. > > -------------------------------------------------- > | | > | --------------------- ------------------ | > | | SNMP applications | <--> | access control | | > | --------------------- ------------------ | > | ^ > | | > | v > | --------------------------------------------- | > | ------------------ | > | SNMP messaging <--> | decryption + | | > | | translation | | > | ------------------ | > | --------------------------------------------- | > | ^ > | | > | v > | -----------------------------------------------| > | | transport mapping | > | -----------------------------------------------| > | ^ > | | > | v > | -----------------------------------------------| > | | transport layer | > | -----------------------------------------------| > > > TLSM approach: > > The order of the steps differ and may be handled by different > subsystems: > 1) decrypt the encrypted portions of the message (transport layer) > 2) determine the SNMP security model and parameters (transport > mapping) > 3*) translate parameters to model-independent parameters (transport > mapping) > 4) decode the ASN.1 (messaging model) > 5) determine which application should get the decrypted portions > (messaging model) > 6*) translate parameters to model-independent parameters (security > model) > 7) pass on the decrypted portions with model-independent security > parameters > This is largely based on having non-SNMP-specific message security and > parameters. > > The transport mapping model might provide the translation from (e.g.) > TLS user to securityName in step 3, OR > The TLS user might be passed to the messaging model to pass to a > TLSM/TMSM security model to do the translation in step 6, if the WG > decides all translations should use the same translation table (e.g. > the USM MIB). > > -------------------------------------------------- > | | > | --------------------- ------------------ | > | | SNMP applications | <--> | access control | | > | --------------------- ------------------ | > | ^ > | | > | v > | --------------------------------------------- | > | ------------------ | > | SNMP messaging <--> | translation* | | > | ------------------ | > |---------------------------------------------- | > | ^ > | | > | v > | -----------------------------------------------| > | ------------------ | > | transport mapping <--> | translation* | | > | ------------------ | > | -----------------------------------------------| > | ^ > | | > | v > | -----------------------------------------------| > | ------------------ | > | transport layer <--> | decryption | | > | ------------------ | > | -----------------------------------------------| > > Hope this helps, > David Harrington > dbharrington@comcast.net > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Tom Petch > > Sent: Sunday, May 08, 2005 5:38 AM > > To: isms@ietf.org > > Subject: [Isms] A picture is worth a 1000 words > > > > I would find it most helpful at this stage to have a picture > > of the way > > TLSM/TMSM fits in with the > > architecture of SNMP (as in RFC 3411 s3.1.3) ie a follow up to > > > > "TODO: Insert drawing here..." > > > > from > > > > SNMPv3 Transport Mapping Security Model section 3.2 > > > > Tom Petch > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 09 12:21:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVB12-0004FU-6f; Mon, 09 May 2005 12:21:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVB10-0004FM-Dp for isms@megatron.ietf.org; Mon, 09 May 2005 12:21:54 -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 MAA02111 for ; Mon, 9 May 2005 12:21:51 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVBG7-0007GX-2i for isms@ietf.org; Mon, 09 May 2005 12:37:33 -0400 Received: from pc6 (1Cust77.tnt27.lnd4.gbr.da.uu.net [62.188.154.77]) by blaster.systems.pipex.net (Postfix) with SMTP id 14B99E000198; Mon, 9 May 2005 17:21:39 +0100 (BST) Message-ID: <010401c554aa$3d4da780$0601a8c0@pc6> From: "Tom Petch" To: , "Sam Hartman" References: Subject: Re: [Isms] Thoughts on Encapsulation Date: Mon, 9 May 2005 15:39:41 +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: f66b12316365a3fe519e75911daf28a8 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 Sam, In which part of your dichotomy would you place draft-ietf-tls-psk-08.txt Tom Petch ----- Original Message ----- From: "Sam Hartman" To: Sent: Thursday, May 05, 2005 2:11 PM Subject: [Isms] Thoughts on Encapsulation > > The following thoughts are presented as an individual. I'm trying to > give a background on all the sorts of things you could do with > encapsulation for SNMP. I may miss some things and I may over > simplify things. > > > So there are several different security technologies you might want to > support. I'd argue that you probably want to support more than one. > > 1) TLS/SASL. The combination of TLS and SASL go well together. You > typically use one or both. In one common mode, TLS is used to > authenticate the server (responder) to the client. The server has > a cert and the client does not. You then use SASL to authenticate > the client to the server. TLS is used to protect the session. > Another common mode supported by the TLS+SASL option only involves > SASL. You use a SASL security layer that provides mutual > authentication to provide both data confidentiality and integrity > to the session and to authenticate both parties. This SASL-only > mode is used by Kerberos. A third mode involves only TLS. Both > the client and server have certificates. This actually often looks > like the first mode because the SASL external mechanism is used to > signal that TLS has provided the client authentication. > > 2) Ssh. This provides for authentication using public keys, Kerberos > and passwords among other options. I'd look at the netconf over > ssh document as a starting point for how to do this. > > 3) DTLS. DTLS is probably going to be important because it provides > UDP support. The catch with DTLS is going to be figuring out how > to authenticate the client to the server if the client doesn't have > credentials. You could use SASL while not supporting security > layers but doing so will make the Kerberos camp quite unhappy. > > I'd also recommend trying to treat notifications as no different than > any other message. Try two approaches and see which works out best. > The first is to try using the existing security context for > notifications. The second is to try treating notifications as their > own security context; most of the mechanisms discussed work if you let > the notifier be the client/initiator. The party receiving > notifications will need credentials but that's actually probably OK. > > Here are some things I'd recommend against. Note that these > recommendations are not things that would cause me to reject a > solution so much as things that would cause me as an individual to > have a bunch of questions about why you were taking that approach. > > 1) Supporting TLS and SASL without supporting all three modes as > described above. > > 2) Using ssh keys but not ssh. > > 3) Assuming that SASL can be used in a datagram-like manner without > ordering and reliable delivery. > > 4) Using Kerberos directly (*) > > 5) Using/recommending the Kerberos TLS ciphersuites. The Kerberos ssh > support is fine though. > > 6) Using raw public-key operations. > > 7) Extracting the session key from a SASL mechanism. That's just not > supported by SASL implementations. > > (*) It may be that SASL is not good enough for the datagram case and > thus you may want to provide for future extension to GSS. That might > look a lot to some like raw Kerberos; it certainly would be > complicated. I'm a bit concerned that UDP support is going to end up > complicated. > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 09 12:55:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVBXd-0000sl-CU; Mon, 09 May 2005 12:55:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVBXb-0000sL-Nh for isms@megatron.ietf.org; Mon, 09 May 2005 12:55:36 -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 MAA05029 for ; Mon, 9 May 2005 12:55:33 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVBmk-0008Tc-4q for isms@ietf.org; Mon, 09 May 2005 13:11:15 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 5D6FFE0063; Mon, 9 May 2005 12:55:29 -0400 (EDT) To: "Tom Petch" Subject: Re: [Isms] Thoughts on Encapsulation References: <010401c554aa$3d4da780$0601a8c0@pc6> From: Sam Hartman Date: Mon, 09 May 2005 12:55:29 -0400 In-Reply-To: <010401c554aa$3d4da780$0601a8c0@pc6> (Tom Petch's message of "Mon, 9 May 2005 15:39:41 +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: 93238566e09e6e262849b4f805833007 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> Sam, In which part of your dichotomy would you place Tom> draft-ietf-tls-psk-08.txt I don't think it fits well into ISMS. You *could* ues it. If you did I'd expect you to then use SASL external. But it only works well if you already have TLS PSKs configured somehow. It doesn't work well with RADIUS or other existing mechanisms. Same goes for any TLS SRP solution only more so. Don't get me wrong: if your organization wants to deploy SRP or TLS PSKs that's great. You'll get better security; you'll have all sorts of warm fuzzy feelings. You won't be using the infrastructure you have today though and supporting existing infrastructure is the goal of ISMS. Naturally I'm going to be concerned if we come up with an ISMS solution that won't work with potential future infrastructures. I don't see that happening though. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 09 14:22:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVCtp-0006J8-TH; Mon, 09 May 2005 14:22:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVCto-0006J3-6u for isms@megatron.ietf.org; Mon, 09 May 2005 14:22:36 -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 OAA14389 for ; Mon, 9 May 2005 14:22:35 -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 1DVD8y-0003Qh-1S for isms@ietf.org; Mon, 09 May 2005 14:38:16 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 7F2B111D731; Mon, 9 May 2005 11:22:31 -0700 (PDT) From: Wes Hardaker To: Sam Hartman Subject: Re: [Isms] Wehn the network doesn't. Organization: Sparta References: <200505070439.AAA13375@ietf.org> Date: Mon, 09 May 2005 11:22:30 -0700 In-Reply-To: (Sam Hartman's message of "Sat, 07 May 2005 16:07:51 -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: b7b9551d71acde901886cc48bfc088a6 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Sat, 07 May 2005 16:07:51 -0400, Sam Hartman said: Sam> I'd really like it if someone would work on some requirements for Sam> SNMP security when the network is down/broken. What do you want Sam> to be able to do? Is being able to push out updates for a few Sam> users while the network is functioning enough? Is keeping Sam> long-lived sessions alive enough? When good networks go bad... The endless discussion. The problem with this discussion is that there is very little data to back it up. However, I suspect that everyone will at least agree that the following breakage-line is likely to be true. It's just that the points along the line aren't accurately placed because of the lack of data: Good network <-> Slow Network TCP Works <-> Slower network UDP works <-> Dead The problem is that determining at which point TCP and UDP each stop working is subject to a large debate that I don't think it would be productive to have. However, I don't know if we can fully avoid it since we're trying to decide if we need a secure UDP solution. The problems: 1) Originally everyone believed that TCP would quickly die. Fortunately it turned out that it survived better than people believed and more recent improvements in TCP have improved the situation greatly as well. Thus TCP now functions in networks where it didn't use to. But, it's still not the 2) Everyone believes that UDP functions better in broken networks, but realistically it's still not great either. It still suffers from problems and some people believe that it functions fantastically. It doesn't. It just barely works. But it does work better than TCP, though probably not by huge amounts. It is here that very little recent data exists, at least that I've seen, about how UDP and TCP compare and how close on the above line those two nodes would appear. I suspect some people would even argue that they are in the same place, though I'd personally disagree (especially without data). Does anyone know of a recent study comparing the two? There's got to be one, but I don't have a reference to one. I will say that anyone who has tried to use ssh/telnet in a really poorly behaving network is probably using it while it's still almost functioning. I know one of the most common things to do when your TCP connection is going bad is you quit it and restart. As much of a pain as that is, because it requires a brand new connection potentially with a new cryptographic exchange, it often fixes a connection faster than it would have been fixed on its own. Fortunately, I think that more advancements in TCP will happen in the next decade that may fix these problems. But that's still a guess and it is actually unknown if improvements in highly lossy networks will happen. I certainly hope so. 3) "Networks never go bad anymore". Although this was probably the case in the late 90s and early 00s where outages were less and less likely, I'd argue we're just reaching the point where it's going to get worse again. There certainly was a period where less and less people worried about management in troubled networks because it was increasingly rare. However, as we head more and more into wireless network infrastructures I think we're only going to be back into an era where we will have to try and fix networks that have died. Anyone who has been to frequent IETF conferences knows that wireless networks aren't perfect much of the time. Fortunately in those cases, there are backplanes which are wired. However, I suspect in the future more and more networks will be deployed where you may not be able to physically back-path a device because the only connections to it will be wireless. Certainly if MANET and similar environments live up to their potential this will be the case. And it's for this reason that I think we still need to be able to do management over protocols that can handle heavily-lossy networks. Whether this is a new super-TCP mode or falling onto UDP when things go bad, I don't know. I'd rather not bet on a new super-TCP mode until it exists and thus I think it's worth our trouble to define a SNMP-over-secure-UDP solution as a potential. Of course, if operators then deploy huge infrastructures and modes that require 12 round trips and connections to a centralized keying system at all times then that's their own fault. But we should offer the potential for something better in those bad times. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 09 14:31:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVD2F-0007hf-1c; Mon, 09 May 2005 14:31:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVD2D-0007ha-Vd for isms@megatron.ietf.org; Mon, 09 May 2005 14:31:18 -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 OAA15351 for ; Mon, 9 May 2005 14:31:16 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVDHM-0003oP-00 for isms@ietf.org; Mon, 09 May 2005 14:46:58 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 09 May 2005 11:30:39 -0700 X-IronPort-AV: i="3.92,169,1112598000"; d="scan'208"; a="635048597:sNHT674854186" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j49ITwEv020703; Mon, 9 May 2005 11:30:36 -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); Mon, 9 May 2005 11:30:35 -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] Thoughts on Encapsulation Date: Mon, 9 May 2005 11:30:33 -0700 Message-ID: Thread-Topic: [Isms] Thoughts on Encapsulation Thread-Index: AcVUuEpK+oZwioX9RyaRB8/MJsL3SQAAfaRg From: "Khanh Nguyen \(khanhvn\)" To: "Sam Hartman" , "Tom Petch" X-OriginalArrivalTime: 09 May 2005 18:30:35.0198 (UTC) FILETIME=[30AECDE0:01C554C5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 > -----Original Message----- > From: Sam Hartman > > Tom Petch writes: > Tom> Sam, In which part of your dichotomy would you place > Tom> draft-ietf-tls-psk-08.txt TLS-PSK is an interesting development. I cited it in the LPSK=20 proposal as it can be the one of the most straightforward ways=20 to implement LPSK. Its advantage is that binding b/w authen=20 and encryp is built-in. Some disadvantages are: + Weak protection against offline dictionary attacks. (EKE, SRP... have been developed to solve this problem) + Transport-dependent (TLS). There is no equivalent method=20 defined for DTLS, SSH, etc.=20 + Not a TLS standard yet. Those disadvantages are not really grave (e.g. dict attacks can be prevented by long passwds), so it may still be a viable=20 option, especially if it become a standard.=20 > I don't think it fits well into ISMS. You *could* ues it. =20 > If you did I'd expect you to then use SASL external. But it=20 > only works well if you already have TLS PSKs configured=20 > somehow. It doesn't work well with RADIUS or other existing=20 > mechanisms. >=20 > Same goes for any TLS SRP solution only more so. >=20 > Don't get me wrong: if your organization wants to deploy SRP=20 > or TLS PSKs that's great. You'll get better security; you'll=20 > have all sorts of warm fuzzy feelings. You won't be using=20 > the infrastructure you have today though and supporting=20 > existing infrastructure is the goal of ISMS. The above issues are among problems that LPSK tries to solve. LPSK uses the localized community strings and/or user passwords=20 as the shared secrets for PSK authentication. This way you can=20 leverage the existing configurations of SNMPv1/USM infrastructure. The use of user credentials to generage LPSK values also=20 facilitates AAA integration. Regards. Khanh >=20 > Naturally I'm going to be concerned if we come up with an=20 > ISMS solution that won't work with potential future=20 > infrastructures. I don't see that happening though. >=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 Mon May 09 14:53:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVDNv-00070D-5h; Mon, 09 May 2005 14:53:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVDNt-000708-9M for isms@megatron.ietf.org; Mon, 09 May 2005 14:53:41 -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 OAA18672 for ; Mon, 9 May 2005 14:53:39 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVDd2-00052f-Ic for isms@ietf.org; Mon, 09 May 2005 15:09:21 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7E53CE0063; Mon, 9 May 2005 14:53:34 -0400 (EDT) To: Wes Hardaker Subject: Re: [Isms] Wehn the network doesn't. References: <200505070439.AAA13375@ietf.org> From: Sam Hartman Date: Mon, 09 May 2005 14:53:34 -0400 In-Reply-To: (Wes Hardaker's message of "Mon, 09 May 2005 11:22:30 -0700") 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: 73734d43604d52d23b3eba644a169745 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Wes" == Wes Hardaker writes: Wes> The problem is that determining at which point TCP and UDP Wes> each stop working is subject to a large debate that I don't Wes> think it would be productive to have. However, I don't know Wes> if we can fully avoid it since we're trying to decide if we Wes> need a secure UDP solution. So, I think determining this in terms of TCP vs UDP is kind of going about it the wrong way. I'd recommend looking at what sort of local security you may need and how you want to get it and whether that has any implications for ISMS. Most of the security solutions we're talking about have significant infrastructure requirements. Let's assume we secure UDP with DTLS. Let's look at all the possible external dependencies we could still have. I'm introducing a few dependencies that are a bit unrealistic, but only a bit. I assume your DTLS uses certificates in one direction and some sort of password fed into an AAA infrastructure in the other direction. That seems plausible at least. I'm also assuming your infrastructure actually does certificate validation; that's unrealistic but the security community would like to at least pretend you do that. Here are some of the external dependencies you have: * Certificate validation depends on an OCSP server. * To get to the OCSP server we need DNS and TCP to some external entity. * If we are lucky, it has the data cached. If we are very unlucky, it starts chasing down certificates in an LDAP directory. IT may follow an arbitrary chain of referrals and how to authenticate to an arbitrary number of LDAP servers. * Your AAA infrastructure is backended by Kerberos. That's actually not completely unheard of. So, your RADIUS server needs to have DNS working and needs to talk to a KDC. So, to send a command to your SNMP engine, you might well need DNS, OCSP, LDAP, RADIUS and Kerberos all to be working. UDP vs TCP just isn't the right level to be looking at this. When running a security infrastructure in practice, you tend to want to have some very simple security infrastructure to fall back on when fixing problems you use with your production infrastructure. For example you may well install ssh keys for the security managers onto enough of the infrastructure that you can get security working again when things break. I think you need to look at under what circumstances your SNMP security solution needs to be independent of your security infrastructure. Here are the possible answers I can see; there are probably potential solutions I'm missing: * USM provides enough of a solution for the case where the network is not working well enough for the security infrastructure. * Go use something else other than SNMP to fix your network; we all hope the netconf folks solved this problem for us. If not, we're actually not that unhappy with our CLIs when we get right down to it. [Yes, this is phrased to spark discussion.] * Everything will be OK; we just use ISMS. * If you have long-lived sessions you'll probably be OK and have enough sessions open to fix things when they break. If not, we can fall back to CLI/USM/whatever else. * We need to consider how to bootstrap local security using the security infrastructure. I think only in the last case--where you look at bootstrapping security infrastructure--does the TCP vs UDP debate become a real issue. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 09 16:15:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVEdF-0002x8-D9; Mon, 09 May 2005 16:13:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVEdD-0002wt-Ma for isms@megatron.ietf.org; Mon, 09 May 2005 16:13:35 -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 QAA02416 for ; Mon, 9 May 2005 16:13:33 -0400 (EDT) Received: from ib72f.i.pppool.de ([85.73.183.47] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVEsN-0001XH-J4 for isms@ietf.org; Mon, 09 May 2005 16:29:17 -0400 Received: by boskop.local (Postfix, from userid 501) id E67932DD770; Mon, 9 May 2005 22:13:19 +0200 (CEST) Date: Mon, 9 May 2005 22:13:19 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Subject: Re: [Isms] Wehn the network doesn't. Message-ID: <20050509201319.GA7773@boskop.local> Mail-Followup-To: Wes Hardaker , Sam Hartman , isms@ietf.org References: <200505070439.AAA13375@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Mon, May 09, 2005 at 11:22:30AM -0700, Wes Hardaker wrote: > The problem is that determining at which point TCP and UDP each stop > working is subject to a large debate that I don't think it would be > productive to have. However, I don't know if we can fully avoid it > since we're trying to decide if we need a secure UDP solution. There is a secure UDP solution which is called SNMPv3/USM. People who rely on using SNMP to fix a truly broken network can use it to get full control over the on the wire retransmission behaviour. Perhaps this is the sort of disclaimer to put into secure transport documents which require TCP as a transport. Let the operators then decide. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 09 16: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 1DVFFA-0002OO-Gl; Mon, 09 May 2005 16: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 1DVFF6-0002Ml-AT for isms@megatron.ietf.org; Mon, 09 May 2005 16:52: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 QAA10253 for ; Mon, 9 May 2005 16:52:41 -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 1DVFUF-0004RU-V7 for isms@ietf.org; Mon, 09 May 2005 17:08:25 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 08E0011D731; Mon, 9 May 2005 13:52:36 -0700 (PDT) From: Wes Hardaker To: Sam Hartman Subject: Re: [Isms] Wehn the network doesn't. Organization: Sparta References: <200505070439.AAA13375@ietf.org> <20050509201319.GA7773@boskop.local> Date: Mon, 09 May 2005 13:52:35 -0700 In-Reply-To: <20050509201319.GA7773@boskop.local> (Juergen Schoenwaelder's message of "Mon, 9 May 2005 22:13:19 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Mon, 9 May 2005 22:13:19 +0200, Juergen Schoenwaelder said: Juergen> There is a secure UDP solution which is called SNMPv3/USM. People who Juergen> rely on using SNMP to fix a truly broken network can use it to get Juergen> full control over the on the wire retransmission behaviour. Or, keep active sessions open in the new mode. Leave that the choice to the operator please. Either solution is certainly usable depending on preference. TCP sessions that need to be restarted don't allow for this. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 09 17:04:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVFQZ-0004rg-AK; Mon, 09 May 2005 17:04:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVFQX-0004rS-FK for isms@megatron.ietf.org; Mon, 09 May 2005 17:04:33 -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 RAA11158 for ; Mon, 9 May 2005 17:04:31 -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 1DVFfh-0004qi-Nm for isms@ietf.org; Mon, 09 May 2005 17:20:15 -0400 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO00F60B; 9 May 2005 17:04:10 -0400 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 9 May 2005 17:04:01 -0400 Received: from connotech.com (209.71.204.101) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG00F60A; 9 May 2005 17:03:51 -0400 Message-ID: <427FD6F3.9040602@connotech.com> Date: Mon, 09 May 2005 17:32:35 -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: isms@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.3 (+) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] Security model characteristics of detailed architectural propositions 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 Dear all: I'm monitoring the current isms activities and I'm somehow puzzled as an IT security specialist. The security model implied by USM is fairly simple and old-fashioned, and is (wholly?) devoid of implementation alternatives or protocol options that would introduce variations in the security model (i.e. unlike e.g. TLS with or without client authentication that exhibit different security model characteristics). The problem with USM is provisioning of shared secrets in each of the SNMP agent that is to be managed under a given user name. Now the isms group is discussing security protocol selection for SNMP traffic encapsulation. The difficulty I have with the current discussion is the many different protocol options which are envisioned, without explanations as the security services that would be provided and without stating the implied provisioning requirements. (Don't forget that authentication of SNMP traffic requires some cryptographic key material, hence implied provisioning requirements can not shrink to zero). I see e.g. two security model features that seem to be currently overlooked: If the EUSM-to-VACM solution is to be re-used with the EK approach, the detailed architecture should encompass the EUSM concepts of AAA server, and (secure) transmission of VACM group membership from the AAA server to the SNMP agent. The SNMP manager must have some faith (trust) that the SNMP agent implementation is well-behaved (in the USM security model, this faith is established by the assumption that derived secrets are ). This typically turns into an SNMP agent implementation cryptographic key, from which data integrity session keys are derived. I suggest that detailed architecture proposals should address the security model implications of protocol selections. Hope this helps (if not, please ignore). -- - 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 Mon May 09 17:22:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVFhl-0007wS-Ah; Mon, 09 May 2005 17:22:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVFhk-0007wK-7b for isms@megatron.ietf.org; Mon, 09 May 2005 17:22: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 RAA13121 for ; Mon, 9 May 2005 17:22:18 -0400 (EDT) Received: from i9fcc.i.pppool.de ([85.73.159.204] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVFwu-0005XD-Od for isms@ietf.org; Mon, 09 May 2005 17:38:02 -0400 Received: by boskop.local (Postfix, from userid 501) id 962592DD8B2; Mon, 9 May 2005 23:22:08 +0200 (CEST) Date: Mon, 9 May 2005 23:22:08 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Subject: Re: [Isms] Wehn the network doesn't. Message-ID: <20050509212208.GA8124@boskop.local> Mail-Followup-To: Wes Hardaker , Sam Hartman , isms@ietf.org References: <200505070439.AAA13375@ietf.org> <20050509201319.GA7773@boskop.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Mon, May 09, 2005 at 01:52:35PM -0700, Wes Hardaker wrote: > > Juergen> There is a secure UDP solution which is called SNMPv3/USM. People who > Juergen> rely on using SNMP to fix a truly broken network can use it to get > Juergen> full control over the on the wire retransmission behaviour. > > Or, keep active sessions open in the new mode. Leave that the choice > to the operator please. Either solution is certainly usable depending > on preference. TCP sessions that need to be restarted don't allow for > this. What does "keep active sessions open in the new mode" mean? I have trouble to grasp the meaning of your comment. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 09 17:29:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVFoC-0001Np-4t; Mon, 09 May 2005 17:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVFoB-0001Nh-Cp for isms@megatron.ietf.org; Mon, 09 May 2005 17:28:59 -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 RAA13704 for ; Mon, 9 May 2005 17:28:57 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVG3L-0005mU-TZ for isms@ietf.org; Mon, 09 May 2005 17:44:41 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j49LScik000158; Mon, 9 May 2005 14:28:38 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Mon, 9 May 2005 14:28:37 -0700 Message-ID: From: "McDonald, Ira" To: "'Sam Hartman'" , Wes Hardaker Subject: RE: [Isms] Wehn the network doesn't. Date: Mon, 9 May 2005 14:28:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On > Behalf Of Sam Hartman > Sent: Monday, May 09, 2005 2:54 PM > To: Wes Hardaker > Cc: isms@ietf.org > Subject: Re: [Isms] Wehn the network doesn't. > > > * USM provides enough of a solution for the case where the network is > not working well enough for the security infrastructure. > > * Go use something else other than SNMP to fix your network; we all > hope the netconf folks solved this problem for us. If not, we're > actually not that unhappy with our CLIs when we get right down to > it. [Yes, this is phrased to spark discussion.] > > --Sam Hi, The Netconf folks aren't even trying to solve the problem of fixing broken SNMP networks. They are explicitly _not_ addressing active management (restart, state changes, etc.) of any managed elements. They're only addressing sending new configurations to healthy systems. CLIs over Telnet or out-of-band dialup always have been the main method used to fix broken large networks. SNMP never has been accepted by the operators as a viable solution. That's the problem that ISMS WG is supposed to be addressing. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 09 17:37:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVFvy-0003Ri-HV; Mon, 09 May 2005 17:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVFvx-0003Ra-D2 for isms@megatron.ietf.org; Mon, 09 May 2005 17:37:01 -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 RAA14532 for ; Mon, 9 May 2005 17:36:59 -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 1DVGB8-00066K-5l for isms@ietf.org; Mon, 09 May 2005 17:52:43 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id A5B7011D731; Mon, 9 May 2005 14:36:54 -0700 (PDT) From: Wes Hardaker To: Sam Hartman Subject: Re: [Isms] Wehn the network doesn't. Organization: Sparta References: <200505070439.AAA13375@ietf.org> <20050509201319.GA7773@boskop.local> <20050509212208.GA8124@boskop.local> Date: Mon, 09 May 2005 14:36:54 -0700 In-Reply-To: <20050509212208.GA8124@boskop.local> (Juergen Schoenwaelder's message of "Mon, 9 May 2005 23:22:08 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Mon, 9 May 2005 23:22:08 +0200, Juergen Schoenwaelder said: Juergen> What does "keep active sessions open in the new mode" mean? I have Juergen> trouble to grasp the meaning of your comment. Sorry, how about: keep active ISMS sessions open -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 09 17:44:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVG2j-0003kc-Lz; Mon, 09 May 2005 17:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVG2h-0003kU-NA for isms@megatron.ietf.org; Mon, 09 May 2005 17:43:59 -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 RAA15041 for ; Mon, 9 May 2005 17:43:57 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVGHs-0006JL-IK for isms@ietf.org; Mon, 09 May 2005 17:59:41 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 8400DE0064; Mon, 9 May 2005 17:43:53 -0400 (EDT) To: "McDonald, Ira" Subject: Re: [Isms] Wehn the network doesn't. References: From: Sam Hartman Date: Mon, 09 May 2005 17:43:53 -0400 In-Reply-To: (Ira McDonald's message of "Mon, 9 May 2005 14:28:36 -0700") 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 >>>>> "McDonald," == McDonald, Ira writes: McDonald,> CLIs over Telnet or out-of-band dialup always have been McDonald,> the main method used to fix broken large networks. McDonald,> SNMP never has been accepted by the operators as a McDonald,> viable solution. That's the problem that ISMS WG is McDonald,> supposed to be addressing. No, that's not our goal. Our goal is the create a security model for SNMP that will meet the security and operational needs of the operator community. I find nothing in the charter of the working group that states which uses of SNMP the operators actually want. As such, the question of which use cases we care about seem entirely within scope. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 09 20:44:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVIqz-0004Wd-J1; Mon, 09 May 2005 20:44:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVIqy-0004WO-F9 for isms@megatron.ietf.org; Mon, 09 May 2005 20:44: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 UAA02764 for ; Mon, 9 May 2005 20:44:02 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVJ6A-0004VL-F5 for isms@ietf.org; Mon, 09 May 2005 20:59:47 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j4A0hnW8014897; Mon, 9 May 2005 17:43:49 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Mon, 9 May 2005 17:43:49 -0700 Message-ID: From: "McDonald, Ira" To: "'Sam Hartman'" , "McDonald, Ira" Subject: RE: [Isms] Wehn the network doesn't. Date: Mon, 9 May 2005 17:43:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Sam, Well - we just talked right past each other. Your reply below is exactly what I what I was trying to say. The goal of the ISMS WG is to finally make SNMP usable and useful and _used_ by operators and administrators, by overcoming the high cost of unique security mechanisms. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Monday, May 09, 2005 5:44 PM > To: McDonald, Ira > Cc: Wes Hardaker; isms@ietf.org > Subject: Re: [Isms] Wehn the network doesn't. > > > >>>>> "McDonald," == McDonald, Ira writes: > > McDonald,> CLIs over Telnet or out-of-band dialup always have been > McDonald,> the main method used to fix broken large networks. > McDonald,> SNMP never has been accepted by the operators as a > McDonald,> viable solution. That's the problem that ISMS WG is > McDonald,> supposed to be addressing. > > No, that's not our goal. Our goal is the create a security model for > SNMP that will meet the security and operational needs of the operator > community. > > I find nothing in the charter of the working group that states which > uses of SNMP the operators actually want. > > > As such, the question of which use cases we care about seem entirely > within scope. > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 10 16:45:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVbby-000299-53; Tue, 10 May 2005 16:45:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVbbv-00028u-53 for isms@megatron.ietf.org; Tue, 10 May 2005 16:45:48 -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 QAA18784 for ; Tue, 10 May 2005 16:45:45 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVbrI-0006qP-0x for isms@ietf.org; Tue, 10 May 2005 17:01:41 -0400 Received: from pc6 (1Cust22.tnt109.lnd4.gbr.da.uu.net [62.188.172.22]) by galaxy.systems.pipex.net (Postfix) with SMTP id 7FBF0E0001BA; Tue, 10 May 2005 21:45:31 +0100 (BST) Message-ID: <01d301c55598$42eac800$0601a8c0@pc6> From: "Tom Petch" To: "Sam Hartman" References: <010401c554aa$3d4da780$0601a8c0@pc6> Subject: Re: [Isms] Thoughts on Encapsulation Date: Tue, 10 May 2005 21:10:43 +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: 0ddefe323dd869ab027dbfff7eff0465 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 Thanks for that. What caught my eye in it was "avoid the need for public key operations. This is useful if TLS is used in performance-constrained environments with limited CPU power." which fits my image of many agents. A challenge I always see in SNMP security is that the server (agent) is the thin skinny device that may not be capable of too much while the client (manager) has the power and resources available - role reversal compared with most client-server systems: and I see server authentication of client (eg set operation) as a pressing need. And to quote Wes (yet one more time) operators' survey "Of the various authentication systems in use at that time by the people that responded: 66% local accounts 49% SSH-keys 40% Radius 29% TACACS+ 14% X.509 Certificates 10% Kerberos" Tom Petch ----- Original Message ----- From: "Sam Hartman" To: "Tom Petch" Cc: Sent: Monday, May 09, 2005 6:55 PM Subject: Re: [Isms] Thoughts on Encapsulation > Tom> Sam, In which part of your dichotomy would you place > Tom> draft-ietf-tls-psk-08.txt > > I don't think it fits well into ISMS. You *could* ues it. If you did > I'd expect you to then use SASL external. But it only works well if > you already have TLS PSKs configured somehow. It doesn't work well > with RADIUS or other existing mechanisms. > > Same goes for any TLS SRP solution only more so. > > Don't get me wrong: if your organization wants to deploy SRP or TLS > PSKs that's great. You'll get better security; you'll have all sorts > of warm fuzzy feelings. You won't be using the infrastructure you > have today though and supporting existing infrastructure is the goal > of ISMS. > > Naturally I'm going to be concerned if we come up with an ISMS > solution that won't work with potential future infrastructures. I > don't see that happening though. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 10 16:45:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVbby-0002Ai-IF; Tue, 10 May 2005 16:45:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVbbu-00028s-C3 for isms@megatron.ietf.org; Tue, 10 May 2005 16:45:48 -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 QAA18781 for ; Tue, 10 May 2005 16:45:44 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVbrH-0006qX-Vv for isms@ietf.org; Tue, 10 May 2005 17:01:40 -0400 Received: from pc6 (1Cust22.tnt109.lnd4.gbr.da.uu.net [62.188.172.22]) by galaxy.systems.pipex.net (Postfix) with SMTP id D2D7EE000212; Tue, 10 May 2005 21:45:34 +0100 (BST) Message-ID: <01d401c55598$4418e7c0$0601a8c0@pc6> From: "Tom Petch" To: "Thierry Moreau" , References: <427FD6F3.9040602@connotech.com> Subject: Re: [Isms] Security model characteristics of detailed architecturalpropositions Date: Tue, 10 May 2005 21:40:09 +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: 386e0819b1192672467565a524848168 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 Two thoughts. First, there is a statement of security requirements and non-requirements in the SNMP v3 architecture and that is mostly being taken as read (David H did refer to them a while back). Second, I, and perhaps others, am a refugee from SNMP, from Ops and Management, and my grounding in security is solid but no way leading edge (ssh yes, TLS no). Do I belong in an Security Area WG at all? Well, I want isms to happen so here I am:-) But I do see a lot of acronyms I am not familiar with, I have a steep learning curve, and do appreciate someone grounded in security stating the obvious now and again (how many parties are there in Radius?); it does encourage me to work harder at it. Tom Petch ----- Original Message ----- From: "Thierry Moreau" To: Sent: Monday, May 09, 2005 11:32 PM Subject: [Isms] Security model characteristics of detailed architecturalpropositions > Dear all: > > I'm monitoring the current isms activities and I'm > somehow puzzled as an IT security specialist. > > The security model implied by USM is fairly simple and > old-fashioned, and is (wholly?) devoid of > implementation alternatives or protocol options that > would introduce variations in the security model (i.e. > unlike e.g. TLS with or without client authentication > that exhibit different security model characteristics). > The problem with USM is provisioning of shared secrets > in each of the SNMP agent that is to be managed under a > given user name. > > Now the isms group is discussing security protocol > selection for SNMP traffic encapsulation. The > difficulty I have with the current discussion is the > many different protocol options which are envisioned, > without explanations as the security services that > would be provided and without stating the implied > provisioning requirements. (Don't forget that > authentication of SNMP traffic requires some > cryptographic key material, hence implied provisioning > requirements can not shrink to zero). > > I see e.g. two security model features that seem to be > currently overlooked: > > If the EUSM-to-VACM solution is to be re-used with > the EK approach, the detailed architecture should > encompass the EUSM concepts of AAA server, and > (secure) transmission of VACM group membership from > the AAA server to the SNMP agent. > > The SNMP manager must have some faith (trust) that > the SNMP agent implementation is well-behaved (in > the USM security model, this faith is established > by the assumption that derived secrets are ). This > typically turns into an SNMP agent implementation > cryptographic key, from which data integrity > session keys are derived. > > I suggest that detailed architecture proposals should > address the security model implications of protocol > selections. > > Hope this helps (if not, please ignore). > > -- > > - 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 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 12 03:09:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7p6-00068f-Ay; Thu, 12 May 2005 03:09:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7p4-00067U-FW for isms@megatron.ietf.org; Thu, 12 May 2005 03:09:30 -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 DAA29823 for ; Thu, 12 May 2005 03:09:29 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW84j-0006pr-Jv for isms@ietf.org; Thu, 12 May 2005 03:25:42 -0400 Received: from pc6 (1Cust124.tnt101.lnd4.gbr.da.uu.net [213.116.50.124]) by blaster.systems.pipex.net (Postfix) with SMTP id A765FE0000BF; Thu, 12 May 2005 08:09:16 +0100 (BST) Message-ID: <001601c556b8$9005d640$0601a8c0@pc6> From: "Tom Petch" To: "Sam Hartman" References: <200505070439.AAA13375@ietf.org> Subject: Re: [Isms] Wehn the network doesn't. Date: Thu, 12 May 2005 08:04:17 +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: 0bc60ec82efc80c84b8d02f4b0e4de22 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 > > So, to send a command to your SNMP engine, you might well need DNS, > OCSP, LDAP, RADIUS and Kerberos all to be working. UDP vs TCP just > isn't the right level to be looking at this. > No problem:-) The command generator/SNMP manager/SNMP client runs on a server platform that has everything a server would be expected to have and more, or can readily acquire it. The issue, perhaps unique to SNMP, is that the SNMP server/agent/command responder is the one with limited facilities, perhaps Telnet/TFTP/TCP/UDP and nothing else, where anything that SNMP needs must be added, assuming that the platform is up to it. And that is the system likely to have poor communications when the network is not working too well. So taking your statement literally, and I expect you did not quite have this in mind, the generation/sending of the command is no problem. It is the authentication of it at the server (which only has Telnet etc) that may be the challenge. Reading security RFC and I-D I find it hard to tease out this issue; they are couched in terms of client and server but seem to assume that the server is the server for all protocols, client ditto. Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 12 10:46:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWExF-00027F-0z; Thu, 12 May 2005 10:46:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWExC-00027A-T9 for isms@megatron.ietf.org; Thu, 12 May 2005 10:46:23 -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 KAA29948 for ; Thu, 12 May 2005 10:46:20 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWFCw-0003e3-2t for isms@ietf.org; Thu, 12 May 2005 11:02:39 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E37FEE0063; Thu, 12 May 2005 10:46:07 -0400 (EDT) To: "Tom Petch" Subject: Re: [Isms] Wehn the network doesn't. References: <200505070439.AAA13375@ietf.org> <001601c556b8$9005d640$0601a8c0@pc6> From: Sam Hartman Date: Thu, 12 May 2005 10:46:07 -0400 In-Reply-To: <001601c556b8$9005d640$0601a8c0@pc6> (Tom Petch's message of "Thu, 12 May 2005 08:04:17 +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: 2409bba43e9c8d580670fda8b695204a 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> >> So, to send a command to your SNMP engine, you might well need >> DNS, OCSP, LDAP, RADIUS and Kerberos all to be working. UDP vs >> TCP just isn't the right level to be looking at this. >> Tom> No problem:-) The command generator/SNMP manager/SNMP client Tom> runs on a server platform that has everything a server would Tom> be expected to have and more, or can readily acquire it. Tom> The issue, perhaps unique to SNMP, is that the SNMP Tom> server/agent/command responder is the one with limited Tom> facilities, perhaps Telnet/TFTP/TCP/UDP and nothing else, Tom> where anything that SNMP needs must be added, assuming that Tom> the platform is up to it. And that is the system likely to Tom> have poor communications when the network is not working too Tom> well. 1) If the network is not working well, central services like DNS may not be available to any party. 2) I constructed the example so that it was the command responder who needed to contact both the AAA server and the OCSP server. So it is the command responder that needs all those facilities. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 12 12:06:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWGCy-0007SV-Nc; Thu, 12 May 2005 12:06:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWGCx-0007RR-5J for isms@megatron.ietf.org; Thu, 12 May 2005 12:06: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 MAA07013 for ; Thu, 12 May 2005 12:06:40 -0400 (EDT) Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWGSg-0005X2-Q9 for isms@ietf.org; Thu, 12 May 2005 12:23:00 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4CG6UdQ007764; Thu, 12 May 2005 16:06:30 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j4CG6IRS007595; Thu, 12 May 2005 16:06:30 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005051209062923250 ; Thu, 12 May 2005 09:06:29 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 09:06:22 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 09:06:02 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 12:06:00 -0400 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] Wehn the network doesn't. Date: Thu, 12 May 2005 12:05:18 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C592901220891@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Wehn the network doesn't. Thread-Index: AcVXAW/chCK1lws1R+uyLUmhZSOP+AACRvww From: "Blumenthal, Uri" To: "Sam Hartman" , "Tom Petch" X-OriginalArrivalTime: 12 May 2005 16:06:00.0158 (UTC) FILETIME=[7D31FFE0:01C5570C] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 > 1) If the network is not working well, central services like DNS may > not be available to any party. Which is why one can configure SNMP engine notification destinations etc. as IP addresses rathr than host names.=20 > 2) I constructed the example so that it was the command responder who > needed to contact both the AAA server and the OCSP server. So it > is the command responder that needs all those facilities. When the network is healthy and the device that hosts SNMP command responder has enough memory and cycles to spare for these extras, there's no problem in adding all those facilities.=20 One of the postulates of the original SNMP design was "Device is small, limited and dumb - in addition to struggling with doing its main job; it has few resources to spare on 'parasitic' management overhead." I don't know how much of it is still true. Intuitively though - even for the biggest router: the more cycles it spends on SNMP, the less of CPU is left for doing its main task (shoveling IP packets around). Why don't those who make the darn things, speak up and tell how much overhead they're willing to suffer for convenience such as deployable SNMPv3 that can plug into their Kerberos (or RADIUS, or SSH) infrastructure. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 12 14:51:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWImi-0004YR-Se; Thu, 12 May 2005 14:51:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWImh-0004YM-GX for isms@megatron.ietf.org; Thu, 12 May 2005 14: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 OAA21188 for ; Thu, 12 May 2005 14:51:45 -0400 (EDT) Message-Id: <200505121851.OAA21188@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.89]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWJ2S-0001Du-Om for isms@ietf.org; Thu, 12 May 2005 15:08:06 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <2005051218513501400c9f1ge>; Thu, 12 May 2005 18:51:36 +0000 From: "David B Harrington" To: "'Blumenthal, Uri'" , "'Sam Hartman'" , "'Tom Petch'" Subject: RE: [Isms] Wehn the network doesn't. Date: Thu, 12 May 2005 14:51: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: <3DEC199BD7489643817ECA151F7C592901220891@pysmsx401.amr.corp.intel.com> Thread-Index: AcVXAW/chCK1lws1R+uyLUmhZSOP+AACRvwwAAWoKUA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Uri, > Why don't > those who make the darn things, speak up and tell how much overhead > they're willing to suffer for convenience such as deployable > SNMPv3 that > can plug into their Kerberos (or RADIUS, or SSH) infrastructure. You're confusing two targets here - those who "make the darn things" are not the same as those who deploy them and have Kerberos (or RADIUS, or SSH) infrastructure. >From the generic standpoint of those who make the darn things, we want to use as little overhead at as little cost as possible without jeopardizing our ability to make the "short list." That's why many MIB modules never get implemented in products - the lack of the MIB module will not prevent the sale of the product. The lack of SNMPv3 in a product generally does not keep the product off the short list. The lack of SNMPv3 in SNMP management applications definitely does not force the application off the short list. >From the generic standpoint of those who deploy networks, as far as I can tell, they want the most important functionality for their business requirements for the least amount of cost. If a vendor's hardware is missing, say 10G Ethernet, they won't make the short list even if they support SNMPv3. If a vendor's product does support 10G Ethernet but doesn't support SNMPv3, the lack of SNMPv3 generally won't keep the vendor off the short list. The economic realities lead many vendors to not bother implementing SNMPv3 or a full complement of MIB modules. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 12 16:16:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWK6c-0005sn-Cy; Thu, 12 May 2005 16:16:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWK6b-0005sd-9X for isms@megatron.ietf.org; Thu, 12 May 2005 16:16:25 -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 QAA04879 for ; Thu, 12 May 2005 16:16:22 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWKMN-0004XV-Ip for isms@ietf.org; Thu, 12 May 2005 16:32:44 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 May 2005 13:16:14 -0700 X-IronPort-AV: i="3.93,100,1115017200"; d="scan'208"; a="264516090:sNHT29491356" Received: from kaushik-w2k03.cisco.com ([171.69.75.179]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4CKG1O4002134; Thu, 12 May 2005 13:16:02 -0700 (PDT) Message-Id: <6.2.0.14.0.20050512131355.039ae338@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 12 May 2005 13:16:01 -0700 To: "Blumenthal, Uri" From: Kaushik Narayan Subject: RE: [Isms] Wehn the network doesn't. In-Reply-To: <3DEC199BD7489643817ECA151F7C592901220891@pysmsx401.amr.cor p.intel.com> References: <3DEC199BD7489643817ECA151F7C592901220891@pysmsx401.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [171.69.75.179] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 All, I didn't want to say this because the consensus has chosen TLS, but since we are discussing SNMP design principles I wanted to bring an issue about typical SNMP usage patterns and TLS SNMP is predominantly used for data collection, this includes operational state that is monitored periodically at very short intervals, bulk data such as performance data that is collected with far lesser frequency but entails massive amount of data and inventory data that is collected on change (periodic polling done to detect any missed change). Each of these data types requires different types of protection. With protection at the transport layer, SNMP engines, for e.g. will need to open new connections even all they might be doing is collecting operStatus every minute, the other option is to have long lived connections and typically with a ratio of 10,000:1 between managed elements and management systems that would be a lot of open connections. Long lived connections also have the side effect that TLS cipher suites negotiated during connection establishment will apply for the length of the connection. This would result in same protection for all SNMP data transported during the lifetime of a connection irrespective of whether it is configuration, operational or performance data (isn't this why there was securityLevel in every SNMPv3 message). In the past when we tried to run SNMPv2c over IPSec and it failed miserably since management systems typically hosted on desktops with 500MB of RAM could not scale to even 10s of devices and in most cases operators are managing tens of thousands. regards, kaushik! At 09:05 AM 5/12/2005, Blumenthal, Uri wrote: > > 1) If the network is not working well, central services like DNS may > > not be available to any party. > >Which is why one can configure SNMP engine notification destinations >etc. as IP addresses rathr than host names. > > > 2) I constructed the example so that it was the command responder who > > needed to contact both the AAA server and the OCSP server. So it > > is the command responder that needs all those facilities. > >When the network is healthy and the device that hosts SNMP command >responder has enough memory and cycles to spare for these extras, >there's no problem in adding all those facilities. > >One of the postulates of the original SNMP design was "Device is small, >limited and dumb - in addition to struggling with doing its main job; it >has few resources to spare on 'parasitic' management overhead." I don't >know how much of it is still true. Intuitively though - even for the >biggest router: the more cycles it spends on SNMP, the less of CPU is >left for doing its main task (shoveling IP packets around). Why don't >those who make the darn things, speak up and tell how much overhead >they're willing to suffer for convenience such as deployable SNMPv3 that >can plug into their Kerberos (or RADIUS, or SSH) infrastructure. > >_______________________________________________ >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 May 12 17:10:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWKwe-0003I6-GA; Thu, 12 May 2005 17:10:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWKwd-0003I1-89 for isms@megatron.ietf.org; Thu, 12 May 2005 17:10:11 -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 RAA09657 for ; Thu, 12 May 2005 17:10:08 -0400 (EDT) Received: from ia41a.i.pppool.de ([85.73.164.26] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWLCQ-0006Dd-0w for isms@ietf.org; Thu, 12 May 2005 17:26:30 -0400 Received: by boskop.local (Postfix, from userid 501) id F02802E640B; Thu, 12 May 2005 23:09:58 +0200 (CEST) Date: Thu, 12 May 2005 23:09:58 +0200 From: Juergen Schoenwaelder To: Kaushik Narayan Message-ID: <20050512210958.GA1254@boskop.local> Mail-Followup-To: Kaushik Narayan , isms@ietf.org References: <3DEC199BD7489643817ECA151F7C592901220891@pysmsx401.amr.corp.intel.com> <6.2.0.14.0.20050512131355.039ae338@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.0.14.0.20050512131355.039ae338@email.cisco.com> User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: isms@ietf.org Subject: [Isms] TLS / SSH scalability concerns X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Thu, May 12, 2005 at 01:16:01PM -0700, Kaushik Narayan wrote: > With protection at the transport layer, SNMP engines, for e.g. will need to > open new connections even all they might be doing is collecting operStatus > every minute, the other option is to have long lived connections and > typically with a ratio of 10,000:1 between managed elements and management > systems that would be a lot of open connections. Long lived connections > also have the side effect that TLS cipher suites negotiated during connection > establishment will apply for the length of the connection. This would > result in same protection for all SNMP data transported during the > lifetime of a connection irrespective of whether it is configuration, > operational or performance data (isn't this why there was securityLevel > in every SNMPv3 message). Are your products really choosing a different securityLevel depending on whether they operate on configuration, operational or performance data? Is this the default setup or something someone could in principle configure? > In the past when we tried to run SNMPv2c over IPSec and it failed miserably > since management systems typically hosted on desktops with 500MB of > RAM could not scale to even 10s of devices and in most cases operators > are managing tens of thousands. Do you really poll 10,000 boxes from a single centralized manager? And does your management software running on a 500MB desktop really scale to tens of thousands of boxes with SNMPv3 security enabled? What I recall from other big companies selling management products is that they usually ask customers for some quite powerful hardware even to manage modest networks and that these vendors are usually very proud of their distributed data collection engines... But I do agree with you that scalability in the number of devices that can be polled is a critical point to have in mind when moving to a TLS transport. For situations where you poll a single variable from a very large number of nodes, TLS will raise overhead. On the other hand, if the data you like to poll does not fit into a few tiny PDUs anymore (and that is often already the case if you poll a few ifTable columns from an IEEE 802 switch these days), then a TCP based transport will at some point become more efficient due to larger message sizes and all the nice things that TCP does for you. (And I assume you are aware of the various proprietary ways to ship larger SNMP data sets via protocols such FTP to overcome SNMP's relatively poor performance for larger data sets.) I do agree that scalability needs to be taken into account and that this is a real issue (while repairing broken networks with SNMP really is a myths in my view a non-issue). My personal take on this is that SNMPv3/USM is out there and going to stay so in cases where you need high end small-data lots-of-devices polling engines, you can still use SNMPv3/USM (and you have to pay the price for the key management or you resort to noAuth/noPriv to avoid lengthy computations). For the more bulky-data medium-number-of- devices situations, I do not think TLS will be unfeasible. Note that I am reading my email using imaps and I you can be sure that I am not the only imap reader on our IMAP server polling mail boxes, which BTW is just one of these many Intel PCs. /js P.S. If you have contacts to customers who are polling 10,000+ devices from a single centralized server, please ask them whether they are willing to support research by capturing traces, running them through analyzers and and giving condensed information to the NMRG. I like to see some more substance added to scalability discussions such as this one by having some reliable data sources and traffic models. -- 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 Thu May 12 17:31:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWLGu-0007VD-Vr; Thu, 12 May 2005 17:31:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWLGs-0007V4-Nf for isms@megatron.ietf.org; Thu, 12 May 2005 17:31:07 -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 RAA11097 for ; Thu, 12 May 2005 17:31:04 -0400 (EDT) Received: from stratton-three-seventy-eight.mit.edu ([18.187.6.123] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWLWf-0006jD-D3 for isms@ietf.org; Thu, 12 May 2005 17:47:26 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 658CBE0063; Thu, 12 May 2005 17:30:58 -0400 (EDT) To: Kaushik Narayan Subject: Re: [Isms] Wehn the network doesn't. References: <3DEC199BD7489643817ECA151F7C592901220891@pysmsx401.amr.corp.intel.com> <6.2.0.14.0.20050512131355.039ae338@email.cisco.com> From: Sam Hartman Date: Thu, 12 May 2005 17:30:58 -0400 In-Reply-To: <6.2.0.14.0.20050512131355.039ae338@email.cisco.com> (Kaushik Narayan's message of "Thu, 12 May 2005 13:16:01 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: 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 >>>>> "Kaushik" == Kaushik Narayan writes: Kaushik> Hi All, I didn't want to say this because the consensus Kaushik> has chosen TLS, but since we are discussing SNMP design Er, we've chosen encapsulation not TLS. Your points might be very important when discussing what we want to encapsulate. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 12 17:49:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWLYe-0002qr-Qu; Thu, 12 May 2005 17:49:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWLYd-0002qf-9w for isms@megatron.ietf.org; Thu, 12 May 2005 17:49:27 -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 RAA12525 for ; Thu, 12 May 2005 17:49:24 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWLoP-0007C5-Cd for isms@ietf.org; Thu, 12 May 2005 18:05:47 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 12 May 2005 14:49:15 -0700 X-IronPort-AV: i="3.93,100,1115017200"; d="scan'208"; a="635985036:sNHT31584638" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4CLmjQC025231; Thu, 12 May 2005 14:49:12 -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); Thu, 12 May 2005 14:49:10 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] TLS / SSH scalability concerns Date: Thu, 12 May 2005 14:49:08 -0700 Message-ID: Thread-Topic: [Isms] TLS / SSH scalability concerns Thread-Index: AcVXN2WH0ImXOU2FRYq2J3QM9uC88QAA1d7w From: "Khanh Nguyen \(khanhvn\)" To: , X-OriginalArrivalTime: 12 May 2005 21:49:10.0200 (UTC) FILETIME=[6DD11380:01C5573C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 FYI (in case you not already know): http://www.umiacs.umd.edu/docs/Du.ppt They concluded that SNMP/TLS was more efficient than USM. Anyway, these results need to be taken w/ a grain of salt as there are many factors (e.g. # msgs per session) that may affect the results. Khanh > -----Original Message----- > From: isms-bounces@lists.ietf.org=20 > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen=20 > Schoenwaelder > Sent: Thursday, May 12, 2005 2:10 PM > To: Kaushik Narayan (kaushik) > Cc: isms@ietf.org > Subject: [Isms] TLS / SSH scalability concerns >=20 > On Thu, May 12, 2005 at 01:16:01PM -0700, Kaushik Narayan wrote: >=20 > > With protection at the transport layer, SNMP engines, for e.g. will=20 > > need to open new connections even all they might be doing is=20 > > collecting operStatus every minute, the other option is to=20 > have long =20 > > lived connections and typically with a ratio of 10,000:1 between=20 > > managed elements and management systems that would be a lot of open=20 > > connections. Long lived connections also have the side=20 > effect that TLS=20 > > cipher suites negotiated during connection establishment will apply=20 > > for the length of the connection. This would result in same=20 > protection=20 > > for all SNMP data transported during the lifetime of a connection=20 > > irrespective of whether it is configuration, operational or=20 > > performance data (isn't this why there was securityLevel in=20 > every SNMPv3 message). >=20 > Are your products really choosing a different securityLevel=20 > depending on whether they operate on configuration,=20 > operational or performance data? > Is this the default setup or something someone could in=20 > principle configure? > =20 > > In the past when we tried to run SNMPv2c over IPSec and it failed=20 > > miserably since management systems typically hosted on=20 > desktops with=20 > > 500MB of RAM could not scale to even 10s of devices and in=20 > most cases=20 > > operators are managing tens of thousands. >=20 > Do you really poll 10,000 boxes from a single centralized=20 > manager? And does your management software running on a 500MB=20 > desktop really scale to tens of thousands of boxes with=20 > SNMPv3 security enabled? >=20 > What I recall from other big companies selling management=20 > products is that they usually ask customers for some quite=20 > powerful hardware even to manage modest networks and that=20 > these vendors are usually very proud of their distributed=20 > data collection engines... >=20 > But I do agree with you that scalability in the number of=20 > devices that can be polled is a critical point to have in=20 > mind when moving to a TLS transport. For situations where you=20 > poll a single variable from a very large number of nodes, TLS=20 > will raise overhead. On the other hand, if the data you like=20 > to poll does not fit into a few tiny PDUs anymore (and that=20 > is often already the case if you poll a few ifTable columns=20 > from an IEEE 802 switch these days), then a TCP based=20 > transport will at some point become more efficient due to=20 > larger message sizes and all the nice things that TCP does=20 > for you. (And I assume you are aware of the various=20 > proprietary ways to ship larger SNMP data sets via protocols=20 > such FTP to overcome SNMP's relatively poor performance for=20 > larger data sets.) >=20 > I do agree that scalability needs to be taken into account=20 > and that this is a real issue (while repairing broken=20 > networks with SNMP really is a myths in my view a non-issue). >=20 > My personal take on this is that SNMPv3/USM is out there and=20 > going to stay so in cases where you need high end small-data=20 > lots-of-devices polling engines, you can still use SNMPv3/USM=20 > (and you have to pay the price for the key management or you=20 > resort to noAuth/noPriv to avoid lengthy computations). For=20 > the more bulky-data medium-number-of- devices situations, I=20 > do not think TLS will be unfeasible. Note that I am reading=20 > my email using imaps and I you can be sure that I am not the=20 > only imap reader on our IMAP server polling mail boxes, which=20 > BTW is just one of these many Intel PCs. >=20 > /js >=20 > P.S. If you have contacts to customers who are polling 10,000+ devices > from a single centralized server, please ask them whether they=20 > are willing to support research by capturing traces, running them > through analyzers and and giving condensed information=20 > to the NMRG.=20 > I like to see some more substance added to scalability=20 > discussions=20 > such as this one by having some reliable data sources=20 > and traffic=20 > models. >=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 May 12 20:59:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWOWP-0003H1-8N; Thu, 12 May 2005 20:59:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWOWN-0003Dj-9t for isms@megatron.ietf.org; Thu, 12 May 2005 20:59:19 -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 UAA00229 for ; Thu, 12 May 2005 20:59:17 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWOmB-0004c8-I6 for isms@ietf.org; Thu, 12 May 2005 21:15:41 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 12 May 2005 17:59:09 -0700 Received: from kaushik-w2k03.cisco.com ([171.69.75.179]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4D0x4ES012912; Thu, 12 May 2005 17:59:05 -0700 (PDT) Message-Id: <6.2.0.14.0.20050512175448.03048ba0@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 12 May 2005 17:58:59 -0700 To: j.schoenwaelder@iu-bremen.de From: Kaushik Narayan In-Reply-To: <20050512210958.GA1254@boskop.local> References: <3DEC199BD7489643817ECA151F7C592901220891@pysmsx401.amr.corp.intel.com> <6.2.0.14.0.20050512131355.039ae338@email.cisco.com> <20050512210958.GA1254@boskop.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [171.69.75.179] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: isms@ietf.org Subject: [Isms] Re: TLS / SSH scalability concerns X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Juergen, Please find my reply inline. At 02:09 PM 5/12/2005, Juergen Schoenwaelder wrote: >On Thu, May 12, 2005 at 01:16:01PM -0700, Kaushik Narayan wrote: > > > With protection at the transport layer, SNMP engines, for e.g. will > need to > > open new connections even all they might be doing is collecting operStatus > > every minute, the other option is to have long lived connections and > > typically with a ratio of 10,000:1 between managed elements and management > > systems that would be a lot of open connections. Long lived connections > > also have the side effect that TLS cipher suites negotiated during > connection > > establishment will apply for the length of the connection. This would > > result in same protection for all SNMP data transported during the > > lifetime of a connection irrespective of whether it is configuration, > > operational or performance data (isn't this why there was securityLevel > > in every SNMPv3 message). > >Are your products really choosing a different securityLevel depending on >whether they operate on configuration, operational or performance data? >Is this the default setup or something someone could in principle >configure? Our products in the field currently supporting only SNMPv3 authNoPriv since DES is the only privacy option for most devices in the field, we will be shipping agents with SNMPv3 AES support soon. As we are trying to support SNMPv3 privacy with AES, we are trying to define default out-of-the box rules for use of privacy and we did want to make sure that we don't use privacy protection for our performance collection use cases. We are trying to selectively use two securityLevels (authPriv and authNoPriv) in addition to noAuthNoPriv used by SNMP engine discovery. > > > In the past when we tried to run SNMPv2c over IPSec and it failed miserably > > since management systems typically hosted on desktops with 500MB of > > RAM could not scale to even 10s of devices and in most cases operators > > are managing tens of thousands. > >Do you really poll 10,000 boxes from a single centralized manager? And >does your management software running on a 500MB desktop really scale >to tens of thousands of boxes with SNMPv3 security enabled? Most of customers use a single server (typical config is around 500MB to 1 Gig of RAM) to manage up to 5000 devices with a majority of them greater than 1000 devices. >What I recall from other big companies selling management products is >that they usually ask customers for some quite powerful hardware even >to manage modest networks and that these vendors are usually very >proud of their distributed data collection engines... > >But I do agree with you that scalability in the number of devices that >can be polled is a critical point to have in mind when moving to a TLS >transport. For situations where you poll a single variable from a very >large number of nodes, TLS will raise overhead. On the other hand, if >the data you like to poll does not fit into a few tiny PDUs anymore >(and that is often already the case if you poll a few ifTable >columns from an IEEE 802 switch these days), then a TCP based transport >will at some point become more efficient due to larger message sizes >and all the nice things that TCP does for you. (And I assume you are >aware of the various proprietary ways to ship larger SNMP data sets >via protocols such FTP to overcome SNMP's relatively poor performance >for larger data sets.) We do have mechanisms to ship performance data via bulk files, again this is not an option available universally and a large set of our customers are still using SNMP to periodically collect statistics using MIB walks. >I do agree that scalability needs to be taken into account and that >this is a real issue (while repairing broken networks with SNMP >really is a myths in my view a non-issue). > >My personal take on this is that SNMPv3/USM is out there and going to >stay so in cases where you need high end small-data lots-of-devices >polling engines, you can still use SNMPv3/USM (and you have to pay >the price for the key management or you resort to noAuth/noPriv to >avoid lengthy computations). For the more bulky-data medium-number-of- >devices situations, I do not think TLS will be unfeasible. Note >that I am reading my email using imaps and I you can be sure that I >am not the only imap reader on our IMAP server polling mail boxes, >which BTW is just one of these many Intel PCs. My concern is that essentially if a part of the usage pattern of SNMP is not met by ISMS there is really too much overhead for doing both USM and ISMS. Also, the bulky-data use cases require least amount of protection. The success of ISMS will be in introducing security in the least intrusive fashion and we need to be careful of the overhead ISMS will add both in terms of requiring additional credentials provisioned on SNMP engines and in terms of performance implications for managers and agents. For deployment of ISMS, operators will compare the overhead to SNMPv2c (which is what is used universally) and not SNMPv3/USM. regards, kaushik! >/js >P.S. If you have contacts to customers who are polling 10,000+ devices > from a single centralized server, please ask them whether they > are willing to support research by capturing traces, running them > through analyzers and and giving condensed information to the NMRG. > I like to see some more substance added to scalability discussions > such as this one by having some reliable data sources and traffic > models. A lot of these customers are very sensitive about providing traces for public consumption. Let me see what I can do. >-- >Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 13 11:45:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWcMO-0000g3-Lz; Fri, 13 May 2005 11:45:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWcMN-0000fk-6O for isms@megatron.ietf.org; Fri, 13 May 2005 11:45:55 -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 LAA25525 for ; Fri, 13 May 2005 11:45:52 -0400 (EDT) Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWccH-0004Jo-8I for isms@ietf.org; Fri, 13 May 2005 12:02:24 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4DFiWHj017402; Fri, 13 May 2005 15:44:32 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j4DFiWt0009451; Fri, 13 May 2005 15:44:32 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005051308443225974 ; Fri, 13 May 2005 08:44:32 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 08:44:25 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 08:44:24 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 11:44:23 -0400 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] TLS / SSH scalability concerns Date: Fri, 13 May 2005 11:43:42 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C592901220F36@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] TLS / SSH scalability concerns Thread-Index: AcVXN2WH0ImXOU2FRYq2J3QM9uC88QAA1d7wACWtHYA= From: "Blumenthal, Uri" To: "Khanh Nguyen \(khanhvn\)" X-OriginalArrivalTime: 13 May 2005 15:44:23.0749 (UTC) FILETIME=[A2E36F50:01C557D2] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 > FYI (in case you not already know): >=20 > http://www.umiacs.umd.edu/docs/Du.ppt > > They concluded that SNMP/TLS was more efficient than USM.=20 And I have a very nice bridge for sale in the vicinity of NYC. :-) > Anyway, these results need to be taken w/ a grain of salt as > there are many factors (e.g. # msgs per session) that may > affect the results. The facts are: - SNMP spends extra cycles on ASN.1 security wrapping/unwrapping; - TLS spends extra cycles on TCP overhead; - TLS has large session establishment overhead; - DES/AES and MD5/SHA1 is done by both, and the cost is similar. Therefore, the more messages are sent within one long session - the greater the chance of amortizing the session establishment cost and come out even (seems rather obvious). As for TLS solution turning out *more* efficient - forgive me for not entirely trusting those results (assuming apples-to-apples comparison, i.e. using SNMPv3 in both cases). _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 13 12:39:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWdCB-0002PZ-SD; Fri, 13 May 2005 12:39:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWdCB-0002PU-3P for isms@megatron.ietf.org; Fri, 13 May 2005 12:39:27 -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 MAA29712 for ; Fri, 13 May 2005 12:39:23 -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 1DWdS7-0006Y0-No for isms@ietf.org; Fri, 13 May 2005 12:55:57 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 13 May 2005 09:39:16 -0700 X-IronPort-AV: i="3.93,107,1115017200"; d="scan'208"; a="264903520:sNHT30960432" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4DGdAO3029428; Fri, 13 May 2005 09:39:10 -0700 (PDT) Received: from [212.254.247.3] (ams-clip-vpn-dhcp405.cisco.com [10.61.65.149]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4DGSn5R028793; Fri, 13 May 2005 09:28:50 -0700 Message-ID: <4284D82F.2000304@cisco.com> Date: Fri, 13 May 2005 18:39:11 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Blumenthal, Uri" Subject: Re: [Isms] TLS / SSH scalability concerns References: <3DEC199BD7489643817ECA151F7C592901220F36@pysmsx401.amr.corp.intel.com> In-Reply-To: <3DEC199BD7489643817ECA151F7C592901220F36@pysmsx401.amr.corp.intel.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1116001731.741883"; x:"432200"; a:"rsa-sha1"; b:"nofws:1477"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"V4fUDIQ+DLeVCmC7lHiYxyNRfflTAfwR1fyi7VrhxBaIRo5+t3OZk7s5thB/RWSNRjqjDTEb" "CAg6X2BTgRxHQkmXtPfFRjWAhahfdcqEwZgildlVjCGSj8nL/iY47PwAZe+d4l6WNtl9J2jKmQm" "SlFig7akooBCIM0DZnl0XKVM="; c:"Date: Fri, 13 May 2005 18:39:11 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] TLS / SSH scalability concerns" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I think there might be some truth on both sides of this issue. For instance, maintaining established sessions goes to Juergen's point that you need to keep getting the biggest baddest largest server to manage "All of This". On the other hand, if you're not taking authentication steps on each packet there's something to be gained, I'm sure. I think it's safe to say that people know how to deal with both. And I actually think a whole lot of people know a whole lot more about TLS. That has certain benefits. I would imagine the same thing will be able to be said about DTLS, assuming a major app picks it up. SIP? Something else? Eliot Blumenthal, Uri wrote: >>FYI (in case you not already know): >> >>http://www.umiacs.umd.edu/docs/Du.ppt >> >>They concluded that SNMP/TLS was more efficient than USM. > > > And I have a very nice bridge for sale in the vicinity of NYC. :-) > > >>Anyway, these results need to be taken w/ a grain of salt as >>there are many factors (e.g. # msgs per session) that may >>affect the results. > > > The facts are: > - SNMP spends extra cycles on ASN.1 security wrapping/unwrapping; > - TLS spends extra cycles on TCP overhead; > - TLS has large session establishment overhead; > - DES/AES and MD5/SHA1 is done by both, and the cost is similar. > > Therefore, the more messages are sent within one long session - the > greater the chance of amortizing the session establishment cost and come > out even (seems rather obvious). As for TLS solution turning out *more* > efficient - forgive me for not entirely trusting those results (assuming > apples-to-apples comparison, i.e. using SNMPv3 in both cases). > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 13 12:45:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWdHm-0003dO-9o; Fri, 13 May 2005 12:45:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWdHl-0003d0-1h for isms@megatron.ietf.org; Fri, 13 May 2005 12:45:13 -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 MAA00358 for ; Fri, 13 May 2005 12:45:09 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWdXh-0006n3-0y for isms@ietf.org; Fri, 13 May 2005 13:01:42 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j4DGiqFT008308; Fri, 13 May 2005 09:44:52 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Fri, 13 May 2005 09:44:52 -0700 Message-ID: From: "McDonald, Ira" To: "'Eliot Lear'" , "Blumenthal, Uri" Subject: RE: [Isms] TLS / SSH scalability concerns Date: Fri, 13 May 2005 09:44:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, With regard to SIP using DTLS, folks may want to read (February 2005). Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On > Behalf Of Eliot Lear > Sent: Friday, May 13, 2005 12:39 PM > To: Blumenthal, Uri > Cc: isms@ietf.org > Subject: Re: [Isms] TLS / SSH scalability concerns > > > I think there might be some truth on both sides of this issue. For > instance, maintaining established sessions goes to Juergen's > point that > you need to keep getting the biggest baddest largest server to manage > "All of This". On the other hand, if you're not taking > authentication > steps on each packet there's something to be gained, I'm sure. > > I think it's safe to say that people know how to deal with > both. And I > actually think a whole lot of people know a whole lot more about TLS. > That has certain benefits. I would imagine the same thing > will be able > to be said about DTLS, assuming a major app picks it up. SIP? > Something else? > > Eliot > > Blumenthal, Uri wrote: > >>FYI (in case you not already know): > >> > >>http://www.umiacs.umd.edu/docs/Du.ppt > >> > >>They concluded that SNMP/TLS was more efficient than USM. > > > > > > And I have a very nice bridge for sale in the vicinity of NYC. :-) > > > > > >>Anyway, these results need to be taken w/ a grain of salt as > >>there are many factors (e.g. # msgs per session) that may > >>affect the results. > > > > > > The facts are: > > - SNMP spends extra cycles on ASN.1 security wrapping/unwrapping; > > - TLS spends extra cycles on TCP overhead; > > - TLS has large session establishment overhead; > > - DES/AES and MD5/SHA1 is done by both, and the cost is similar. > > > > Therefore, the more messages are sent within one long session - the > > greater the chance of amortizing the session establishment > cost and come > > out even (seems rather obvious). As for TLS solution > turning out *more* > > efficient - forgive me for not entirely trusting those > results (assuming > > apples-to-apples comparison, i.e. using SNMPv3 in both cases). > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 13 13:19:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWdp9-0002Ec-Ck; Fri, 13 May 2005 13:19:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWdp7-0002EX-Lz for isms@megatron.ietf.org; Fri, 13 May 2005 13:19:41 -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 NAA06942 for ; Fri, 13 May 2005 13:19:38 -0400 (EDT) Received: from iaff2.i.pppool.de ([85.73.175.242] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWe54-00004t-NC for isms@ietf.org; Fri, 13 May 2005 13:36:12 -0400 Received: by boskop.local (Postfix, from userid 501) id 8596E2E6DF2; Fri, 13 May 2005 19:19:27 +0200 (CEST) Date: Fri, 13 May 2005 19:19:27 +0200 From: Juergen Schoenwaelder To: "Blumenthal, Uri" Subject: Re: [Isms] TLS / SSH scalability concerns Message-ID: <20050513171927.GA1191@boskop.local> Mail-Followup-To: "Blumenthal, Uri" , "Khanh Nguyen (khanhvn)" , isms@ietf.org References: <3DEC199BD7489643817ECA151F7C592901220F36@pysmsx401.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DEC199BD7489643817ECA151F7C592901220F36@pysmsx401.amr.corp.intel.com> User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Fri, May 13, 2005 at 11:43:42AM -0400, Blumenthal, Uri wrote: > As for TLS solution turning out *more* > efficient - forgive me for not entirely trusting those results (assuming > apples-to-apples comparison, i.e. using SNMPv3 in both cases). Larger message sizes, reduced overhead due to session state, perhaps better optimized libraries. Message size is a very important parameter. There is a paper in the Fall issue of the IEEE electronic Transactions on Network and Service Management (eTNSM) which compares SNMP performance with Web Services and one of the conclusion is that several commercial SNMP implementations exhibit interesting performance behaviour. It seems that SNMP performance does not get that much attention and things sometimes are less optimized than what one would expect. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 13 14:26:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWerb-0004Jp-FA; Fri, 13 May 2005 14:26:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWera-0004Jk-BC for isms@megatron.ietf.org; Fri, 13 May 2005 14:26:18 -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 OAA11792 for ; Fri, 13 May 2005 14:26:16 -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 1DWf7Z-0002dx-2f for isms@ietf.org; Fri, 13 May 2005 14:42:49 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 13 May 2005 11:26:08 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4DIPuO5017824; Fri, 13 May 2005 11:25:59 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 11:26:02 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] TLS / SSH scalability concerns Date: Fri, 13 May 2005 11:26:01 -0700 Message-ID: Thread-Topic: [Isms] TLS / SSH scalability concerns Thread-Index: AcVXN2WH0ImXOU2FRYq2J3QM9uC88QAA1d7wACWtHYAABRLfIA== From: "Khanh Nguyen \(khanhvn\)" To: "Blumenthal, Uri" X-OriginalArrivalTime: 13 May 2005 18:26:02.0257 (UTC) FILETIME=[37A65010:01C557E9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Is it possible that the way USM uses DES causes inefficiency? DES is a stream cipher, but USM uses it to encrypt short messages. DES IV needs to be re-initialized repeatedly for each USM message, and the IV salt needs to be appended to each message. That seems=20 to be more overhead compared to TLS (init DES only once per session) I don't know much about DTLS, but it may face a similar issue=20 (i.e. using stream ciphers to encrypt short, unreliable datagrams) =20 Does anyone know how DTLS solves this issue? Does it need to re-init DES per datagram? Khanh=20 > From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 >=20 > The facts are: > - SNMP spends extra cycles on ASN.1 security wrapping/unwrapping; > - TLS spends extra cycles on TCP overhead; > - TLS has large session establishment overhead; > - DES/AES and MD5/SHA1 is done by both, and the cost is similar. >=20 > Therefore, the more messages are sent within one long session=20 > - the greater the chance of amortizing the session=20 > establishment cost and come out even (seems rather obvious).=20 > As for TLS solution turning out *more* efficient - forgive me=20 > for not entirely trusting those results (assuming=20 > apples-to-apples comparison, i.e. using SNMPv3 in both cases). _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 13 14:41:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWf6N-0006qY-QU; Fri, 13 May 2005 14:41:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWf6L-0006qT-SQ for isms@megatron.ietf.org; Fri, 13 May 2005 14:41:33 -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 OAA12948 for ; Fri, 13 May 2005 14:41:31 -0400 (EDT) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWfMJ-0003DC-GF for isms@ietf.org; Fri, 13 May 2005 14:58:04 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4DIdHI7015840; Fri, 13 May 2005 18:39:17 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j4DIdHt0009355; Fri, 13 May 2005 18:39:17 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005051311391612565 ; Fri, 13 May 2005 11:39:17 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 11:39:07 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 11:39:07 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 14:39:05 -0400 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] TLS / SSH scalability concerns Date: Fri, 13 May 2005 14:38:24 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929012210C7@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] TLS / SSH scalability concerns Thread-Index: AcVXN2WH0ImXOU2FRYq2J3QM9uC88QAA1d7wACWtHYAABRLfIAABN55A From: "Blumenthal, Uri" To: "Khanh Nguyen \(khanhvn\)" X-OriginalArrivalTime: 13 May 2005 18:39:05.0773 (UTC) FILETIME=[0AA95DD0:01C557EB] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 > Is it possible that the way USM uses DES causes inefficiency? Hmm, maybe... But to a noticeable extent...? > DES [you mean CFB mode] is a stream cipher, but USM uses it to encrypt > short messages. DES IV needs to be re-initialized repeatedly for each > USM message, and the IV salt needs to be appended to each message.=20 > That seems to be more overhead compared to TLS (init DES only once > per session) True... Good observation! > I don't know much about DTLS, but it may face a similar issue=20 > (i.e. using stream ciphers to encrypt short, unreliable datagrams) =20 > Does anyone know how DTLS solves this issue? Does it need to > re-init DES per datagram? On the other hand, not reinitializing the IV can lead to attacks... _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 13 15:17:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWffB-0003nl-VN; Fri, 13 May 2005 15:17:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWffB-0003ng-9e for isms@megatron.ietf.org; Fri, 13 May 2005 15:17:33 -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 PAA18323 for ; Fri, 13 May 2005 15:17:31 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWfv9-0004hO-Fn for isms@ietf.org; Fri, 13 May 2005 15:34:04 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-4.cisco.com with ESMTP; 13 May 2005 12:17:21 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4DJHGPq024219; Fri, 13 May 2005 12:17:18 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 12:17:17 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] TLS / SSH scalability concerns Date: Fri, 13 May 2005 12:17:16 -0700 Message-ID: Thread-Topic: [Isms] TLS / SSH scalability concerns Thread-Index: AcVXN2WH0ImXOU2FRYq2J3QM9uC88QAA1d7wACWtHYAABRLfIAABN55AAABzlhA= From: "Khanh Nguyen \(khanhvn\)" To: "Blumenthal, Uri" X-OriginalArrivalTime: 13 May 2005 19:17:18.0008 (UTC) FILETIME=[60F0AB80:01C557F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > -----Original Message----- > From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 >=20 >> I don't know much about DTLS, but it may face a similar issue (i.e.=20 >> using stream ciphers to encrypt short, unreliable datagrams) Does=20 >> anyone know how DTLS solves this issue? Does it need to re-init DES=20 >> per datagram? >=20 > On the other hand, not reinitializing the IV can lead to attacks... > That's right. That's why I don't think DTLS (or any datagram transport) can do any better than USM regarding this issue. =20 Khanh=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat May 14 18:47:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DX5QB-0003R8-TL; Sat, 14 May 2005 18:47:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DX5Q8-0003R3-Fa for isms@megatron.ietf.org; Sat, 14 May 2005 18:47: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 SAA11003 for ; Sat, 14 May 2005 18:47:39 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DX5gI-00028I-VH for isms@ietf.org; Sat, 14 May 2005 19:04:28 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j4EMkCUd010070; Sat, 14 May 2005 15:46:12 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sat, 14 May 2005 15:46:11 -0700 Message-ID: From: "McDonald, Ira" To: "'Khanh Nguyen (khanhvn)'" , "Blumenthal, Uri" Subject: RE: [Isms] TLS / SSH scalability concerns Date: Sat, 14 May 2005 15:46:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, DTLS is explained (in current ) in terms of differences from TLS/1.1 (work-in-progress from IETF TLS WG). In particular, note the following excerpts: 3.1. Loss-insensitive messaging In TLS's traffic encryption layer (called the TLS Record Layer), records are not independent. There are two kinds of inter-record dependency: 1. Cryptographic context (CBC state, stream cipher key stream) is chained between records. 2. Anti-replay and message reordering protection are provided by a MAC which includes a sequence number, but the sequence numbers are implicit in the records. The fix for both of these problems is straightforward and well-known from IPsec ESP [ESP]: add explicit state to the records. TLS 1.1 [TLS11] is already adding explicit CBC state to TLS records. DTLS borrows that mechanism and adds explicit sequence numbers. <...> 4.1.2.2. Null or standard stream cipher The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL cipher. The only stream cipher described in TLS 1.1 is RC4, which cannot be randomly accessed. RC4 MUST NOT be used with DTLS. 4.1.2.3. Block Cipher DTLS block cipher encryption and decryption are performed exactly as with TLS 1.1. 4.1.2.4. New Cipher Suites Upon registration, new TLS cipher suites MUST indicate whether they are suitable for DTLS usage and what, if any, adaptations must be made. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On > Behalf Of Khanh Nguyen (khanhvn) > Sent: Friday, May 13, 2005 2:26 PM > To: Blumenthal, Uri > Cc: isms@ietf.org > Subject: RE: [Isms] TLS / SSH scalability concerns > > > Is it possible that the way USM uses DES causes inefficiency? > DES is a stream cipher, but USM uses it to encrypt short messages. > DES IV needs to be re-initialized repeatedly for each USM message, > and the IV salt needs to be appended to each message. That seems > to be more overhead compared to TLS (init DES only once per session) > > I don't know much about DTLS, but it may face a similar issue > (i.e. using stream ciphers to encrypt short, unreliable datagrams) > Does anyone know how DTLS solves this issue? Does it need to > re-init DES per datagram? > > Khanh > > > From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com] > > > > The facts are: > > - SNMP spends extra cycles on ASN.1 security wrapping/unwrapping; > > - TLS spends extra cycles on TCP overhead; > > - TLS has large session establishment overhead; > > - DES/AES and MD5/SHA1 is done by both, and the cost is similar. > > > > Therefore, the more messages are sent within one long session > > - the greater the chance of amortizing the session > > establishment cost and come out even (seems rather obvious). > > As for TLS solution turning out *more* efficient - forgive me > > for not entirely trusting those results (assuming > > apples-to-apples comparison, i.e. using SNMPv3 in both cases). > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 16 12:30:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXiTl-0004vR-Rm; Mon, 16 May 2005 12:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXiTk-0004um-1q for isms@megatron.ietf.org; Mon, 16 May 2005 12:30: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 MAA06012 for ; Mon, 16 May 2005 12:30:00 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXijN-0001Rj-Uw for isms@ietf.org; Mon, 16 May 2005 12:46:15 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA09356; Mon, 16 May 2005 09:28:53 -0700 (PDT) Received: from XCH-NWBH-02.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 j4GGSnN26169; Mon, 16 May 2005 09:28:49 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 09:28:46 -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] TLS / SSH scalability concerns Date: Mon, 16 May 2005 09:28:26 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC2BA@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] TLS / SSH scalability concerns Thread-Index: AcVXN2WH0ImXOU2FRYq2J3QM9uC88QAA1d7wAL4SUOA= From: "Fleischman, Eric" To: "Khanh Nguyen \(khanhvn\)" , , X-OriginalArrivalTime: 16 May 2005 16:28:46.0654 (UTC) FILETIME=[5557BDE0:01C55A34] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Khanh, I've seen those figures as well as another study stating that SNMP performed better over TCP than over UDP. However, our own experience is that local environmental issues dramatically effect performance. For example, performance characteristics over wired LANs and wired WANs can differ, depending on local factors. The performance deltas within wireless environments can be quite significant, depending on whether one is using WLANs, Mobile IP, NEMO, or MANET. TCP performance over satellites is becoming well known and significantly impacts the application being conveyed. My point being that the reason I have been emphasizing the need for flexibility is because there are so many different possible environments, and large enterprises need to be able to tweak configurations appropriately. --Eric -----Original Message----- From: Khanh Nguyen (khanhvn) [mailto:khanhvn@cisco.com]=20 Sent: Thursday, May 12, 2005 2:49 PM To: j.schoenwaelder@iu-bremen.de; isms@ietf.org Subject: RE: [Isms] TLS / SSH scalability concerns FYI (in case you not already know): http://www.umiacs.umd.edu/docs/Du.ppt They concluded that SNMP/TLS was more efficient than USM. Anyway, these results need to be taken w/ a grain of salt as there are many factors (e.g. # msgs per session) that may affect the results. Khanh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 16 14:58:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXknY-00061o-K2; Mon, 16 May 2005 14:58:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXknX-00060e-NM for isms@megatron.ietf.org; Mon, 16 May 2005 14:58:39 -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 OAA23743 for ; Mon, 16 May 2005 14:58:38 -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 1DXl47-0000G9-QF for isms@ietf.org; Mon, 16 May 2005 15:15:49 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 16 May 2005 11:58:27 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4GIwAEb027396; Mon, 16 May 2005 11:58:22 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 11:58:24 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] TLS / SSH scalability concerns Date: Mon, 16 May 2005 11:58:23 -0700 Message-ID: Thread-Topic: [Isms] TLS / SSH scalability concerns Thread-Index: AcVY1uyAUio6PONPSwWsMY6qitu0rgBZzZow From: "Khanh Nguyen \(khanhvn\)" To: "McDonald, Ira" X-OriginalArrivalTime: 16 May 2005 18:58:24.0312 (UTC) FILETIME=[3C71A380:01C55A49] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 > From: McDonald, Ira [mailto:imcdonald@sharplabs.com]=20 > > DTLS is explained (in current )=20 > in terms of differences from TLS/1.1 (work-in-progress from=20 > IETF TLS WG). Thanks Ira for the info. Looks like DTLS relies on TLS 1.1=20 "explicit IV", which prepends a block of random data to each=20 TLS data record. As a side effect of this, records can be=20 decrypted individually (no record chaining). Note that=20 TLS 1.1 & explicit IV is a proposal, not a standard (yet). > 4.1.2.3. Block Cipher >=20 > DTLS block cipher encryption and decryption are performed > exactly as with TLS 1.1. Well... except the record sizes are different. The extra=20 block in each record is a small overhead for TLS, but can be=20 a bigger one for DTLS, since TLS max record size is ~16Kb,=20 while DTLS max rec size is limited by datagram MTU (~1.5Kb). So in a sense, DTLS faces the same issue as USM: using a=20 bulk cipher to encypt short datagram. BTW, I also found this: http://crypto.stanford.edu/~nagendra/papers/dtls.pdf I haven't read thru it yet, but near the end, DTLS authors=20 acknowledged that DTLS had more overhead than TLS. Khanh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 16 15:21:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXl9y-0003MA-NJ; Mon, 16 May 2005 15:21:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXl9v-0003IU-9r for isms@megatron.ietf.org; Mon, 16 May 2005 15:21:49 -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 PAA27683 for ; Mon, 16 May 2005 15:21:45 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXlQV-0001Om-Am for isms@ietf.org; Mon, 16 May 2005 15:38:56 -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 j4GJLWIg029211; Mon, 16 May 2005 12:21:32 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j4GJLT37026161; Mon, 16 May 2005 12:21:29 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j4GJLTHu026158; Mon, 16 May 2005 12:21:29 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 16 May 2005 12:21:29 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Khanh Nguyen (khanhvn)" Subject: RE: [Isms] TLS / SSH scalability concerns In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, Have you compared DTLS using SHA and AES vs USM using SHA and AES? Using a new security model will allow the definition of syntax of the msgSecurityParameters field, since it probably no longer needs many of the values needed to support USM (since they are part of either session establishment or done by DTLS). Regards, /david t. perkins On Mon, 16 May 2005, Khanh Nguyen (khanhvn) wrote: > > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > > > > DTLS is explained (in current ) > > in terms of differences from TLS/1.1 (work-in-progress from > > IETF TLS WG). > > Thanks Ira for the info. Looks like DTLS relies on TLS 1.1 > "explicit IV", which prepends a block of random data to each > TLS data record. As a side effect of this, records can be > decrypted individually (no record chaining). Note that > TLS 1.1 & explicit IV is a proposal, not a standard (yet). > > > 4.1.2.3. Block Cipher > > > > DTLS block cipher encryption and decryption are performed > > exactly as with TLS 1.1. > > Well... except the record sizes are different. The extra > block in each record is a small overhead for TLS, but can be > a bigger one for DTLS, since TLS max record size is ~16Kb, > while DTLS max rec size is limited by datagram MTU (~1.5Kb). > So in a sense, DTLS faces the same issue as USM: using a > bulk cipher to encypt short datagram. > > BTW, I also found this: > http://crypto.stanford.edu/~nagendra/papers/dtls.pdf > > I haven't read thru it yet, but near the end, DTLS authors > acknowledged that DTLS had more overhead than TLS. > > Khanh > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 16 15:30:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXlIe-00058w-9x; Mon, 16 May 2005 15:30:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXlIc-00058r-Ei for isms@megatron.ietf.org; Mon, 16 May 2005 15:30: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 PAA28713 for ; Mon, 16 May 2005 15:30:44 -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 1DXlZC-0001oJ-No for isms@ietf.org; Mon, 16 May 2005 15:47:56 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 16 May 2005 12:30:36 -0700 X-IronPort-AV: i="3.93,112,1115017200"; d="scan'208"; a="265895299:sNHT29602084" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4GJUIEb021397; Mon, 16 May 2005 12:30:31 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 12:30:21 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] TLS / SSH scalability concerns Date: Mon, 16 May 2005 12:30:20 -0700 Message-ID: Thread-Topic: [Isms] TLS / SSH scalability concerns Thread-Index: AcVXN2WH0ImXOU2FRYq2J3QM9uC88QAA1d7wAL4SUOAABkZ7oA== From: "Khanh Nguyen \(khanhvn\)" To: "Fleischman, Eric" , X-OriginalArrivalTime: 16 May 2005 19:30:21.0100 (UTC) FILETIME=[B2F046C0:01C55A4D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 > From: Fleischman, Eric [mailto:eric.fleischman@boeing.com]=20 >=20 > Khanh, >=20 > I've seen those figures as well as another study stating that=20 > SNMP performed better over TCP than over UDP. However, our=20 > own experience is that local environmental issues=20 > dramatically effect performance. For example, performance=20 > characteristics over wired LANs and wired WANs can differ,=20 > depending on local factors. The performance deltas within=20 > wireless environments can be quite significant, depending on=20 > whether one is using WLANs, Mobile IP, NEMO, or MANET. TCP=20 > performance over satellites is becoming well known and=20 > significantly impacts the application being conveyed. My=20 > point being that the reason I have been emphasizing the need=20 > for flexibility is because there are so many different=20 > possible environments, and large enterprises need to be able=20 > to tweak configurations appropriately. >=20 Eric, I am with you about this. I just have some concerns about=20 the efficency of using UDP for secure transport. UDP in=20 general has less overhead than TCP, but the situation may=20 be reversed when security is added (e.g. DTLS has more=20 overhead than TLS). Anyway, efficiency is just one of many factors to be considered, and I agree with you that=20 SNMP should have the transport flexibility, and let the=20 operators decide what's best for their environments. Khanh > > --Eric >=20 > -----Original Message----- > From: Khanh Nguyen (khanhvn) [mailto:khanhvn@cisco.com] > Sent: Thursday, May 12, 2005 2:49 PM > To: j.schoenwaelder@iu-bremen.de; isms@ietf.org > Subject: RE: [Isms] TLS / SSH scalability concerns >=20 >=20 > FYI (in case you not already know): >=20 > http://www.umiacs.umd.edu/docs/Du.ppt >=20 > They concluded that SNMP/TLS was more efficient than USM. =20 > Anyway, these > results need to be taken w/ a grain of salt as there are many factors > (e.g. # msgs per session) that may affect the results. >=20 > Khanh >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 16 18:15:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXnrd-000754-1p; Mon, 16 May 2005 18:15:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXnrb-00074H-2v for isms@megatron.ietf.org; Mon, 16 May 2005 18:15: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 SAA03156 for ; Mon, 16 May 2005 18:15:00 -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 1DXo86-0006a0-Ef for isms@ietf.org; Mon, 16 May 2005 18:32:07 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id D25FC11D739; Mon, 16 May 2005 15:14:32 -0700 (PDT) From: Wes Hardaker To: Kaushik Narayan Subject: Re: [Isms] TLS / SSH scalability concerns Organization: Sparta References: <3DEC199BD7489643817ECA151F7C592901220891@pysmsx401.amr.corp.intel.com> <6.2.0.14.0.20050512131355.039ae338@email.cisco.com> <20050512210958.GA1254@boskop.local> Date: Mon, 16 May 2005 15:14:32 -0700 In-Reply-To: <20050512210958.GA1254@boskop.local> (Juergen Schoenwaelder's message of "Thu, 12 May 2005 23:09:58 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Thu, 12 May 2005 23:09:58 +0200, Juergen Schoenwaelder said: Juergen> I do agree that scalability needs to be taken into account and that Juergen> this is a real issue (while repairing broken networks with SNMP Juergen> really is a myths in my view a non-issue). I agree too. I think it's important to leave to the operators, when possible, about which solutions to pick from. Documentation for a product will hopeful discuss the pros and cons of certain deployment scenarios. One thing to consider when thinking about the problem of how many connections a manager can handle will not just be the raw number, but *where* the impact will be. One of the reasons that TCP didn't do really well back in the days of yore with small amounts of memory is that the TCP stack is implemented in the kernel. Thus, expansion to a huge number of connections there suffers from the fact that generally today's OSes can't swap out kernel memory. Thus, a huge increase in TCP connections meant DoSing the machine pretty easily. Some of the connection types we are considering will have vastly different impacts based on the underlying transport. EG, a TLS connection certainly will have ramifications that affect kernel tables since it's based on TCP. However, I think that the majority of the data for the security half of TLS will be in application space not in kernel space which is good. Even better, in the case of DTLS where the underlying protocol is UDP based the ratio of kernel to user space requirements will be even lower I think. Thus, picking the right scalable solution will certainly require selecting the best transport in an EK approach. But don't blame the problem on EK itself. Somewhere, somehow data must be stored for a secure connection and of course there is no way around that. Instead you have to compare the size and where it is likely to be stored. EG, if you compare DTLS and SNMPv3/USM I think you'd find that the kernel requirements will be identical. The size of the application space might be larger for DTLS, however, but I have zero data to back that up with and I think the difference will likely be fairly small. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 16 18:37:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXoDR-0004ly-DE; Mon, 16 May 2005 18:37:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXoDQ-0004lb-2x for isms@megatron.ietf.org; Mon, 16 May 2005 18:37:36 -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 SAA08854 for ; Mon, 16 May 2005 18:37:31 -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 1DXoDZ-0007OZ-2i for isms@ietf.org; Mon, 16 May 2005 18:37:46 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 1F61F11D739; Mon, 16 May 2005 15:20:25 -0700 (PDT) From: Wes Hardaker To: "Khanh Nguyen (khanhvn)" Subject: Re: [Isms] TLS / SSH scalability concerns Organization: Sparta References: Date: Mon, 16 May 2005 15:20:23 -0700 In-Reply-To: (Khanh Nguyen's message of "Thu, 12 May 2005 14:49:08 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Thu, 12 May 2005 14:49:08 -0700, "Khanh Nguyen (khanhvn)" said: Khanh> FYI (in case you not already know): Khanh> http://www.umiacs.umd.edu/docs/Du.ppt After that presentation was given, I actually stood up to the microphone and explained a number of the biases in it that made it an unfair comparison. In summary, they were comparing an optimized implementation that had been around for a while against one that had never been optimized and was even implemented in less-than-optimal ways at times due to the fact it was supposed to be a reference implementation. The authors agreed that their data was based on the only 2 data points and they couldn't do a better analysis since they had no other data to go by and that the margin of error was likely fairly high. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 16 18:42:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXoHz-0005JG-1R; Mon, 16 May 2005 18:42:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXoHy-0005J8-AH for isms@megatron.ietf.org; Mon, 16 May 2005 18:42:18 -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 SAA09706 for ; Mon, 16 May 2005 18:42:15 -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 1DXoYa-0000Zi-EU for isms@ietf.org; Mon, 16 May 2005 18:59:29 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id E264A11D7EB; Mon, 16 May 2005 15:42:12 -0700 (PDT) From: Wes Hardaker To: "Khanh Nguyen (khanhvn)" Subject: Re: [Isms] TLS / SSH scalability concerns Organization: Sparta References: Date: Mon, 16 May 2005 15:42:10 -0700 In-Reply-To: (Wes Hardaker's message of "Mon, 16 May 2005 15:20:23 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Mon, 16 May 2005 15:20:23 -0700, Wes Hardaker said: Khanh> FYI (in case you not already know): Khanh> http://www.umiacs.umd.edu/docs/Du.ppt Wes> After that presentation was given, I actually stood up to the Wes> microphone and explained a number of the biases in it that made it an Wes> unfair comparison. I should follow that up with it's not that I don't believe that the results are true. They may be. I just don't trust that particular data set at all to draw that conclusion from. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 16 19:31:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXp3U-0003nZ-BF; Mon, 16 May 2005 19:31:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXp3S-0003nU-Sp for isms@megatron.ietf.org; Mon, 16 May 2005 19:31:23 -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 TAA15445 for ; Mon, 16 May 2005 19:31:19 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXpK5-0003ey-97 for isms@ietf.org; Mon, 16 May 2005 19:48:34 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 16 May 2005 16:31:12 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j4GNV4rE021312; Mon, 16 May 2005 16:31:09 -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); Mon, 16 May 2005 16:31:08 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] TLS / SSH scalability concerns Date: Mon, 16 May 2005 16:31:08 -0700 Message-ID: Thread-Topic: [Isms] TLS / SSH scalability concerns Thread-Index: AcVaTINQBzjHnW/QRuSAkkZyrxKg0wAEvwtQ From: "Khanh Nguyen \(khanhvn\)" To: "David T. Perkins" X-OriginalArrivalTime: 16 May 2005 23:31:08.0550 (UTC) FILETIME=[564A3260:01C55A6F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 > From: David T. Perkins [mailto:dperkins@dsperkins.com]=20 >=20 > Have you compared DTLS using SHA and AES vs USM using SHA and AES? No, and I am not aware of any performance analysis/test that=20 compares DTLS-AES vs USM-AES. AES CBC modes is similar to=20 DES, so I guess DTLS-AES will have similar overhead as DTLS-DES. =20 =20 BTW, this brough up a related issue: I am wondering if=20 DES/AES OFM (Output Feedback Mode) is more suitable than CBC=20 mode (which DTLS uses) to encrypt unreliable UDP datagrams. OFM was designed for noisy/lossy channel (e.g. satelite=20 communication). Unlike CBC, OFM blocks can be decrypted=20 individually, and transmission errors do not propagate to=20 the next blocks, so OFM may be a good fit for unreliable=20 UDP transport & troubleshooting mal-function networks. =20 Another alternative is the new CRT (Counter) mode that NIST recently adopted for AES. Like OFM, CRT blocks can be=20 decrypted individually. =20 > Using a new security model will allow the definition of=20 > syntax of the msgSecurityParameters field, since it probably=20 > no longer needs many of the values needed to support USM=20 > (since they are part of either session establishment or done by DTLS). That's true. Khanh >=20 > Regards, > /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 16 19:45:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXpHP-0007yN-5h; Mon, 16 May 2005 19:45:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXpHN-0007yI-Tr for isms@megatron.ietf.org; Mon, 16 May 2005 19:45:45 -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 TAA16991 for ; Mon, 16 May 2005 19:45:42 -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 1DXpY0-0004Td-J6 for isms@ietf.org; Mon, 16 May 2005 20:02:57 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 16 May 2005 16:45:35 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4GNikF3002306; Mon, 16 May 2005 16:45:28 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 16:45:30 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] TLS / SSH scalability concerns Date: Mon, 16 May 2005 16:45:30 -0700 Message-ID: Thread-Topic: [Isms] TLS / SSH scalability concerns Thread-Index: AcVaaLTWC/kx36WETSqUFE7QU6BZtwABsBvg From: "Khanh Nguyen \(khanhvn\)" To: "Wes Hardaker" X-OriginalArrivalTime: 16 May 2005 23:45:30.0699 (UTC) FILETIME=[582BB1B0:01C55A71] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com]=20 >=20 > Khanh> FYI (in case you not already know): > Khanh> http://www.umiacs.umd.edu/docs/Du.ppt >=20 > Wes> After that presentation was given, I actually stood up to the=20 > Wes> microphone and explained a number of the biases in it that made it=20 > Wes> an unfair comparison. >=20 > I should follow that up with it's not that I don't believe=20 > that the results are true. They may be. I just don't trust=20 > that particular data set at all to draw that conclusion from. Sure. Their test cases seem to be very limited. We don't=20 have other empirical data to either confirm of counter their=20 conclusions, but I think in the end, things may go both ways depend on the environments. Khanh >=20 > -- > Wes Hardaker > Sparta, Inc. >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 17 02:43:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXvns-0005dy-Q4; Tue, 17 May 2005 02:43:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXvnr-0005bc-0U for isms@megatron.ietf.org; Tue, 17 May 2005 02:43: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 CAA14673 for ; Tue, 17 May 2005 02:43:41 -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 1DXw4X-0001Hc-BR for isms@ietf.org; Tue, 17 May 2005 03:00:58 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 16 May 2005 23:43:32 -0700 X-IronPort-AV: i="3.93,113,1115017200"; d="scan'208"; a="266102837:sNHT28964006" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4H6hTER004993; Mon, 16 May 2005 23:43:29 -0700 (PDT) Received: from [212.254.247.3] (ams-clip-vpn-dhcp4386.cisco.com [10.61.81.33]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4H6WqnH022778; Mon, 16 May 2005 23:32:53 -0700 Message-ID: <4289928F.1070701@cisco.com> Date: Tue, 17 May 2005 08:43:27 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wes Hardaker Subject: Re: [Isms] TLS / SSH scalability concerns References: <3DEC199BD7489643817ECA151F7C592901220891@pysmsx401.amr.corp.intel.com> <6.2.0.14.0.20050512131355.039ae338@email.cisco.com> <20050512210958.GA1254@boskop.local> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1116311574.342543"; x:"432200"; a:"rsa-sha1"; b:"nofws:135"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"ehalHOzmb1BF2q6lUI4An0+PfUJomdf1P3JC2ZegyoKgXaJ3W7nDldOQRQ6vjcuDEUcZPW85" "fuPuY4YdgOkRHICq2ZATpzzF5+J6KIReImBQgU3fGoQgTJn8G+31B2o8EcfvCd7+srGLXyt6i/i" "NNCdEVrnvdpXvnMJXaxsBv08="; c:"Date: Tue, 17 May 2005 08:43:27 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] TLS / SSH scalability concerns" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Wes, Which do you think is more likely to be optimized for performance? TLS/TCP or *anything*/UDP? People spend huge amounts of money just on the former... Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 17 03:43:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXwji-00036s-JD; Tue, 17 May 2005 03:43:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXwjg-00036m-Fo for isms@megatron.ietf.org; Tue, 17 May 2005 03:43:28 -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 DAA18770 for ; Tue, 17 May 2005 03:43:26 -0400 (EDT) Received: from smtp-out.completel.net ([83.145.110.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXx0N-0004EG-5q for isms@ietf.org; Tue, 17 May 2005 04:00:44 -0400 Received: from boskop.local (unknown [195.167.238.7]) by smtp-out.completel.net (Postfix) with ESMTP id BDC6225C16B for ; Tue, 17 May 2005 09:43:17 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 08A352EF1EA; Tue, 17 May 2005 09:43:16 +0200 (CEST) Date: Tue, 17 May 2005 09:43:16 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Subject: Re: [Isms] TLS / SSH scalability concerns Message-ID: <20050517074316.GB4543@boskop.local> Mail-Followup-To: Wes Hardaker , Kaushik Narayan , isms@ietf.org References: <3DEC199BD7489643817ECA151F7C592901220891@pysmsx401.amr.corp.intel.com> <6.2.0.14.0.20050512131355.039ae338@email.cisco.com> <20050512210958.GA1254@boskop.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Mon, May 16, 2005 at 03:14:32PM -0700, Wes Hardaker wrote: > One thing to consider when thinking about the problem of how many > connections a manager can handle will not just be the raw number, but > *where* the impact will be. One of the reasons that TCP didn't do > really well back in the days of yore with small amounts of memory is > that the TCP stack is implemented in the kernel. Thus, expansion to a > huge number of connections there suffers from the fact that generally > today's OSes can't swap out kernel memory. Thus, a huge increase in > TCP connections meant DoSing the machine pretty easily. I think this problem has been recognized and solved about 10 years ago when the Web took off and persistent HTTP connections did not yet exist. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 17 07:01:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXzpH-0007lT-Mg; Tue, 17 May 2005 07:01:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXzpG-0007lK-So for isms@megatron.ietf.org; Tue, 17 May 2005 07:01:26 -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 HAA07861 for ; Tue, 17 May 2005 07:01:23 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY05t-0006ep-Tc for isms@ietf.org; Tue, 17 May 2005 07:18:41 -0400 Received: from pc6 (1Cust175.tnt102.lnd4.gbr.da.uu.net [213.116.52.175]) by galaxy.systems.pipex.net (Postfix) with SMTP id 30E16E00061D; Tue, 17 May 2005 12:01:02 +0100 (BST) Message-ID: <01fa01c55ac6$c08b3460$0601a8c0@pc6> From: "Tom Petch" To: "Wes Hardaker" , "Kaushik Narayan" References: <3DEC199BD7489643817ECA151F7C592901220891@pysmsx401.amr.corp.intel.com><6.2.0.14.0.20050512131355.039ae338@email.cisco.com><20050512210958.GA1254@boskop.local> Subject: Re: [Isms] TLS / SSH scalability concerns Date: Tue, 17 May 2005 11:40: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: 41c17b4b16d1eedaa8395c26e9a251c4 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 There is an assumption buried in this thread that I would challenge, namely that all SNMP sessions will be the same and will be equally secure. From a security standpoint alone, I think this wrong. The more a security technology is used, the less secure it is, so I believe the security should be used only when it is needed. The SNMP manager polling the interface table on n,000 agents every 30 second does not need and should not be using security. Rather, the secure sessions should only be the ones that need it - eg configuration change, anything related to security and such like - which I would expect to be much fewer in number. Tom Petch Original Message ----- From: "Wes Hardaker" To: "Kaushik Narayan" Cc: Sent: Tuesday, May 17, 2005 12:14 AM Subject: Re: [Isms] TLS / SSH scalability concerns > >>>>> On Thu, 12 May 2005 23:09:58 +0200, Juergen Schoenwaelder said: > > Juergen> I do agree that scalability needs to be taken into account and that > Juergen> this is a real issue (while repairing broken networks with SNMP > Juergen> really is a myths in my view a non-issue). > > I agree too. I think it's important to leave to the operators, when > possible, about which solutions to pick from. Documentation for a > product will hopeful discuss the pros and cons of certain deployment > scenarios. > > One thing to consider when thinking about the problem of how many > connections a manager can handle will not just be the raw number, but > *where* the impact will be. One of the reasons that TCP didn't do > really well back in the days of yore with small amounts of memory is > that the TCP stack is implemented in the kernel. Thus, expansion to a > huge number of connections there suffers from the fact that generally > today's OSes can't swap out kernel memory. Thus, a huge increase in > TCP connections meant DoSing the machine pretty easily. > > Some of the connection types we are considering will have vastly > different impacts based on the underlying transport. EG, a TLS > connection certainly will have ramifications that affect kernel tables > since it's based on TCP. However, I think that the majority of the > data for the security half of TLS will be in application space not in > kernel space which is good. Even better, in the case of DTLS where > the underlying protocol is UDP based the ratio of kernel to user space > requirements will be even lower I think. Thus, picking the right > scalable solution will certainly require selecting the best transport > in an EK approach. But don't blame the problem on EK itself. > Somewhere, somehow data must be stored for a secure connection and of > course there is no way around that. Instead you have to compare the > size and where it is likely to be stored. EG, if you compare DTLS and > SNMPv3/USM I think you'd find that the kernel requirements will be > identical. The size of the application space might be larger for > DTLS, however, but I have zero data to back that up with and I think > the difference will likely be fairly small. > > -- > Wes Hardaker > Sparta, Inc. > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 17 07:21:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY08R-0004qr-3o; Tue, 17 May 2005 07:21:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY08Q-0004ql-3M for isms@megatron.ietf.org; Tue, 17 May 2005 07:21:14 -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 HAA09501 for ; Tue, 17 May 2005 07:21:12 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY0P8-0007oB-RE for isms@ietf.org; Tue, 17 May 2005 07:38:32 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 17 May 2005 04:21:04 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j4HBL0rA003477; Tue, 17 May 2005 04:21:00 -0700 (PDT) Received: from [144.254.23.90] (dhcp-data-vlan10-23-90.cisco.com [144.254.23.90]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4HBALGT024298; Tue, 17 May 2005 04:10:22 -0700 Message-ID: <4289D399.6070900@cisco.com> Date: Tue, 17 May 2005 13:20:57 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Petch Subject: Re: [Isms] TLS / SSH scalability concerns References: <3DEC199BD7489643817ECA151F7C592901220891@pysmsx401.amr.corp.intel.com><6.2.0.14.0.20050512131355.039ae338@email.cisco.com><20050512210958.GA1254@boskop.local> <01fa01c55ac6$c08b3460$0601a8c0@pc6> In-Reply-To: <01fa01c55ac6$c08b3460$0601a8c0@pc6> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1116328223.938545"; x:"432200"; a:"rsa-sha1"; b:"nofws:1585"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"Go2wuf5z7SvgSMdb9AK+ObCX+YYzlho7lBCgj9VpvrEQrbSabENFTYESvdBFvWHN37bSXXpd" "3m/8UlLjH9s5nqEZEH2vveDnRRbg991xGitTdCFGjKpvao5cXmvIpUNKtK/b7aE9D56vDT1vp/a" "qkFMSx4419LyBQDk2QK9a0dw="; c:"Date: Tue, 17 May 2005 13:20:57 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] TLS / SSH scalability concerns" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: > There is an assumption buried in this thread that I would challenge, namely that > all SNMP sessions will be the same and will be equally secure. From a security > standpoint alone, I think this wrong. The more a security technology is used, > the less secure it is, so I believe the security should be used only when it is > needed. Perhaps definition of terms is in order, but I will tend to trust mechanisms that are both widely deployed and frequently used more so than I would ones that are niether widely deployed nor frequently used, simply due to the eyeball factor. Now that's not the only factor, but it's an important one. > The SNMP manager polling the interface table on n,000 agents every 30 second > does not need and should not be using security. Let's just agree that the operators of a system may wish to decide the sensitivity of their information. I think VACM designers had this in mind. I, however, am concerned about an operator's ability to make this decision, especially since attacks can develop more rapidly than an operator's ability to respond to them. Also, the level of device configuration required increases to cover each OID tree requiring coverage. Finally, as you begin to nitpick along these lines, the ability of management applications to actually do their thing will diminish if we end up with a situation where the application is configured to retrieve information using "insecure" while all of a sudden the security administrator has made the information accessible via only "secure" means in response to the latest attack. [Ok, I myself am tempted to end that paragraph with Imminent Death of the Net Predicted. ;-] > Rather, the secure sessions > should only be the ones that need it - eg configuration change, anything related > to > security and such like - which I would expect to be much fewer in number. An ever-increasing swamp if ever there was. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 17 09:03:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY1j1-0003PN-V0; Tue, 17 May 2005 09:03:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY1j0-0003PH-He for isms@megatron.ietf.org; Tue, 17 May 2005 09:03:06 -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 JAA19632 for ; Tue, 17 May 2005 09:03:04 -0400 (EDT) Message-Id: <200505171303.JAA19632@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY1zl-0005Kt-4a for isms@ietf.org; Tue, 17 May 2005 09:20:25 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005051713025601400k9o2je>; Tue, 17 May 2005 13:02:56 +0000 From: "David B Harrington" To: Subject: RE: [Isms] TLS / SSH scalability concerns Date: Tue, 17 May 2005 09:02:39 -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: <01fa01c55ac6$c08b3460$0601a8c0@pc6> Thread-Index: AcVaz/XjJG11YaZ0Sja5/RYiJnAuuQADccfA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 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, I understand the concern about the overhead of applying security to everything, and wanting to selectively apply security based on the data involved. However, I think the amount of work to configure different levels of security for different data requests from different users will be significant, and might be a show-stopper. VACM provides a static configuration of data access policy, and I know of nobody that is actively utilizing it in their *operations* (please speak up if you know of environments where it is being actively used). I think that VACM suffers a similar problem to USM - it needs to be dynamically configurable from a central authorization server (or something similar), and/or management applications need to make it easy to configure across a heterogenous network. Let me ask this: when operators connect to the CLI, do they open multiple connections, SSH for "show" commands for sensitive information and to change configurations, and Telnet when they are just monitoring a device? I suspect they just use SSH for both purposes, and eat the overhead. Now SNMP exaggerates the problem compared to CLI, but I think the result will be similar - they'll just have a single secure connection for their SNMP, if we design a reasonably efficient secure connection. Of course, one approach is to use SNMPv3 proxy at a distributed polling engine (mid-level manager) - if a section of the network can be secured via non-SNMP means adequately (mgmt VLANs, source address filtering, etc.) then they might use AuthNoPriv to gather large tables of not-necessarily-sensitive data, such as statistics from the interface tables, then aggregate the tables, and send them over a secure AuthPriv channel to a centralized manager of managers. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Tom Petch > Sent: Tuesday, May 17, 2005 5:40 AM > To: Wes Hardaker; Kaushik Narayan > Cc: isms@ietf.org > Subject: Re: [Isms] TLS / SSH scalability concerns > > There is an assumption buried in this thread that I would > challenge, namely that > all SNMP sessions will be the same and will be equally > secure. From a security > standpoint alone, I think this wrong. The more a security > technology is used, > the less secure it is, so I believe the security should be > used only when it is > needed. > The SNMP manager polling the interface table on n,000 agents > every 30 second > does not need and should not be using security. Rather, the > secure sessions > should only be the ones that need it - eg configuration > change, anything related > to > security and such like - which I would expect to be much > fewer in number. > > Tom Petch > > Original Message ----- > From: "Wes Hardaker" > To: "Kaushik Narayan" > Cc: > Sent: Tuesday, May 17, 2005 12:14 AM > Subject: Re: [Isms] TLS / SSH scalability concerns > > > > >>>>> On Thu, 12 May 2005 23:09:58 +0200, Juergen Schoenwaelder > said: > > > > Juergen> I do agree that scalability needs to be taken into > account and that > > Juergen> this is a real issue (while repairing broken > networks with SNMP > > Juergen> really is a myths in my view a non-issue). > > > > I agree too. I think it's important to leave to the operators, when > > possible, about which solutions to pick from. Documentation for a > > product will hopeful discuss the pros and cons of certain deployment > > scenarios. > > > > One thing to consider when thinking about the problem of how many > > connections a manager can handle will not just be the raw > number, but > > *where* the impact will be. One of the reasons that TCP didn't do > > really well back in the days of yore with small amounts of memory is > > that the TCP stack is implemented in the kernel. Thus, > expansion to a > > huge number of connections there suffers from the fact that > generally > > today's OSes can't swap out kernel memory. Thus, a huge increase in > > TCP connections meant DoSing the machine pretty easily. > > > > Some of the connection types we are considering will have vastly > > different impacts based on the underlying transport. EG, a TLS > > connection certainly will have ramifications that affect > kernel tables > > since it's based on TCP. However, I think that the majority of the > > data for the security half of TLS will be in application > space not in > > kernel space which is good. Even better, in the case of DTLS where > > the underlying protocol is UDP based the ratio of kernel to > user space > > requirements will be even lower I think. Thus, picking the right > > scalable solution will certainly require selecting the best > transport > > in an EK approach. But don't blame the problem on EK itself. > > Somewhere, somehow data must be stored for a secure > connection and of > > course there is no way around that. Instead you have to compare the > > size and where it is likely to be stored. EG, if you > compare DTLS and > > SNMPv3/USM I think you'd find that the kernel requirements will be > > identical. The size of the application space might be larger for > > DTLS, however, but I have zero data to back that up with and I think > > the difference will likely be fairly small. > > > > -- > > Wes Hardaker > > Sparta, Inc. > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 17 13:20:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY5jr-0005GF-TQ; Tue, 17 May 2005 13:20:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY5jr-0005GA-E1 for isms@megatron.ietf.org; Tue, 17 May 2005 13:20:15 -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 NAA17341 for ; Tue, 17 May 2005 13:20:11 -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 1DY60d-0003QB-CE for isms@ietf.org; Tue, 17 May 2005 13:37:36 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 9E39511D731; Tue, 17 May 2005 10:20:07 -0700 (PDT) From: Wes Hardaker To: Eliot Lear Subject: Re: [Isms] TLS / SSH scalability concerns Organization: Sparta References: <3DEC199BD7489643817ECA151F7C592901220891@pysmsx401.amr.corp.intel.com> <6.2.0.14.0.20050512131355.039ae338@email.cisco.com> <20050512210958.GA1254@boskop.local> <4289928F.1070701@cisco.com> Date: Tue, 17 May 2005 10:20:03 -0700 In-Reply-To: <4289928F.1070701@cisco.com> (Eliot Lear's message of "Tue, 17 May 2005 08:43:27 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Tue, 17 May 2005 08:43:27 +0200, Eliot Lear said: Eliot> Which do you think is more likely to be optimized for performance? Eliot> TLS/TCP or *anything*/UDP? People spend huge amounts of money just on Eliot> the former... I don't know. That was my point. I don't have data for this particular case. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 17 13:21:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY5l9-0005NT-Jt; Tue, 17 May 2005 13:21:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY5l7-0005NO-Vm for isms@megatron.ietf.org; Tue, 17 May 2005 13:21:34 -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 NAA17609 for ; Tue, 17 May 2005 13:21:30 -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 1DY61v-0003S6-0n for isms@ietf.org; Tue, 17 May 2005 13:38:55 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 1DE1411D731; Tue, 17 May 2005 10:21:31 -0700 (PDT) From: Wes Hardaker To: "Tom Petch" Subject: Re: [Isms] TLS / SSH scalability concerns Organization: Sparta References: <3DEC199BD7489643817ECA151F7C592901220891@pysmsx401.amr.corp.intel.com> <6.2.0.14.0.20050512131355.039ae338@email.cisco.com> <20050512210958.GA1254@boskop.local> <01fa01c55ac6$c08b3460$0601a8c0@pc6> Date: Tue, 17 May 2005 10:21:29 -0700 In-Reply-To: <01fa01c55ac6$c08b3460$0601a8c0@pc6> (Tom Petch's message of "Tue, 17 May 2005 11:40:06 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Tue, 17 May 2005 11:40:06 +0200, "Tom Petch" said: Tom> The SNMP manager polling the interface table on n,000 agents Tom> every 30 second does not need and should not be using security. Err... Riiiigght. I'm glad those ever important SETs will be done securely at least. Even though the decision about whether to send them might be based on insecure data. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 17 13:29:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY5so-0008AZ-T9; Tue, 17 May 2005 13:29:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY5sn-0008AU-Ea for isms@megatron.ietf.org; Tue, 17 May 2005 13:29:29 -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 NAA18180 for ; Tue, 17 May 2005 13:29:23 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY69X-0003vO-Aa for isms@ietf.org; Tue, 17 May 2005 13:46:48 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j4HHSPe04387; Tue, 17 May 2005 13:28:25 -0400 (EDT) Received: from nortel.com (wcary0w4.ca.nortel.com [47.129.41.8]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 29WLX0S8; Tue, 17 May 2005 13:28:57 -0400 Message-ID: <428A29D8.8090906@nortel.com> Date: Tue, 17 May 2005 13:28:56 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Marcus Leech User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Petch Subject: Re: [Isms] TLS / SSH scalability concerns References: <3DEC199BD7489643817ECA151F7C592901220891@pysmsx401.amr.corp.intel.com><6.2.0.14.0.20050512131355.039ae338@email.cisco.com><20050512210958.GA1254@boskop.local> <01fa01c55ac6$c08b3460$0601a8c0@pc6> In-Reply-To: <01fa01c55ac6$c08b3460$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch wrote: >... From a security >standpoint alone, I think this wrong. The more a security technology is used, >the less secure it is, so I believe the security should be used only when it is >needed. > With the exception of certain badly-engineered cryptosystems, I can't support this statement at all. I don't think any of us is proposing to deploy a system that deliberately ignores 60 years of deep thought in security and cryptography. But I could be wrong :-) -- Marcus Leech Mail: Dept 1A12, M/S: 04352P16 Security Standards Advisor Phone: (ESN) 393-9145 +1 613 763 9145 Advanced Technology Research Nortel Networks mleech@nortel.com _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 17 14:16:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY6ci-0002Tr-E8; Tue, 17 May 2005 14:16:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY6cg-0002Tm-TO for isms@megatron.ietf.org; Tue, 17 May 2005 14:16:55 -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 OAA22868 for ; Tue, 17 May 2005 14:16:52 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY6tT-0006V7-5h for isms@ietf.org; Tue, 17 May 2005 14:34:16 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j4HIGX3x019692; Tue, 17 May 2005 11:16:34 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Tue, 17 May 2005 11:16:34 -0700 Message-ID: From: "McDonald, Ira" To: "'Wes Hardaker'" , Tom Petch Subject: RE: [Isms] TLS / SSH scalability concerns Date: Tue, 17 May 2005 11:16:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I agree with Wes and Marcus - Tom Petch's premise that it's okay to collect statistics in a non-secure manner is fatally flawed. There was lots of discussion some time back on this list around the idea that you shouldn't "waste" the overhead of security for SNMP Get requests/responses. This is just plain wrong, unless you don't care if your statistics (and their apparent sources) have been hacked. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On > Behalf Of Wes Hardaker > Sent: Tuesday, May 17, 2005 1:21 PM > To: Tom Petch > Cc: isms@ietf.org > Subject: Re: [Isms] TLS / SSH scalability concerns > > > >>>>> On Tue, 17 May 2005 11:40:06 +0200, "Tom Petch" > said: > > Tom> The SNMP manager polling the interface table on n,000 agents > Tom> every 30 second does not need and should not be using security. > > Err... Riiiigght. > > I'm glad those ever important SETs will be done securely at least. > Even though the decision about whether to send them might be based on > insecure data. > > -- > Wes Hardaker > Sparta, Inc. > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 17 14:28:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY6nS-0005mS-B3; Tue, 17 May 2005 14:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY6nQ-0005mN-OQ for isms@megatron.ietf.org; Tue, 17 May 2005 14:28:00 -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 OAA23791 for ; Tue, 17 May 2005 14:27:58 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY74D-0007BF-RY for isms@ietf.org; Tue, 17 May 2005 14:45:22 -0400 Received: from pc6 (1Cust96.tnt101.lnd4.gbr.da.uu.net [213.116.50.96]) by blaster.systems.pipex.net (Postfix) with SMTP id 09117E0000B2; Tue, 17 May 2005 19:27:44 +0100 (BST) Message-ID: <007701c55b05$28c217e0$0601a8c0@pc6> From: "Tom Petch" To: "McDonald, Ira" References: Subject: Re: [Isms] TLS / SSH scalability concerns Date: Tue, 17 May 2005 19:21:17 +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: d0bdc596f8dd1c226c458f0b4df27a88 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 Just to clarify, I did not have in mind the gathering of statistics. What I see SNMP managers do is poll at regular intervals - 30s is typical - in order to maintain a view of which agents are ok and which are not. Some poll using the system group, some use the interface table. So my reference is not to statistics but to the work of maintaining the display of suitably coloured icons on the monitor. As you gather, I do not see that as needing much security but am interested to hear different points of view. Tom Petch ----- Original Message ----- From: "McDonald, Ira" To: "'Wes Hardaker'" ; "Tom Petch" Cc: Sent: Tuesday, May 17, 2005 8:16 PM Subject: RE: [Isms] TLS / SSH scalability concerns > Hi, > > I agree with Wes and Marcus - Tom Petch's premise that it's okay > to collect statistics in a non-secure manner is fatally flawed. > > There was lots of discussion some time back on this list around > the idea that you shouldn't "waste" the overhead of security for > SNMP Get requests/responses. This is just plain wrong, unless > you don't care if your statistics (and their apparent sources) > have been hacked. > > Cheers, > - Ira > > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org]On > > Behalf Of Wes Hardaker > > Sent: Tuesday, May 17, 2005 1:21 PM > > To: Tom Petch > > Cc: isms@ietf.org > > Subject: Re: [Isms] TLS / SSH scalability concerns > > > > > > >>>>> On Tue, 17 May 2005 11:40:06 +0200, "Tom Petch" > > said: > > > > Tom> The SNMP manager polling the interface table on n,000 agents > > Tom> every 30 second does not need and should not be using security. > > > > Err... Riiiigght. > > > > I'm glad those ever important SETs will be done securely at least. > > Even though the decision about whether to send them might be based on > > insecure data. > > > > -- > > Wes Hardaker > > Sparta, Inc. > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 17 16:14:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY8Pg-00028u-96; Tue, 17 May 2005 16:11:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY8Pb-00026B-Ec for isms@megatron.ietf.org; Tue, 17 May 2005 16:11:33 -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 QAA10008 for ; Tue, 17 May 2005 16:11:28 -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 1DY8gO-0006PB-Ca for isms@ietf.org; Tue, 17 May 2005 16:28:53 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 1B99E11D731; Tue, 17 May 2005 13:11:26 -0700 (PDT) From: Wes Hardaker To: Tom Petch Subject: Re: [Isms] TLS / SSH scalability concerns Organization: Sparta References: <007701c55b05$28c217e0$0601a8c0@pc6> Date: Tue, 17 May 2005 13:11:25 -0700 In-Reply-To: <007701c55b05$28c217e0$0601a8c0@pc6> (Tom Petch's message of "Tue, 17 May 2005 19:21:17 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Tue, 17 May 2005 19:21:17 +0200, "Tom Petch" said: Tom> So my reference is not to statistics but to the work of Tom> maintaining the display of suitably coloured icons on the Tom> monitor. Tom> As you gather, I do not see that as needing much security but am Tom> interested to hear different points of view. If you don't care about the accuracy of those red and green lights, then I agree. I doesn't need to be secure. I, for one, would kind of like to know that a device is truly green when I'm looking for problems. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 18 21:58:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYaId-0004NZ-3f; Wed, 18 May 2005 21:58:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYaIb-0004NU-Rv for isms@megatron.ietf.org; Wed, 18 May 2005 21:58:09 -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 VAA16953 for ; Wed, 18 May 2005 21:58:07 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYaZe-00011Y-Tb for isms@ietf.org; Wed, 18 May 2005 22:15:48 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 18 May 2005 18:57:59 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j4J1vFrg010116 for ; Wed, 18 May 2005 18:57:57 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 18:57:55 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: Re: [Isms] Thoughts on Encapsulation Date: Wed, 18 May 2005 18:57:54 -0700 Message-ID: Thread-Topic: Re: [Isms] Thoughts on Encapsulation Thread-Index: AcVcFiwI/7PlTipsROmhK4h3jiGKNw== From: "Khanh Nguyen \(khanhvn\)" To: X-OriginalArrivalTime: 19 May 2005 01:57:55.0736 (UTC) FILETIME=[2C9BA180:01C55C16] 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 It has been a couple of weeks since we decided to use EK. What should we do next? Sam gave some thoughts about 3 choices of transport encapsulation: TLS, SSH, and DTLS, and our recent=20 discussions seem to indicate a consensus that we may need more than one (to support both TCP and UDP.) Assume that we pick TLS and DTLS (correct me if that's a wrong assumption:), then I guess the next step in terms of architectural decisions will be about authentication. There are a few options that have been raised: 1. Certificate (for server auth) + SASL (for client) 2. Mutual authentication using Kerberos 3. Mutual auth using PSK/LPSK (via SASL, TLS-SRP, SNMP PDU, etc.) ... So should we start to do some evaluation of these options to find what's most suitable for SNMP auth? We may end up selecting more than one method, e.g. one mandatory and a couple of optional ones...=20 Khanh =20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 19 03:32:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYfWH-0006aj-2a; Thu, 19 May 2005 03:32:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYfWF-0006Yk-BP for isms@megatron.ietf.org; Thu, 19 May 2005 03:32:35 -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 DAA29577 for ; Thu, 19 May 2005 03:32:33 -0400 (EDT) Received: from smtp-out.completel.net ([83.145.110.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYfnL-0008TQ-9n for isms@ietf.org; Thu, 19 May 2005 03:50:16 -0400 Received: from boskop.local (unknown [195.167.238.7]) by smtp-out.completel.net (Postfix) with ESMTP id 8AF3228002A for ; Thu, 19 May 2005 09:32:15 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 449312EFFC5; Thu, 19 May 2005 09:32:13 +0200 (CEST) Date: Thu, 19 May 2005 09:32:13 +0200 From: Juergen Schoenwaelder To: "Khanh Nguyen (khanhvn)" Subject: Re: [Isms] Thoughts on Encapsulation Message-ID: <20050519073213.GA10235@boskop.local> Mail-Followup-To: "Khanh Nguyen (khanhvn)" , isms@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Wed, May 18, 2005 at 06:57:54PM -0700, Khanh Nguyen (khanhvn) wrote: > It has been a couple of weeks since we decided to use EK. What should > we do next? Sam gave some thoughts about 3 choices of transport > encapsulation: TLS, SSH, and DTLS, and our recent > discussions seem to indicate a consensus that we may need more than one > (to support both TCP and UDP.) > > Assume that we pick TLS and DTLS (correct me if that's a wrong > assumption:) [...] I would not drop ssh. Besides insecure telnet, ssh is _the_ protocol to access CLIs and netconf also mandates the support of ssh. The other option of course would be to define a netconf extension that effectively tunnels SNMP like requests through netconf. So on the box, you would just process an SNMP like rpc by mapping it on the local SNMP instrumentation and on the manager side you might be be able to provide an API which is similar to your existing SNMP API and then at the end things run over netconf's transport (whatever you choose). Now such ideas are of course clearly out of the scope of the charter of this WG. ;-) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 19 04:16:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYgCq-0002Zf-SI; Thu, 19 May 2005 04:16:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYgCo-0002ZX-L6 for isms@megatron.ietf.org; Thu, 19 May 2005 04:16:34 -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 EAA04159 for ; Thu, 19 May 2005 04:16:32 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYgTu-0001L6-QM for isms@ietf.org; Thu, 19 May 2005 04:34:16 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 19 May 2005 01:16:24 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4J8GKPo013580; Thu, 19 May 2005 01:16:20 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp112.cisco.com [10.61.64.112]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4J85ZtC010073; Thu, 19 May 2005 01:05:36 -0700 Message-ID: <428C4B51.8050201@cisco.com> Date: Thu, 19 May 2005 10:16:17 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de Subject: Re: [Isms] Thoughts on Encapsulation [BEEP/NETCONF] References: <20050519073213.GA10235@boskop.local> In-Reply-To: <20050519073213.GA10235@boskop.local> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1116489937.705354"; x:"432200"; a:"rsa-sha1"; b:"nofws:2634"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"OEMfuWcES4jg1YRuGZKfjSAkFxz5DN+geoZv1FABSlyMDqkFora6GuiXi26TKplHbc/fKkp0" "cK7Q6rUnXrwRtdb3vuQ4+hTUUsCl6RlrQ8/XBJXdOVVHtpDjvlYJFslv79dFIC+806fLR80nKp8" "CXHxCO96w1i2kP8L0eu8GfKs="; c:"Date: Thu, 19 May 2005 10:16:17 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] Thoughts on Encapsulation [BEEP/NETCONF]" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: Andy Bierman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen, [just a terminology note- in this message SNMP means the content above L3 that would be tunneled, except where noted(*).] A few of us are currently thinking about a BEEP profile for SNMP. Our current thoughts are to continue to use binary format, however. This allows for additional code reuse and compact data structures. However, one could specify profiles for both ASN.1 and an XML schema. That having been said, I prefer a single approach to begin with to improve chances of interoperability. Whether this is tied to NETCONF or not is an interesting question. It would be REALLY nice for SNMP & NETCONF to share the same security context. Doing so means that one would need to adapt to the other as far as what the securityName is, for instance. As to whether to use the same port, my first consideration is whether a firewall administrator doing port blocking would want to block this form of SNMP(*) apart from NETCONF. I think the answer is no. However... My next consideration is whether it is reasonable to have SNMP depend on NETCONF. From a BEEP standpoint, if you're sharing the same TCP connection, either at the initial greeting, or the greeting after TLS is established, you must announce all allowed profiles. Once you're there you need to announce one or more SNMP profiles because BEEP doesn't allow for a repeat of the greeting. The only other option would be to incorporate this form of SNMP into NETCONF base protocol semantics, and quite frankly pragmatically I'm not a fan. It sounds like chances of getting both done reduce as a product of each other. There's a final consideration about how well the flow control in BEEP will be able to sustain / support both uses. Here I'm inclined to think that it's sufficient, but I'm not firmly convinced. Therefore I'd suggest that it should be possible to share a BEEP connection between NETCONF and SNMP but not required. In order for me to say this I have to believe that interoperability will not be impacted. I don't think it will be. Am I wrong? Thoughts? Eliot Juergen Schoenwaelder wrote: > On Wed, May 18, 2005 at 06:57:54PM -0700, Khanh Nguyen (khanhvn) wrote: > > >>It has been a couple of weeks since we decided to use EK. What should >>we do next? Sam gave some thoughts about 3 choices of transport >>encapsulation: TLS, SSH, and DTLS, and our recent >>discussions seem to indicate a consensus that we may need more than one >>(to support both TCP and UDP.) >> >>Assume that we pick TLS and DTLS (correct me if that's a wrong >>assumption:) [...] > > > I would not drop ssh. Besides insecure telnet, ssh is _the_ protocol to > access CLIs and netconf also mandates the support of ssh. > > The other option of course would be to define a netconf extension that > effectively tunnels SNMP like requests through netconf. So on the box, > you would just process an SNMP like rpc by mapping it on > the local SNMP instrumentation and on the manager side you might be > be able to provide an API which is similar to your existing SNMP API > and then at the end things run over netconf's transport (whatever > you choose). Now such ideas are of course clearly out of the scope > of the charter of this WG. ;-) > > /js > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 19 04:17:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYgDf-0002ia-5f; Thu, 19 May 2005 04:17:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYgDd-0002iU-O9 for isms@megatron.ietf.org; Thu, 19 May 2005 04:17:25 -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 EAA04416 for ; Thu, 19 May 2005 04:17:23 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYgUk-0001OA-9P for isms@ietf.org; Thu, 19 May 2005 04:35:07 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 19 May 2005 01:17:13 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4J8HAPo014033; Thu, 19 May 2005 01:17:10 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp112.cisco.com [10.61.64.112]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4J86PQ3010078; Thu, 19 May 2005 01:06:26 -0700 Message-ID: <428C4B84.10406@cisco.com> Date: Thu, 19 May 2005 10:17:08 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khanh Nguyen (khanhvn)" Subject: Re: [Isms] Thoughts on Encapsulation References: In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1116489987.269864"; x:"432200"; a:"rsa-sha1"; b:"nofws:336"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"M+POPZl9TulkbMFTRBrQqJWYXOi+rdH3/JbLy8YqJzk0Jjhfi6768akEJdrn+4rq65bXdUFC" "P7HXX/Yue4aSdc0l2IwZS22sSxltKQlCk0bQl7pU0SXW6J3B11ifrwy5O6kbUfa3szdgSaKr1xC" "+HuipNEPJjPNjddqCKifykYM="; c:"Date: Thu, 19 May 2005 10:17:08 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] Thoughts on Encapsulation" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 Khanh Nguyen (khanhvn) wrote: > It has been a couple of weeks since we decided to use EK. What should > we do next? Sam gave some thoughts about 3 choices of transport > encapsulation: TLS, SSH, and DTLS, and our recent > discussions seem to indicate a consensus that we may need more than one > (to support both TCP and UDP.) For interoperability's sake I strongly suggest that we add a single mechanism. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 19 04:35:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYgUm-0006wn-Sc; Thu, 19 May 2005 04:35:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYgUj-0006wH-PJ for isms@megatron.ietf.org; Thu, 19 May 2005 04:35:06 -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 EAA05403 for ; Thu, 19 May 2005 04:35:03 -0400 (EDT) Received: from smtp-out.completel.net ([83.145.110.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYglr-0001kN-9p for isms@ietf.org; Thu, 19 May 2005 04:52:47 -0400 Received: from boskop.local (unknown [195.167.238.7]) by smtp-out.completel.net (Postfix) with ESMTP id 6AB7B25C03C for ; Thu, 19 May 2005 10:34:56 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 8D0F62F00AD; Thu, 19 May 2005 10:34:54 +0200 (CEST) Date: Thu, 19 May 2005 10:34:54 +0200 From: Juergen Schoenwaelder To: Eliot Lear Subject: Re: [Isms] Thoughts on Encapsulation [BEEP/NETCONF] Message-ID: <20050519083454.GB10716@boskop.local> Mail-Followup-To: Eliot Lear , isms@ietf.org, Andy Bierman References: <20050519073213.GA10235@boskop.local> <428C4B51.8050201@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428C4B51.8050201@cisco.com> User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Andy Bierman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Thu, May 19, 2005 at 10:16:17AM +0200, Eliot Lear wrote: > A few of us are currently thinking about a BEEP profile for SNMP. Our > current thoughts are to continue to use binary format, however. This > allows for additional code reuse and compact data structures. However, > one could specify profiles for both ASN.1 and an XML schema. That > having been said, I prefer a single approach to begin with to improve > chances of interoperability. > > Whether this is tied to NETCONF or not is an interesting question. It > would be REALLY nice for SNMP & NETCONF to share the same security > context. Doing so means that one would need to adapt to the other as > far as what the securityName is, for instance. You can look at this in different ways. You can either have a netconf extension that basically allows you to access SNMP instrumentation using some new netconf primitives. You can strike for primitives that can map to typical SNMP APIs so you can port management apps by relinking them. Alternatively, you can provide new primitives (such as get-table) which can then be supported more efficiently but require new manager code to be used. A completely different approach is to just map the SNMP data models into NETCONF data models and simply use netconf primitives to access them. Again, requires new manager code. Another option would be to just harmonize the transports so that you can us the same security context between SNMP and NETCONF. All these approaches have pros and cons and I have no opinion yet what the right thing to do would be (also depends on how successful you expect NETCONF to be). Personally, I am not convinced by BEEP mappings. BEEP is a great piece of engineering work but it seems that outside some core BEEPers in the IETF nobody cares about it. This is quite different from ssh which is very widely deployed and used. [But this is just my personal opinion and there is probably little value in discussing opinions.] /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 Thu May 19 11:07:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYmcU-0002M1-6W; Thu, 19 May 2005 11:07:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYmcR-0002Lo-67 for isms@megatron.ietf.org; Thu, 19 May 2005 11:07:28 -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 LAA13990 for ; Thu, 19 May 2005 11:07:24 -0400 (EDT) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYmtb-0004Yk-2f for isms@ietf.org; Thu, 19 May 2005 11:25:12 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4JF6943000691; Thu, 19 May 2005 15:06:09 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j4JF69jw028915; Thu, 19 May 2005 15:06:09 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005051908060914745 ; Thu, 19 May 2005 08:06:09 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 08:06:08 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 08:06:08 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 11:06:06 -0400 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] Thoughts on Encapsulation Date: Thu, 19 May 2005 11:05:20 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929012AA41D@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Thoughts on Encapsulation Thread-Index: AcVcFiwI/7PlTipsROmhK4h3jiGKNwAbS0Dg From: "Blumenthal, Uri" To: "Khanh Nguyen \(khanhvn\)" , X-OriginalArrivalTime: 19 May 2005 15:06:06.0881 (UTC) FILETIME=[4853B110:01C55C84] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 > Assume that we pick TLS and DTLS (correct me if that's a wrong > assumption:), then I guess the next step in terms of architectural > decisions will be about authentication. There are a few options that > have been raised: >=20 > 1. Certificate (for server auth) + SASL (for client) And we'd need to assume that (a) PKI is deployed within the admin domain, and (b)SASL passwords (credentials) would be provisioned somehow. > 2. Mutual authentication using Kerberos And we'd need to assume that those who don't have Kerberos, will deploy it. > 3. Mutual auth using PSK/LPSK (via SASL, TLS-SRP, SNMP PDU, etc.) And again, the credentials would have to be provisioned somehow. ... > So should we start to do some evaluation of these options to find what's > most suitable for SNMP auth? We may end up selecting more than one > method, e.g. one mandatory and a couple of optional ones...=20 :-) Sweet time agreeing upon that. =20 _______________________________________________ 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 May 19 11:53:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYnKh-0008Vq-Dh; Thu, 19 May 2005 11:53:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYnKf-0008Vd-9V for isms@megatron.ietf.org; Thu, 19 May 2005 11:53:09 -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 LAA18416 for ; Thu, 19 May 2005 11:53:06 -0400 (EDT) Received: from moby.atcorp.com ([204.72.172.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYnbm-00060x-TF for isms@ietf.org; Thu, 19 May 2005 12:10:55 -0400 Received: from localhost ([127.0.0.1] helo=STRIPER ident=root) by moby.atcorp.com with asmtp (Exim 3.35 #1 (Debian)) id 1DYnKM-00035j-00; Thu, 19 May 2005 10:52:50 -0500 From: "Wayne Kading" To: "'Blumenthal, Uri'" , "'Khanh Nguyen \(khanhvn\)'" Subject: RE: [Isms] Thoughts on Encapsulation Date: Thu, 19 May 2005 10:52:48 -0500 Organization: ATC Message-ID: <000001c55c8a$cf1ffef0$84aca8c0@STRIPER> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <3DEC199BD7489643817ECA151F7C5929012AA41D@pysmsx401.amr.corp.intel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I would be interested to know whether the options below and the SSH option support the "one touch" approach discussed previously in this WG. Wayne -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Blumenthal, Uri Sent: Thursday, May 19, 2005 10:05 AM To: Khanh Nguyen (khanhvn); isms@ietf.org Subject: RE: [Isms] Thoughts on Encapsulation > Assume that we pick TLS and DTLS (correct me if that's a wrong > assumption:), then I guess the next step in terms of architectural > decisions will be about authentication. There are a few options that > have been raised: > > 1. Certificate (for server auth) + SASL (for client) And we'd need to assume that (a) PKI is deployed within the admin domain, and (b)SASL passwords (credentials) would be provisioned somehow. > 2. Mutual authentication using Kerberos And we'd need to assume that those who don't have Kerberos, will deploy it. > 3. Mutual auth using PSK/LPSK (via SASL, TLS-SRP, SNMP PDU, etc.) And again, the credentials would have to be provisioned somehow. ... _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 19 11:54:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYnLc-0000cl-5k; Thu, 19 May 2005 11:54:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYnLa-0000cW-Ak for isms@megatron.ietf.org; Thu, 19 May 2005 11:54:06 -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 LAA18584 for ; Thu, 19 May 2005 11:54:03 -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 1DYnci-00064R-Us for isms@ietf.org; Thu, 19 May 2005 12:11:52 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 5F16F11D739; Thu, 19 May 2005 08:53:57 -0700 (PDT) From: Wes Hardaker To: "Khanh Nguyen (khanhvn)" Subject: Re: [Isms] Thoughts on Encapsulation Organization: Sparta References: <20050519073213.GA10235@boskop.local> Date: Thu, 19 May 2005 08:53:56 -0700 In-Reply-To: <20050519073213.GA10235@boskop.local> (Juergen Schoenwaelder's message of "Thu, 19 May 2005 09:32:13 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Thu, 19 May 2005 09:32:13 +0200, Juergen Schoenwaelder said: Juergen> The other option of course would be to define a netconf Juergen> extension that effectively tunnels SNMP like requests through Juergen> netconf. I've argued for a long time that netconf needs to deal with management too because doing 2 protocols for management is insane. However, I'd be very strongly opposed to having SNMP messages require netconf to be sent under ISMS. You're suddenly requiring boxes to speak XML when they haven't necessarily ever before. That's an overhead that doesn't justify the benefits even remotely, IMHO. Assuming that netconf is going to take off is a very questionable assumption at this point (don't get me wrong, I hope it is used, but I'm not going to bet another protocol on the burdens that it imposes). [note: for those that say HTTP interfaces require XML support, they don't. They require code that can generate XML-like structures though not necessarily compliant (eg, bad-HTML). More importantly, however, Web servers on boxes don't have to *parse* XML which is where the impact is. Form data and the like is not sent in XML form.] -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 19 14:05:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpOp-00076A-DB; Thu, 19 May 2005 14:05:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpOn-00073C-2Q for isms@megatron.ietf.org; Thu, 19 May 2005 14:05:33 -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 OAA00866 for ; Thu, 19 May 2005 14:05:31 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYpfy-0001P3-Pj for isms@ietf.org; Thu, 19 May 2005 14:23:20 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 19 May 2005 11:05:21 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j4JI50nS000585; Thu, 19 May 2005 11:05:19 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 11:05:17 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] Thoughts on Encapsulation Date: Thu, 19 May 2005 11:05:16 -0700 Message-ID: Thread-Topic: [Isms] Thoughts on Encapsulation Thread-Index: AcVcFiwI/7PlTipsROmhK4h3jiGKNwAbS0DgAAXujVA= From: "Khanh Nguyen \(khanhvn\)" To: "Blumenthal, Uri" , X-OriginalArrivalTime: 19 May 2005 18:05:17.0716 (UTC) FILETIME=[5052ED40:01C55C9D] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 > -----Original Message----- > From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 >=20 > > Assume that we pick TLS and DTLS (correct me if that's a wrong=20 > > assumption:), then I guess the next step in terms of architectural=20 > > decisions will be about authentication. There are a few=20 > > options that have been raised: > >=20 > > 1. Certificate (for server auth) + SASL (for client) >=20 > And we'd need to assume that (a) PKI is deployed within the=20 > admin domain, and (b)SASL passwords (credentials) would be=20 > provisioned somehow. >=20 > > 2. Mutual authentication using Kerberos >=20 > And we'd need to assume that those who don't have Kerberos,=20 > will deploy it. >=20 > > 3. Mutual auth using PSK/LPSK (via SASL, TLS-SRP, SNMP PDU, etc.) >=20 > And again, the credentials would have to be provisioned somehow. >=20 > ... I guess whatever method we use, we'll need some credential=20 provisioning (even w/ Kerberos you still need credentials=20 to establish trust b/w each device and Kerberos server). =20 So I think the criteria will be which option requires the=20 minimal amount of provisioning & maintenance efforts. >=20 > > So should we start to do some evaluation of these options to find > what's > > most suitable for SNMP auth? We may end up selecting more than one=20 > > method, e.g. one mandatory and a couple of optional ones... >=20 > :-) Sweet time agreeing upon that. True, unfortunately. Khanh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 19 14:19:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpcS-0002hJ-43; Thu, 19 May 2005 14:19:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpcQ-0002gB-Hf for isms@megatron.ietf.org; Thu, 19 May 2005 14:19: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 OAA02433 for ; Thu, 19 May 2005 14:19:36 -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 1DYptb-0001ns-VO for isms@ietf.org; Thu, 19 May 2005 14:37:25 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 19 May 2005 11:19:23 -0700 X-IronPort-AV: i="3.93,121,1115017200"; d="scan'208"; a="267324546:sNHT6971690230" 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 j4JIJDO3021327; Thu, 19 May 2005 11:19:14 -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); Thu, 19 May 2005 11:19:19 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] Thoughts on Encapsulation Date: Thu, 19 May 2005 11:19:17 -0700 Message-ID: Thread-Topic: [Isms] Thoughts on Encapsulation Thread-Index: AcVcRPZsqsyOkWP/T7OAPQksnBrg1AAU/xeQ From: "Khanh Nguyen \(khanhvn\)" To: X-OriginalArrivalTime: 19 May 2005 18:19:19.0268 (UTC) FILETIME=[45ED9240:01C55C9F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 > >=20 > > Assume that we pick TLS and DTLS (correct me if that's a wrong > > assumption:) [...] >=20 > I would not drop ssh. Besides insecure telnet, ssh is _the_=20 > protocol to access CLIs and netconf also mandates the support of ssh. That's a good point, although SSH+DTLS doesn't sound like a=20 matching pair (unless we just drop DTLS). =20 Khanh >=20 > The other option of course would be to define a netconf=20 > extension that effectively tunnels SNMP like requests through=20 > netconf. So on the box, you would just process an SNMP like=20 > rpc by mapping it on the local SNMP=20 > instrumentation and on the manager side you might be be able=20 > to provide an API which is similar to your existing SNMP API=20 > and then at the end things run over netconf's transport=20 > (whatever you choose). Now such ideas are of course clearly=20 > out of the scope of the charter of this WG. ;-) >=20 > /js >=20 > --=20 > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 19 14:22:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpff-0003UH-1R; Thu, 19 May 2005 14:22:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpfd-0003U1-UW for isms@megatron.ietf.org; Thu, 19 May 2005 14:22:58 -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 OAA02640 for ; Thu, 19 May 2005 14:22:56 -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 1DYpwp-0001tM-Qv for isms@ietf.org; Thu, 19 May 2005 14:40:45 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 19 May 2005 11:22:47 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4JIMIOJ023488; Thu, 19 May 2005 11:22:39 -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); Thu, 19 May 2005 11:22:44 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] Thoughts on Encapsulation Date: Thu, 19 May 2005 11:22:43 -0700 Message-ID: Thread-Topic: [Isms] Thoughts on Encapsulation Thread-Index: AcVciwnnlYEr9XlqQ365EHFj0OJIuAAFFFbA From: "Khanh Nguyen \(khanhvn\)" To: "Wayne Kading" , "Blumenthal, Uri" X-OriginalArrivalTime: 19 May 2005 18:22:44.0672 (UTC) FILETIME=[C05BBC00:01C55C9F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 > -----Original Message----- > From: Wayne Kading [mailto:wkading@atcorp.com]=20 >=20 > I would be interested to know whether the options below and=20 > the SSH option support the "one touch" approach discussed=20 > previously in this WG. Sorry that I missed it... what's the "one touch" approach? Khanh =20 >=20 > Wayne >=20 > -----Original Message----- > From: isms-bounces@lists.ietf.org=20 > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Blumenthal, Uri > Sent: Thursday, May 19, 2005 10:05 AM > To: Khanh Nguyen (khanhvn); isms@ietf.org > Subject: RE: [Isms] Thoughts on Encapsulation >=20 > > Assume that we pick TLS and DTLS (correct me if that's a wrong=20 > > assumption:), then I guess the next step in terms of architectural=20 > > decisions will be about authentication. There are a few=20 > options that=20 > > have been raised: > >=20 > > 1. Certificate (for server auth) + SASL (for client) >=20 > And we'd need to assume that (a) PKI is deployed within the=20 > admin domain, and (b)SASL passwords (credentials) would be=20 > provisioned somehow. >=20 > > 2. Mutual authentication using Kerberos >=20 > And we'd need to assume that those who don't have Kerberos,=20 > will deploy it. >=20 > > 3. Mutual auth using PSK/LPSK (via SASL, TLS-SRP, SNMP PDU, etc.) >=20 > And again, the credentials would have to be provisioned somehow. >=20 > ... >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 19 14: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 1DYpqt-0007H1-Ds; Thu, 19 May 2005 14: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 1DYpqt-0007Gw-4Y for isms@megatron.ietf.org; Thu, 19 May 2005 14:34:35 -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 OAA03905 for ; Thu, 19 May 2005 14:34:33 -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 1DYq85-0002Cv-5M for isms@ietf.org; Thu, 19 May 2005 14:52:22 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 19 May 2005 11:34:25 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4JIYJPq005374; Thu, 19 May 2005 11:34:22 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 11:34:19 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] Thoughts on Encapsulation Date: Thu, 19 May 2005 11:34:17 -0700 Message-ID: Thread-Topic: [Isms] Thoughts on Encapsulation Thread-Index: AcVcSykGReNLeqZ7TWiQHFkAcQC+qgAVgL9A From: "Khanh Nguyen \(khanhvn\)" To: "Eliot Lear" X-OriginalArrivalTime: 19 May 2005 18:34:19.0600 (UTC) FILETIME=[5E915500:01C55CA1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com]=20 >=20 > Khanh Nguyen (khanhvn) wrote: > > It has been a couple of weeks since we decided to use EK. =20 > What should=20 > > we do next? Sam gave some thoughts about 3 choices of transport > > encapsulation: TLS, SSH, and DTLS, and our recent=20 > discussions seem to=20 > > indicate a consensus that we may need more than one (to=20 > support both=20 > > TCP and UDP.) >=20 > For interoperability's sake I strongly suggest that we add a=20 > single mechanism. I agree, but sometime we need some tradeoff b/w interoperability and flexibility. Khanh >=20 > Eliot >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 19 15:06:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYqLk-00078b-Nl; Thu, 19 May 2005 15:06:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYqLj-00078W-TP for isms@megatron.ietf.org; Thu, 19 May 2005 15:06:27 -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 PAA08406 for ; Thu, 19 May 2005 15:06:25 -0400 (EDT) Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYqcu-0003M2-L2 for isms@ietf.org; Thu, 19 May 2005 15:24:15 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4JJ6597013800; Thu, 19 May 2005 19:06:10 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j4JJ59rR029443; Thu, 19 May 2005 19:05:39 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005051912053412331 ; Thu, 19 May 2005 12:05:34 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 12:05:34 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 12:05:34 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 15:05:32 -0400 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] Thoughts on Encapsulation Date: Thu, 19 May 2005 15:04:47 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929012AA684@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Thoughts on Encapsulation Thread-Index: AcVcSykGReNLeqZ7TWiQHFkAcQC+qgAVgL9AAAD+rFA= From: "Blumenthal, Uri" To: "Khanh Nguyen \(khanhvn\)" , "Eliot Lear" X-OriginalArrivalTime: 19 May 2005 19:05:32.0964 (UTC) FILETIME=[BB2DFE40:01C55CA5] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >> > It has been a couple of weeks since we decided to use EK. =20 >> > What should we do next? Sam gave some thoughts about 3 choices >> > of transport encapsulation: TLS, SSH, and DTLS, and our recent=20 >> > discussions seem to indicate a consensus that we may need more >> > than one (to support both TCP and UDP.) >>=20 >> For interoperability's sake I strongly suggest that we add a=20 >> single mechanism. > >I agree, but sometime we need some tradeoff b/w interoperability and >flexibility. Since (according to Wes's survey) the user population is split about evenly between RADIUS, Kerberos, PKI and SSH - which single mandatory mechanism is going to make at least 51% of the users happy? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 19 15:12:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYqRm-0001pB-B7; Thu, 19 May 2005 15:12:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYqRk-0001p6-NF for isms@megatron.ietf.org; Thu, 19 May 2005 15:12:40 -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 PAA09305 for ; Thu, 19 May 2005 15:12:38 -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 1DYqiw-0003ZW-Vc for isms@ietf.org; Thu, 19 May 2005 15:30:28 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 1159811D8A5; Thu, 19 May 2005 12:12:31 -0700 (PDT) From: Wes Hardaker To: "Khanh Nguyen (khanhvn)" Subject: Re: [Isms] Thoughts on Encapsulation Organization: Sparta References: Date: Thu, 19 May 2005 12:12:30 -0700 In-Reply-To: (Khanh Nguyen's message of "Thu, 19 May 2005 11:05:16 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Thu, 19 May 2005 11:05:16 -0700, "Khanh Nguyen (khanhvn)" said: Khanh> I guess whatever method we use, we'll need some credential Khanh> provisioning (even w/ Kerberos you still need credentials Khanh> to establish trust b/w each device and Kerberos server). Khanh> So I think the criteria will be which option requires the Khanh> minimal amount of provisioning & maintenance efforts. The right way to think about it, IMHO, is being able to use whatever the operators already have in place. That was the whole point of the WG. IE, if they have something in place we can directly leverage then the incremental cost is 0 event though there probably was a cost to what they were using. Security will always require some aspect of bootstrapping, regardless of whether that is public or symmetric key distribution. What we don't want to do is make people do more than what they've already done. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 19 15:31:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYqjV-0002f0-Oh; Thu, 19 May 2005 15:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYqjU-0002ev-0l for isms@megatron.ietf.org; Thu, 19 May 2005 15:31:00 -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 PAA13138 for ; Thu, 19 May 2005 15:30:58 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYr0g-0004lb-HK for isms@ietf.org; Thu, 19 May 2005 15:48:47 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 19 May 2005 12:30:50 -0700 X-IronPort-AV: i="3.93,121,1115017200"; d="scan'208"; a="637431309:sNHT27960516" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4JJUQOD010751; Thu, 19 May 2005 12:30:39 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 12:30:46 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] Thoughts on Encapsulation Date: Thu, 19 May 2005 12:30:44 -0700 Message-ID: Thread-Topic: [Isms] Thoughts on Encapsulation Thread-Index: AcVcSykGReNLeqZ7TWiQHFkAcQC+qgAVgL9AAAD+rFAAAPPywA== From: "Khanh Nguyen \(khanhvn\)" To: "Blumenthal, Uri" X-OriginalArrivalTime: 19 May 2005 19:30:46.0118 (UTC) FILETIME=[4116F860:01C55CA9] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 > -----Original Message----- > From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 > Sent: Thursday, May 19, 2005 12:05 PM > To: Khanh Nguyen (khanhvn); Eliot Lear > Cc: isms@ietf.org > Subject: RE: [Isms] Thoughts on Encapsulation >=20 > >> > It has been a couple of weeks since we decided to use EK. =20 > >> > What should we do next? Sam gave some thoughts about 3=20 > choices of=20 > >> > transport encapsulation: TLS, SSH, and DTLS, and our recent=20 > >> > discussions seem to indicate a consensus that we may=20 > need more than=20 > >> > one (to support both TCP and UDP.) > >>=20 > >> For interoperability's sake I strongly suggest that we add=20 > a single=20 > >> mechanism. > > > >I agree, but sometime we need some tradeoff b/w interoperability and=20 > >flexibility. >=20 > Since (according to Wes's survey) the user population is=20 > split about evenly between RADIUS, Kerberos, PKI and SSH -=20 > which single mandatory mechanism is going to make at least=20 > 51% of the users happy? >=20 66% local accounts=20 Khanh :) _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 19 15:34:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYqme-000357-BV; Thu, 19 May 2005 15:34:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYqmc-00034g-P8 for isms@megatron.ietf.org; Thu, 19 May 2005 15:34:14 -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 PAA13468 for ; Thu, 19 May 2005 15:34:12 -0400 (EDT) Received: from moby.atcorp.com ([204.72.172.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYr3p-0004qQ-72 for isms@ietf.org; Thu, 19 May 2005 15:52:02 -0400 Received: from localhost ([127.0.0.1] helo=STRIPER ident=root) by moby.atcorp.com with asmtp (Exim 3.35 #1 (Debian)) id 1DYqmS-0003NK-00; Thu, 19 May 2005 14:34:04 -0500 From: "Wayne Kading" To: "'Khanh Nguyen \(khanhvn\)'" , "'Blumenthal, Uri'" Subject: RE: [Isms] Thoughts on Encapsulation Date: Thu, 19 May 2005 14:34:02 -0500 Organization: ATC Message-ID: <001501c55ca9$b6ffc110$84aca8c0@STRIPER> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I have added the string of previous "one touch" messages after my message below. Wayne -----Original Message----- From: Khanh Nguyen (khanhvn) [mailto:khanhvn@cisco.com] Sent: Thursday, May 19, 2005 1:23 PM To: Wayne Kading; Blumenthal, Uri Cc: isms@ietf.org Subject: RE: [Isms] Thoughts on Encapsulation > -----Original Message----- > From: Wayne Kading [mailto:wkading@atcorp.com] > > I would be interested to know whether the options below and > the SSH option support the "one touch" approach discussed > previously in this WG. Sorry that I missed it... what's the "one touch" approach? Khanh > > Wayne > > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Blumenthal, Uri > Sent: Thursday, May 19, 2005 10:05 AM > To: Khanh Nguyen (khanhvn); isms@ietf.org > Subject: RE: [Isms] Thoughts on Encapsulation > > > Assume that we pick TLS and DTLS (correct me if that's a wrong > > assumption:), then I guess the next step in terms of architectural > > decisions will be about authentication. There are a few > options that > > have been raised: > > > > 1. Certificate (for server auth) + SASL (for client) > > And we'd need to assume that (a) PKI is deployed within the > admin domain, and (b)SASL passwords (credentials) would be > provisioned somehow. > > > 2. Mutual authentication using Kerberos > > And we'd need to assume that those who don't have Kerberos, > will deploy it. > > > 3. Mutual auth using PSK/LPSK (via SASL, TLS-SRP, SNMP PDU, etc.) > > And again, the credentials would have to be provisioned somehow. > > ... > -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David T. Perkins Sent: Wednesday, May 04, 2005 1:41 PM To: Tom Petch Cc: isms@ietf.org Subject: Re: [Isms] One touch; was CALL FOR CONSENSUS: ISMS Architecture HI, Tom - the goal is not "zero touch for the box", but "zero touch" to add support for SNMP. The ideal is that a box is configured for management without support for SNMP. Then when it is decided to support SNMP, the only thing that is done is to turn on SNMP support for the box. Ideally, if syslog targets have already been set up, then SNMP can use them for notification targets. Ideally, the identities that have been set up for OTHER management activities can be used for SNMP request operations on the box. On Wed, 4 May 2005, Tom Petch wrote: > Wes > > What is acceptable? Ken said he could not imagine a zero touch secure system > and nor can I. So at the very least, I have to put in a secret of some shape or > form when I instal the box, along with IPv4 address, default gateway, sysName, > sysContact etc. > > Whether that happens to be the key for a preinstalled USM user, a secret used > for OOBK, the password of root/superuser, it makes no difference, I believe it > still has > to be done. > > Of course you also have to prevent its re-entry except under controlled > circumstances but that is what we have today (in non-SNMP environments). And > with SNMPv3, it could be tied into the input of engine id, so both go in > together or not at all. > > Tom Petch > > ----- Original Message ----- > From: "Wes Hardaker" > To: "Randy Presuhn" > Cc: > Sent: Tuesday, May 03, 2005 10:35 PM > Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture > > > > >>>>> On Tue, 3 May 2005 12:05:22 -0700, "Randy Presuhn" > said: > > > > Randy> However, any SNMP stack out there that supports USM should > > Randy> provide the ability to use SNMPv3 to set the keys. Rather than > > Randy> modifying the SNMP stack, or modifying the existing "OOB > > Randy> service", one could use an application acting on behalf of the > > Randy> security administrator to talk to the OOB service, and use > > Randy> SNMPv3 to set the USM keys. > > > > The thought had crossed my mind as well, but that still requires > > either provisioning of the SNMPv3 service with an initial USM user > > (bad IMHO) or requires the service to be run on the same host and a > > noAuthNoPriv user with access privileges tied to the loopback address > > (or any other form of an internal-to-the-box-trusted-network) which > > probably doesn't exist in most implementations today. > > > > Requiring the setup of just one USM user instead of X is still bad, > > IMHO, because operators don't want to do this today either. > > > > -- > > Wes Hardaker > > Sparta, Inc. 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 May 19 21:46:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYway-0007kq-VZ; Thu, 19 May 2005 21:46:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYway-0007kl-9v for isms@megatron.ietf.org; Thu, 19 May 2005 21:46:36 -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 VAA28308 for ; Thu, 19 May 2005 21:46:34 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYwsE-0001Vs-58 for isms@ietf.org; Thu, 19 May 2005 22:04:27 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 19 May 2005 18:46:25 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j4K1jZrm022470; Thu, 19 May 2005 18:46:22 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 18:46:19 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: Leverage existing infrastructure (was RE: [Isms] Thoughts on Encapsulation) Date: Thu, 19 May 2005 18:46:18 -0700 Message-ID: Thread-Topic: Leverage existing infrastructure (was RE: [Isms] Thoughts on Encapsulation) Thread-Index: AcVcpxDsFEQDgnPZTF2/+rbEgl8W4AAAFdZg From: "Khanh Nguyen \(khanhvn\)" To: "Wes Hardaker" X-OriginalArrivalTime: 20 May 2005 01:46:19.0312 (UTC) FILETIME=[B7EB8300:01C55CDD] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 > From: Wes Hardaker > The right way to think about it, IMHO, is being able to use=20 > whatever the operators already have in place. That was the=20 > whole point of the WG. IE, if they have something in place=20 > we can directly leverage then the incremental cost is 0=20 I do agree that leverage existing infrastructure is important. The "minimal deployment efforts" criteria should take into=20 account what operators already deployed. =20 The problem is that different operators deploys different things. Your survey indicates that local accounts is the only auth method that a majority of operators use. All other methods are < 50%. So I think leveraging local accounts should be #1 priority. In addition, I believe we should not focus only on leveraging *other* management interface (e.g. CLI) while ignore leveraging existing SNMP deployment itself (e.g. SNMPv1/v2). I think=20 SNMPv1/v2 installed base out there is huge, and that should be the primary target of our new security model. Imagine that you can convert the whole SNMPv1/v2 infrastructure of a company overnight to highly-secure SNMPv3 with "zero touch"=20 (except some automated software upgrade) and "zero dependence" on other external infrastructure (PKI, kerberos, radius, CLI...) Is that appealing? I don't want to do self-promoting, but the=20 LPSK proposal can do just that. =20 Regards. Khanh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 20 02:42:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ1Dj-0002eR-63; Fri, 20 May 2005 02:42:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ1Dh-0002eM-5P for isms@megatron.ietf.org; Fri, 20 May 2005 02:42:53 -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 CAA12010 for ; Fri, 20 May 2005 02:42:51 -0400 (EDT) Received: from ibbce.i.pppool.de ([85.73.187.206] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ1Uz-00005k-Ge for isms@ietf.org; Fri, 20 May 2005 03:00:46 -0400 Received: by boskop.local (Postfix, from userid 501) id 51C8D2F0753; Fri, 20 May 2005 08:42:42 +0200 (CEST) Date: Fri, 20 May 2005 08:42:42 +0200 From: Juergen Schoenwaelder To: "Khanh Nguyen (khanhvn)" Subject: Re: [Isms] Thoughts on Encapsulation Message-ID: <20050520064242.GE12241@boskop.local> Mail-Followup-To: "Khanh Nguyen (khanhvn)" , isms@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Thu, May 19, 2005 at 11:19:17AM -0700, Khanh Nguyen (khanhvn) wrote: > That's a good point, although SSH+DTLS doesn't sound like a > matching pair (unless we just drop DTLS). And I did not say SSH-DTLS. I said SSH. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 20 08:59:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ76A-0003uq-GB; Fri, 20 May 2005 08:59:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ765-0003uX-Av for isms@megatron.ietf.org; Fri, 20 May 2005 08:59:28 -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 IAA10546 for ; Fri, 20 May 2005 08:59:23 -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 1DZ7NR-0000tE-1M for isms@ietf.org; Fri, 20 May 2005 09:17:22 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 20 May 2005 05:59:15 -0700 X-IronPort-AV: i="3.93,123,1115017200"; d="scan'208"; a="267632970:sNHT31042124" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4KCx8O3022692; Fri, 20 May 2005 05:59:08 -0700 (PDT) Received: from [144.254.23.90] (dhcp-data-vlan10-23-90.cisco.com [144.254.23.90]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4KCmMU8020389; Fri, 20 May 2005 05:48:23 -0700 Message-ID: <428DDF1D.4010307@cisco.com> Date: Fri, 20 May 2005 14:59:09 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de Subject: Re: [Isms] Thoughts on Encapsulation References: <20050520064242.GE12241@boskop.local> In-Reply-To: <20050520064242.GE12241@boskop.local> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1116593304.320824"; x:"432200"; a:"rsa-sha1"; b:"nofws:645"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"GdAj1WVX8cjgtTh7ZY2TTNox70OAHpftnHfV+3gO1RhYRBOFsraiNmGORL7vtE80alf8d7wu" "oQXoO3/Swd3KVpak0wvIq+J5t3y8SzU0r+V3whQEnebiV9LA96MqB1Nbv5fUH6CrDCFJOESR7HE" "9+zPQdp4KoCtTVkolT6S0hr4="; c:"Date: Fri, 20 May 2005 14:59:09 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] Thoughts on Encapsulation" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I think there is this notion that SSH is some magic thing that all service providers implement and therefore want everything they do to pass over it. I'd be happy living with this except it really doesn't work in a managed services environment and people are ignoring that. This is a major reason why BEEP is appealing (that plus framing and windowing). We need a sufficiently general solution. BTW, PSKs have their own sets of problems, like preprovisioning of keys, again in a managed service environment. Eliot Juergen Schoenwaelder wrote: > On Thu, May 19, 2005 at 11:19:17AM -0700, Khanh Nguyen (khanhvn) wrote: > > >>That's a good point, although SSH+DTLS doesn't sound like a >>matching pair (unless we just drop DTLS). > > > And I did not say SSH-DTLS. I said SSH. > > /js > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 20 11: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 1DZ8zd-0006O6-R0; Fri, 20 May 2005 11: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 1DZ8zc-0006Nr-AS for isms@megatron.ietf.org; Fri, 20 May 2005 11:00: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 LAA25751 for ; Fri, 20 May 2005 11:00:50 -0400 (EDT) Received: from moby.atcorp.com ([204.72.172.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ9Gz-0004LM-6R for isms@ietf.org; Fri, 20 May 2005 11:18:50 -0400 Received: from localhost ([127.0.0.1] helo=STRIPER ident=root) by moby.atcorp.com with asmtp (Exim 3.35 #1 (Debian)) id 1DZ8zO-0007ME-00; Fri, 20 May 2005 10:00:38 -0500 From: "Wayne Kading" To: "'Khanh Nguyen \(khanhvn\)'" Subject: RE: Leverage existing infrastructure (was RE: [Isms] Thoughts onEncapsulation) Date: Fri, 20 May 2005 10:00:37 -0500 Organization: ATC Message-ID: <001801c55d4c$aee10f90$84aca8c0@STRIPER> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Khanh, Your reasoning below is one of the major reasons I preferred the EK architecture. I would like to know whether the WG would consider the LPSK proposal as a mandatory option for ISMS authentication. Also, what is involved with your reference to "some automated software upgrade?" Wayne -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Khanh Nguyen (khanhvn) Sent: Thursday, May 19, 2005 8:46 PM To: Wes Hardaker Cc: isms@ietf.org Subject: Leverage existing infrastructure (was RE: [Isms] Thoughts onEncapsulation) > From: Wes Hardaker > The right way to think about it, IMHO, is being able to use > whatever the operators already have in place. That was the > whole point of the WG. IE, if they have something in place > we can directly leverage then the incremental cost is 0 I do agree that leverage existing infrastructure is important. The "minimal deployment efforts" criteria should take into account what operators already deployed. The problem is that different operators deploys different things. Your survey indicates that local accounts is the only auth method that a majority of operators use. All other methods are < 50%. So I think leveraging local accounts should be #1 priority. In addition, I believe we should not focus only on leveraging *other* management interface (e.g. CLI) while ignore leveraging existing SNMP deployment itself (e.g. SNMPv1/v2). I think SNMPv1/v2 installed base out there is huge, and that should be the primary target of our new security model. Imagine that you can convert the whole SNMPv1/v2 infrastructure of a company overnight to highly-secure SNMPv3 with "zero touch" (except some automated software upgrade) and "zero dependence" on other external infrastructure (PKI, kerberos, radius, CLI...) Is that appealing? I don't want to do self-promoting, but the LPSK proposal can do just that. Regards. Khanh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 20 11:01:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ90d-0006X7-Ow; Fri, 20 May 2005 11:01:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ90c-0006X2-Lu for isms@megatron.ietf.org; Fri, 20 May 2005 11:01:54 -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 LAA25831 for ; Fri, 20 May 2005 11:01:52 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ9Hy-0004Ml-2T for isms@ietf.org; Fri, 20 May 2005 11:19:52 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2C371E0063; Fri, 20 May 2005 11:01:33 -0400 (EDT) To: "Khanh Nguyen (khanhvn)" Subject: Re: [Isms] Thoughts on Encapsulation References: From: Sam Hartman Date: Fri, 20 May 2005 11:01:33 -0400 In-Reply-To: (Khanh Nguyen's message of "Wed, 18 May 2005 18:57:54 -0700") 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: 9182cfff02fae4f1b6e9349e01d62f32 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 >>>>> "Khanh" == Khanh Nguyen (khanhvn) writes: Khanh> It has been a couple of weeks since we decided to use EK. Khanh> What should we do next? Sam gave some thoughts about 3 Khanh> choices of transport encapsulation: TLS, SSH, and DTLS, and Khanh> our recent discussions seem to indicate a consensus that we Khanh> may need more than one (to support both TCP and UDP.) Khanh> Assume that we pick TLS and DTLS (correct me if that's a Khanh> wrong assumption:), then I guess the next step in terms of Khanh> architectural decisions will be about authentication. Khanh> There are a few options that have been raised: Khanh> 1. Certificate (for server auth) + SASL (for client) That's certainly not what I said. I said certificate+SASL. Certs are normally used for servers; SASL for clients. However you should support all the combinations if you go this route. Khanh> Khanh> 2. Mutual authentication using Kerberos You should not directly use Kerberos unless you explain why SASL and SSH fail to meet your needs. Both of these approaches get you reasonable Kerberos support. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 20 11:03:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ92E-0006rd-RZ; Fri, 20 May 2005 11:03:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ92D-0006pn-Cf for isms@megatron.ietf.org; Fri, 20 May 2005 11:03:33 -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 LAA25904 for ; Fri, 20 May 2005 11:03:31 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ9Jb-0004Om-DK for isms@ietf.org; Fri, 20 May 2005 11:21:31 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 95F60E0063; Fri, 20 May 2005 11:03:16 -0400 (EDT) To: Eliot Lear Subject: Re: [Isms] Thoughts on Encapsulation References: <20050520064242.GE12241@boskop.local> <428DDF1D.4010307@cisco.com> From: Sam Hartman Date: Fri, 20 May 2005 11:03:16 -0400 In-Reply-To: <428DDF1D.4010307@cisco.com> (Eliot Lear's message of "Fri, 20 May 2005 14:59:09 +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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Eliot" == Eliot Lear writes: Eliot> I think there is this notion that SSH is some magic thing Eliot> that all service providers implement and therefore want Eliot> everything they do to pass over it. I'd be happy living Eliot> with this except it really doesn't work in a managed Eliot> services environment and people are ignoring that. This is Eliot> a major reason why BEEP is appealing (that plus framing and Eliot> windowing). We need a sufficiently general solution. In what way does ssh not work in a managed services environment? Please start by explaining what you mean by managed services environment; I'm quite unfamiliar with the space you are thinking of. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 20 12:00:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ9va-0003Dy-TC; Fri, 20 May 2005 12:00:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ9va-0003Dt-3A for isms@megatron.ietf.org; Fri, 20 May 2005 12:00: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 MAA01283 for ; Fri, 20 May 2005 12:00:43 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZACx-0005rn-B2 for isms@ietf.org; Fri, 20 May 2005 12:18:44 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 20 May 2005 09:00:36 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j4KG0VnC004341; Fri, 20 May 2005 09:00:31 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp4110.cisco.com [10.61.80.13]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4KFnfN4022034; Fri, 20 May 2005 08:49:42 -0700 Message-ID: <428E099D.6050208@cisco.com> Date: Fri, 20 May 2005 18:00:29 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman Subject: Re: [Isms] Thoughts on Encapsulation References: <20050520064242.GE12241@boskop.local> <428DDF1D.4010307@cisco.com> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1116604183.692827"; x:"432200"; a:"rsa-sha1"; b:"nofws:188"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"WLaHIwvNtotfRlabjZX3LgKEncWJsa5kBEpnDomCWI2Ids5sft55xn5V1M0SUfFqEo+VZEGg" "4BxgJ22PLo+Oog1qhy5HqIeGeK4ssoDu5ddeqGiIYow4ATiuAyBsc8eQFDpvwotz923UWUnjSEG" "zjzJmSEsQj1OgC11f38tYUVs="; c:"Date: Fri, 20 May 2005 18:00:29 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: [Isms] Thoughts on Encapsulation" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I'm specifically referring to call-home support where you want the managed entity to contact the manager. You *could* make this work for SSH. I think the protocol supports it. But nobody's done it (nor seems to want to). Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 20 12:19:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZADV-0007Of-20; Fri, 20 May 2005 12:19:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZADT-0007Oa-Vl for isms@megatron.ietf.org; Fri, 20 May 2005 12:19:16 -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 MAA02992 for ; Fri, 20 May 2005 12:19:13 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZAUp-0006Ou-M8 for isms@ietf.org; Fri, 20 May 2005 12:37:14 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 9971AE0063; Fri, 20 May 2005 12:18:52 -0400 (EDT) To: Eliot Lear Subject: Re: [Isms] Thoughts on Encapsulation References: <20050520064242.GE12241@boskop.local> <428DDF1D.4010307@cisco.com> <428E099D.6050208@cisco.com> From: Sam Hartman Date: Fri, 20 May 2005 12:18:52 -0400 In-Reply-To: <428E099D.6050208@cisco.com> (Eliot Lear's message of "Fri, 20 May 2005 18:00:29 +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: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Eliot" == Eliot Lear writes: Eliot> I'm specifically referring to call-home support where you Eliot> want the managed entity to contact the manager. You Eliot> *could* make this work for SSH. I think the protocol Eliot> supports it. But nobody's done it (nor seems to want to). OK, so an extension of the notify problem? I have seen people configure ssh to do this, but yes, it was a bit tricky. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 20 12:48:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAfW-000892-E7; Fri, 20 May 2005 12:48:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAfU-00088L-AI for isms@megatron.ietf.org; Fri, 20 May 2005 12:48:12 -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 MAA05783 for ; Fri, 20 May 2005 12:48:08 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZAwr-0007H2-Ji for isms@ietf.org; Fri, 20 May 2005 13:06:10 -0400 Received: from h-68-166-188-60.snvacaid.dynamic.covad.net ([68.166.188.60] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DZAfQ-0006gC-00 for isms@ietf.org; Fri, 20 May 2005 09:48:08 -0700 Message-ID: <004a01c55d5c$11e93e00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050520064242.GE12241@boskop.local> <428DDF1D.4010307@cisco.com> <428E099D.6050208@cisco.com> Subject: Re: [Isms] Thoughts on Encapsulation Date: Fri, 20 May 2005 09:50:46 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Sam Hartman" > To: "Eliot Lear" > Cc: > Sent: Friday, May 20, 2005 9:18 AM > Subject: Re: [Isms] Thoughts on Encapsulation > > >>>>> "Eliot" == Eliot Lear writes: > > Eliot> I'm specifically referring to call-home support where you > Eliot> want the managed entity to contact the manager. You > Eliot> *could* make this work for SSH. I think the protocol > Eliot> supports it. But nobody's done it (nor seems to want to). > > OK, so an extension of the notify problem? > > I have seen people configure ssh to do this, but yes, it was a bit > tricky. ... Not just "the notify problem." It is also an issue for boxes supporting, for example, RFCs 2981, 3165, or 4011. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 20 13:28:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBIi-0002Tm-Nz; Fri, 20 May 2005 13:28:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBIi-0002Th-3i for isms@megatron.ietf.org; Fri, 20 May 2005 13:28: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 NAA10905 for ; Fri, 20 May 2005 13:28:41 -0400 (EDT) Received: from ibe02.i.pppool.de ([85.73.190.2] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZBa7-0000Bj-7M for isms@ietf.org; Fri, 20 May 2005 13:46:43 -0400 Received: by boskop.local (Postfix, from userid 501) id E770C2F2A24; Fri, 20 May 2005 19:28:34 +0200 (CEST) Date: Fri, 20 May 2005 19:28:34 +0200 From: Juergen Schoenwaelder To: Eliot Lear Subject: Re: [Isms] Thoughts on Encapsulation Message-ID: <20050520172834.GB13586@boskop.local> Mail-Followup-To: Eliot Lear , "Khanh Nguyen (khanhvn)" , isms@ietf.org References: <20050520064242.GE12241@boskop.local> <428DDF1D.4010307@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428DDF1D.4010307@cisco.com> User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Fri, May 20, 2005 at 02:59:09PM +0200, Eliot Lear wrote: > I think there is this notion that SSH is some magic thing that all > service providers implement and therefore want everything they do to > pass over it. I'd be happy living with this except it really doesn't > work in a managed services environment and people are ignoring that. What is a "managed services environment" and what are the reasons why ssh does not work there? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 20 14:19:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZC5W-0001Sk-B5; Fri, 20 May 2005 14:19:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZC5V-0001Sf-UT for isms@megatron.ietf.org; Fri, 20 May 2005 14:19:09 -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 OAA19689 for ; Fri, 20 May 2005 14:19:08 -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 1DZCMu-00026m-IL for isms@ietf.org; Fri, 20 May 2005 14:37:09 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 20 May 2005 11:18:59 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4KIIFQI000008; Fri, 20 May 2005 11:18:53 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 11:18:51 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] Thoughts on Encapsulation Date: Fri, 20 May 2005 11:18:51 -0700 Message-ID: Thread-Topic: [Isms] Thoughts on Encapsulation Thread-Index: AcVdO7njQLsckWXRS6u9/cvIfsIH1gAJmJAQ From: "Khanh Nguyen \(khanhvn\)" To: "Eliot Lear" X-OriginalArrivalTime: 20 May 2005 18:18:52.0035 (UTC) FILETIME=[601BE530:01C55D68] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 > From: Eliot Lear [mailto:lear@cisco.com]=20 >=20 > BTW, PSKs have their own sets of problems, like=20 > preprovisioning of keys, again in a managed service environment. >=20 Any authentication system will need preprovisioning of some=20 credentials. Of course we can talk about leveraging existing=20 credentials, but that's another topic. Khanh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 20 14:27:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCE0-0003ZD-6U; Fri, 20 May 2005 14:27:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCDy-0003Z8-Ng for isms@megatron.ietf.org; Fri, 20 May 2005 14:27:54 -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 OAA20421 for ; Fri, 20 May 2005 14:27:53 -0400 (EDT) Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZCVN-0002Kt-7I for isms@ietf.org; Fri, 20 May 2005 14:45:54 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4KIRhou006248 for ; Fri, 20 May 2005 18:27:43 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j4KIRhIX029433 for ; Fri, 20 May 2005 18:27:43 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005052011274327670 for ; Fri, 20 May 2005 11:27:43 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 11:27:43 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 11:27:42 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 14:27:40 -0400 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] Thoughts on Encapsulation Date: Fri, 20 May 2005 14:26:54 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929012AACE7@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Thoughts on Encapsulation Thread-Index: AcVdO7njQLsckWXRS6u9/cvIfsIH1gAJmJAQAAG58aA= From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 20 May 2005 18:27:41.0108 (UTC) FILETIME=[9B760740:01C55D69] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 > Any authentication system will need preprovisioning of some=20 > credentials. Of course we can talk about leveraging existing=20 > credentials, but that's another topic. I thought the main thrust behind this exercise was to find a way to re-use existing credentials to make deployment easier.=20 Another (smaller but still significant) issue was the desire to introduce temporary short-term (session) keys to complement long-term keys. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 20 14:28:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCEt-0003g3-PU; Fri, 20 May 2005 14:28:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCEs-0003fs-Nz for isms@megatron.ietf.org; Fri, 20 May 2005 14:28:50 -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 OAA20466 for ; Fri, 20 May 2005 14:28:49 -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 1DZCWH-0002ML-6R for isms@ietf.org; Fri, 20 May 2005 14:46:50 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 20 May 2005 11:28:38 -0700 X-IronPort-AV: i="3.93,124,1115017200"; d="scan'208"; a="267770502:sNHT28884798" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4KISGOF019761; Fri, 20 May 2005 11:28:31 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 11:28:34 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] Thoughts on Encapsulation Date: Fri, 20 May 2005 11:28:34 -0700 Message-ID: Thread-Topic: [Isms] Thoughts on Encapsulation Thread-Index: AcVdTQ/EffGjaIaoS8qt376ZClIC0AAErstw From: "Khanh Nguyen \(khanhvn\)" To: "Sam Hartman" X-OriginalArrivalTime: 20 May 2005 18:28:34.0616 (UTC) FILETIME=[BB5AB380:01C55D69] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 > From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 >=20 > >>>>> "Khanh" =3D=3D Khanh Nguyen (khanhvn) = writes: >=20 > Khanh> Assume that we pick TLS and DTLS (correct me if that's a > Khanh> wrong assumption:), then I guess the next step in terms of > Khanh> architectural decisions will be about authentication. > Khanh> There are a few options that have been raised: >=20 > Khanh> 1. Certificate (for server auth) + SASL (for client) >=20 > That's certainly not what I said. I said certificate+SASL. =20 > Certs are normally used for servers; SASL for clients. =20 > However you should support all the combinations if you go this route. Sorry for missing that. BTW, if you use SASL password auth for both client and server (mutual auth), then that belongs option 3 (PSK/LPSK)=20 >=20 > Khanh>=20 > Khanh> 2. Mutual authentication using Kerberos=20 >=20 > You should not directly use Kerberos unless you explain why=20 > SASL and SSH fail to meet your needs. Both of these=20 > approaches get you reasonable Kerberos support. I didn't say that we should use Kerberos directly :) I mentioned Kerberos as a class of authentication method in general, which can=20 be implemented by different transport mechanisms (SASL, SSH, etc). I was trying to decouple transport from authentication, at least=20 conceptually for the sake of our architectural decisions. Khanh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 20 15:16:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCyZ-0002hA-RS; Fri, 20 May 2005 15:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCyY-0002h5-K3 for isms@megatron.ietf.org; Fri, 20 May 2005 15:16:02 -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 PAA28160 for ; Fri, 20 May 2005 15:16:00 -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 1DZDFy-0004GL-93 for isms@ietf.org; Fri, 20 May 2005 15:34:02 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 20 May 2005 12:15:53 -0700 X-IronPort-AV: i="3.93,124,1115017200"; d="scan'208"; a="267788755:sNHT31053228" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4KJFBQK003734; Fri, 20 May 2005 12:15:50 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 12:15:48 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Leverage existing infrastructure (was RE: [Isms] Thoughts onEncapsulation) Date: Fri, 20 May 2005 12:15:48 -0700 Message-ID: Thread-Topic: Leverage existing infrastructure (was RE: [Isms] Thoughts onEncapsulation) Thread-Index: AcVdTQXVCZpcPPK2RIubQvPgwFQ5KAAHMhdQ From: "Khanh Nguyen \(khanhvn\)" To: "Wayne Kading" X-OriginalArrivalTime: 20 May 2005 19:15:48.0425 (UTC) FILETIME=[546FA390:01C55D70] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 > From: Wayne Kading [mailto:wkading@atcorp.com]=20 >=20 > Khanh, >=20 > Your reasoning below is one of the major reasons I preferred=20 > the EK architecture. I would like to know whether the WG=20 > would consider the LPSK proposal as a mandatory option for=20 > ISMS authentication. Many thanks for bringing LPSK to ISMS attentions. The TLSM model addressed the transport encapsulation, but it still leaves the=20 authentication issue pretty much open. LPSK attempts to fill=20 that in, and I would like to hear from other people your opinions about it. My LPSK draft is still preliminary, and I badly need lots of helps and advises to refine it and fit it in the SNMPv3=20 architecture. >=20 > Also, what is involved with your reference to "some automated=20 > software upgrade?" Basically it involves (1) upgrading SNMPv1/v2 software image to SNMPv3, and (2) converting the plain-text community strings=20 stored in the device into LPSK values. The process can be fully=20 automated using tools such as CiscoWorks RME. Khanh >=20 > Wayne >=20 > -----Original Message----- > From: isms-bounces@lists.ietf.org=20 > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Khanh=20 > Nguyen (khanhvn) > Sent: Thursday, May 19, 2005 8:46 PM > To: Wes Hardaker > Cc: isms@ietf.org > Subject: Leverage existing infrastructure (was RE: [Isms] Thoughts > onEncapsulation) >=20 > > From: Wes Hardaker > > The right way to think about it, IMHO, is being able to use=20 > whatever=20 > > the operators already have in place. That was the whole=20 > point of the=20 > > WG. IE, if they have something in place we can directly=20 > leverage then=20 > > the incremental cost is 0 >=20 > I do agree that leverage existing infrastructure is important. > The "minimal deployment efforts" criteria should take into=20 > account what operators already deployed. =20 >=20 > The problem is that different operators deploys different things. > Your survey indicates that local accounts is the only auth=20 > method that a majority of operators use. All other methods are < 50%. > So I think leveraging local accounts should be #1 priority. >=20 > In addition, I believe we should not focus only on leveraging > *other* management interface (e.g. CLI) while ignore=20 > leveraging existing SNMP deployment itself (e.g. SNMPv1/v2). I think > SNMPv1/v2 installed base out there is huge, and that should=20 > be the primary target of our new security model. >=20 > Imagine that you can convert the whole SNMPv1/v2=20 > infrastructure of a company overnight to highly-secure SNMPv3=20 > with "zero touch"=20 > (except some automated software upgrade) and "zero dependence" > on other external infrastructure (PKI, kerberos, radius,=20 > CLI...) Is that appealing? I don't want to do=20 > self-promoting, but the LPSK proposal can do just that. =20 >=20 > Regards. >=20 > Khanh >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 20 16:23:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZE1e-0007yo-Pr; Fri, 20 May 2005 16:23:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZE1c-0007yj-Tq for isms@megatron.ietf.org; Fri, 20 May 2005 16:23:16 -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 QAA11123 for ; Fri, 20 May 2005 16:23:14 -0400 (EDT) Message-Id: <200505202023.QAA11123@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZEJ2-0008Ub-Jm for isms@ietf.org; Fri, 20 May 2005 16:41:17 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <20050520202304015007ir9re>; Fri, 20 May 2005 20:23:04 +0000 From: "David B Harrington" To: "'Sam Hartman'" , "'Eliot Lear'" Subject: RE: [Isms] Thoughts on Encapsulation Date: Fri, 20 May 2005 16:22:57 -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: AcVdWBfvt23gpaSLQZGRretsfdsqLQAIYbOg In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Sam, Can you identify who you saw do this, so we can ask how they did it? 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: Friday, May 20, 2005 12:19 PM > To: Eliot Lear > Cc: isms@ietf.org > Subject: Re: [Isms] Thoughts on Encapsulation > > >>>>> "Eliot" == Eliot Lear writes: > > Eliot> I'm specifically referring to call-home support where you > Eliot> want the managed entity to contact the manager. You > Eliot> *could* make this work for SSH. I think the protocol > Eliot> supports it. But nobody's done it (nor seems to want to). > > OK, so an extension of the notify problem? > > I have seen people configure ssh to do this, but yes, it was a bit > tricky. > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 20 16:59:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZEaZ-0008WR-HQ; Fri, 20 May 2005 16:59:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZEaW-0008V5-6g for isms@megatron.ietf.org; Fri, 20 May 2005 16:59: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 QAA13732 for ; Fri, 20 May 2005 16:59:17 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZErw-0000sM-2p for isms@ietf.org; Fri, 20 May 2005 17:17:21 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 20 May 2005 13:59:10 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j4KKwXxo012132; Fri, 20 May 2005 13:59:07 -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); Fri, 20 May 2005 13:59:01 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] Thoughts on Encapsulation Date: Fri, 20 May 2005 13:58:59 -0700 Message-ID: Thread-Topic: [Isms] Thoughts on Encapsulation Thread-Index: AcVdO7njQLsckWXRS6u9/cvIfsIH1gAJmJAQAAG58aAABM6nIA== From: "Khanh Nguyen \(khanhvn\)" To: "Blumenthal, Uri" , X-OriginalArrivalTime: 20 May 2005 20:59:01.0098 (UTC) FILETIME=[BF8E8CA0:01C55D7E] 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 > From: Blumenthal, Uri >=20 > > Any authentication system will need preprovisioning of some=20 > > credentials. Of course we can talk about leveraging existing=20 > > credentials, but that's another topic. >=20 > I thought the main thrust behind this exercise was to find a=20 > way to re-use existing credentials to make deployment easier.=20 Sorry for not making myself clear. I do strongly support reuse. My point is that reuse is a _means_ to achieve the _end_ which=20 is easing SNMPv3 deployment & maintenance. We should not try to reuse just for the sake of reuse. Any reuse method should be=20 evaluated in terms of its total benefit-cost contribution toward=20 the end goal of ISMS: "The solution should maximize useability in operational environments to achieve high deployment success and at the same time minimize=20 implementation and deployment costs to minimize the time until=20 deployment is possible..." >=20 > Another (smaller but still significant) issue was the desire=20 > to introduce temporary short-term (session) keys to=20 > complement long-term keys. Agree. This issue is sometime overlooked. Maybe we should=20 add this point to ISMS charter. Khanh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 20 18:47:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZGH7-0001IN-GE; Fri, 20 May 2005 18:47:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYnTm-0003ym-1v for isms@megatron.ietf.org; Thu, 19 May 2005 12:02:34 -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 MAA19434 for ; Thu, 19 May 2005 12:02:31 -0400 (EDT) Received: from mail.networksolutionsemail.com ([205.178.146.50]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DYnkw-0006H4-HH for isms@ietf.org; Thu, 19 May 2005 12:20:20 -0400 Received: (qmail 13761 invoked by uid 78); 19 May 2005 16:02:18 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 19 May 2005 16:02:18 -0000 Message-ID: <428CB888.3050801@andybierman.com> Date: Thu, 19 May 2005 09:02:16 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eliot Lear Subject: Re: [Isms] Thoughts on Encapsulation [BEEP/NETCONF] References: <20050519073213.GA10235@boskop.local> <428C4B51.8050201@cisco.com> In-Reply-To: <428C4B51.8050201@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 20 May 2005 18:47:24 -0400 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Eliot Lear wrote: This is an interesting thread. It will be difficult to sort out the possibilities without answered a question we used to ask a lot in the IETF: What problem are you solving here? There are many ways to look at the "can't get there from here" problem. They usually depend on where you're standing at the time. Juergen already pointed out some of possibilities. I don't see the advantage of a shared BEEP connection between SNMP and NETCONF entities, as opposed to separate connections using the same security profile. I can't imagine a "SNMP over NETCONF" initiative going very far in the standards process. SMIv2 data converted to XML encoding maybe. Andy > Juergen, > > [just a terminology note- in this message SNMP means the content above > L3 that would be tunneled, except where noted(*).] > > A few of us are currently thinking about a BEEP profile for SNMP. Our > current thoughts are to continue to use binary format, however. This > allows for additional code reuse and compact data structures. > However, one could specify profiles for both ASN.1 and an XML schema. > That having been said, I prefer a single approach to begin with to > improve chances of interoperability. > > Whether this is tied to NETCONF or not is an interesting question. It > would be REALLY nice for SNMP & NETCONF to share the same security > context. Doing so means that one would need to adapt to the other as > far as what the securityName is, for instance. > > As to whether to use the same port, my first consideration is whether > a firewall administrator doing port blocking would want to block this > form of SNMP(*) apart from NETCONF. I think the answer is no. > However... > > My next consideration is whether it is reasonable to have SNMP depend > on NETCONF. From a BEEP standpoint, if you're sharing the same TCP > connection, either at the initial greeting, or the greeting after TLS > is established, you must announce all allowed profiles. Once you're > there you need to announce one or more SNMP profiles because BEEP > doesn't allow for a repeat of the greeting. The only other option > would be to incorporate this form of SNMP into NETCONF base protocol > semantics, and quite frankly pragmatically I'm not a fan. It sounds > like chances of getting both done reduce as a product of each other. > > There's a final consideration about how well the flow control in BEEP > will be able to sustain / support both uses. Here I'm inclined to > think that it's sufficient, but I'm not firmly convinced. > > Therefore I'd suggest that it should be possible to share a BEEP > connection between NETCONF and SNMP but not required. In order for me > to say this I have to believe that interoperability will not be > impacted. I don't think it will be. Am I wrong? > > Thoughts? > > Eliot > > Juergen Schoenwaelder wrote: > >> On Wed, May 18, 2005 at 06:57:54PM -0700, Khanh Nguyen (khanhvn) wrote: >> >> >>> It has been a couple of weeks since we decided to use EK. What should >>> we do next? Sam gave some thoughts about 3 choices of transport >>> encapsulation: TLS, SSH, and DTLS, and our recent discussions seem >>> to indicate a consensus that we may need more than one >>> (to support both TCP and UDP.) >>> >>> Assume that we pick TLS and DTLS (correct me if that's a wrong >>> assumption:) [...] >> >> >> >> I would not drop ssh. Besides insecure telnet, ssh is _the_ protocol >> to access CLIs and netconf also mandates the support of ssh. >> >> The other option of course would be to define a netconf extension that >> effectively tunnels SNMP like requests through netconf. So on the box, >> you would just process an SNMP like rpc by mapping it on >> the local SNMP instrumentation and on the manager side you might be >> be able to provide an API which is similar to your existing SNMP API >> and then at the end things run over netconf's transport (whatever >> you choose). Now such ideas are of course clearly out of the scope >> of the charter of this WG. ;-) >> >> /js >> > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri May 20 19:46:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZHC0-000874-9t; Fri, 20 May 2005 19:46:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZHBz-00086y-4h for isms@megatron.ietf.org; Fri, 20 May 2005 19:46:11 -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 TAA27732 for ; Fri, 20 May 2005 19:46:07 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZHTR-0004ky-GH for isms@ietf.org; Fri, 20 May 2005 20:04:13 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 20 May 2005 16:46:01 -0700 Received: from kaushik-w2k03.cisco.com (sjc-vpn7-505.cisco.com [10.21.145.249]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j4KNjwxP008802; Fri, 20 May 2005 16:45:59 -0700 (PDT) Message-Id: <6.2.0.14.0.20050520163011.061cd078@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 20 May 2005 16:45:58 -0700 To: Andy Bierman From: Kaushik Narayan Subject: Re: [Isms] Thoughts on Encapsulation [BEEP/NETCONF] In-Reply-To: <428CB888.3050801@andybierman.com> References: <20050519073213.GA10235@boskop.local> <428C4B51.8050201@cisco.com> <428CB888.3050801@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Andy, There could be benefits to sharing a BEEP connection between SNMPv3 and NETCONF (and potentially Secure Syslog) especially since SNMPv3 will be able to re-use a long lived channel between the management systems and managed entities and save the cost of the TLS exchange and connection state that would required to be maintained in case of an independent connection for SNMP. regards, kaushik! At 09:02 AM 5/19/2005, Andy Bierman wrote: >Eliot Lear wrote: > >This is an interesting thread. >It will be difficult to sort out the possibilities without >answered a question we used to ask a lot in the IETF: > >What problem are you solving here? > >There are many ways to look at the "can't get there from here" problem. >They usually depend on where you're standing at the time. Juergen >already pointed out some of possibilities. >I don't see the advantage of a shared BEEP connection between SNMP and >NETCONF entities, as opposed to separate connections using the same >security profile. > >I can't imagine a "SNMP over NETCONF" initiative going very far in the >standards process. SMIv2 data converted to XML encoding maybe. > >Andy > >>Juergen, >> >>[just a terminology note- in this message SNMP means the content above L3 >>that would be tunneled, except where noted(*).] >> >>A few of us are currently thinking about a BEEP profile for SNMP. Our >>current thoughts are to continue to use binary format, however. This >>allows for additional code reuse and compact data structures. >>However, one could specify profiles for both ASN.1 and an XML schema. >>That having been said, I prefer a single approach to begin with to >>improve chances of interoperability. >> >>Whether this is tied to NETCONF or not is an interesting question. It >>would be REALLY nice for SNMP & NETCONF to share the same security >>context. Doing so means that one would need to adapt to the other as far >>as what the securityName is, for instance. >> >>As to whether to use the same port, my first consideration is whether a >>firewall administrator doing port blocking would want to block this form >>of SNMP(*) apart from NETCONF. I think the answer is no. >>However... >> >>My next consideration is whether it is reasonable to have SNMP depend on >>NETCONF. From a BEEP standpoint, if you're sharing the same TCP >>connection, either at the initial greeting, or the greeting after TLS is >>established, you must announce all allowed profiles. Once you're there >>you need to announce one or more SNMP profiles because BEEP doesn't allow >>for a repeat of the greeting. The only other option would be to >>incorporate this form of SNMP into NETCONF base protocol semantics, and >>quite frankly pragmatically I'm not a fan. It sounds like chances of >>getting both done reduce as a product of each other. >> >>There's a final consideration about how well the flow control in BEEP >>will be able to sustain / support both uses. Here I'm inclined to think >>that it's sufficient, but I'm not firmly convinced. >> >>Therefore I'd suggest that it should be possible to share a BEEP >>connection between NETCONF and SNMP but not required. In order for me to >>say this I have to believe that interoperability will not be impacted. I >>don't think it will be. Am I wrong? >> >>Thoughts? >> >>Eliot >> >>Juergen Schoenwaelder wrote: >> >>>On Wed, May 18, 2005 at 06:57:54PM -0700, Khanh Nguyen (khanhvn) wrote: >>> >>> >>>>It has been a couple of weeks since we decided to use EK. What should >>>>we do next? Sam gave some thoughts about 3 choices of transport >>>>encapsulation: TLS, SSH, and DTLS, and our recent discussions seem to >>>>indicate a consensus that we may need more than one >>>>(to support both TCP and UDP.) >>>> >>>>Assume that we pick TLS and DTLS (correct me if that's a wrong >>>>assumption:) [...] >>> >>> >>> >>>I would not drop ssh. Besides insecure telnet, ssh is _the_ protocol to >>>access CLIs and netconf also mandates the support of ssh. >>> >>>The other option of course would be to define a netconf extension that >>>effectively tunnels SNMP like requests through netconf. So on the box, >>>you would just process an SNMP like rpc by mapping it on >>>the local SNMP instrumentation and on the manager side you might be >>>be able to provide an API which is similar to your existing SNMP API >>>and then at the end things run over netconf's transport (whatever >>>you choose). Now such ideas are of course clearly out of the scope >>>of the charter of this WG. ;-) >>> >>>/js >> > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 23 14:05:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHIo-0003sr-T7; Mon, 23 May 2005 14:05:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHIn-0003sm-RW for isms@megatron.ietf.org; Mon, 23 May 2005 14:05: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 OAA20252 for ; Mon, 23 May 2005 14:05:20 -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 1DaHao-0006SJ-8A for isms@ietf.org; Mon, 23 May 2005 14:23:59 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id E736011D8A5; Mon, 23 May 2005 11:05:06 -0700 (PDT) From: Wes Hardaker To: "Khanh Nguyen (khanhvn)" Organization: Sparta References: Date: Mon, 23 May 2005 11:05:06 -0700 In-Reply-To: (Khanh Nguyen's message of "Thu, 19 May 2005 18:46:18 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: isms@ietf.org Subject: [Isms] Re: Leverage existing infrastructure X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Thu, 19 May 2005 18:46:18 -0700, "Khanh Nguyen (khanhvn)" said: Wes> The right way to think about it, IMHO, is being able to use Wes> whatever the operators already have in place. That was the Wes> whole point of the WG. IE, if they have something in place Wes> we can directly leverage then the incremental cost is 0 Khanh> I do agree that leverage existing infrastructure is important. It's not "just" important, it's the whole reason the WG was created. Khanh> All other methods [!local accounts] are < 50%. So I think Khanh> leveraging local accounts should be #1 priority. The problem is not so simple. Yes, local accounts are the most widely used but they also don't scale very well. I think to succeed we'll likely have to recommend implementation of 2 different services. Or, do something that will work for both local accounts and centralized accounts (eg, radius). Doing something that supports both will certainly have a huge impact in potential deployment and thus is probably what we should shoot for. Khanh> In addition, I believe we should not focus only on leveraging Khanh> *other* management interface (e.g. CLI) while ignore leveraging Khanh> existing SNMP deployment itself (e.g. SNMPv1/v2). I agree that there is a large deployment of SNMPv1/SNMPv2c. However, I don't think that operators are actually happy about that. I doubt they wanted to configure community names in all their devices if they didn't have to. Khanh> I think SNMPv1/v2 installed base out there is huge, and that Khanh> should be the primary target of our new security model. I disagree entirely. The purpose of this work was to try and move away from a SNMP-centric authentication system like SNMPv1/2c and communities and SNMPv3/USM and into a system they already use for everything else they do (CLI access, web-access, etc). Merely taking our existing system and transforming it into another SNMP-centric system will not help the situation at all. Khanh> Imagine that you can convert the whole SNMPv1/v2 infrastructure Khanh> of a company overnight to highly-secure SNMPv3 with "zero Khanh> touch" (except some automated software upgrade) and "zero Khanh> dependence" on other external infrastructure (PKI, kerberos, Khanh> radius, CLI...) Is that appealing? I don't want to do Khanh> self-promoting, but the LPSK proposal can do just that. I've finally gotten around to reading the LPSK proposal, and I'm sorry it's taken so long, but in essence it is essentially a USM clone. You're merely promoting a new way to generate SNMP-specific keys that could actually be done today with USM keys for that matter (there is no reason that at account creation time in a device you couldn't auto-populate the USM table based on the same information; but no one does this). You're proposing having essentially a parallel user database that is populated either with community string to key conversions or existing password to key conversions. This doesn't meet my expectations on a number of levels: 1) Most importantly, to summarize the above: you're not reusing existing infrastructure other than SNMP's own infrastructure. That's not what I believe is what operators want. They want you to reuse *their* infrastructure, not SNMP's. 2) community strings have been sent in the clear already; I'd rather not convert those previously-passed-unprotected strings to keys when an attacker quite possibly may already know the starting data. 2) You're making an assumption about being able to convert existing users into LPSK users merely by taking their existing passwords and converting them to keys. This has multiple issues with it: a) The passwords may not be stored in the box in the clear. MD5 sums, crypt sums, or other one-way hash functions are often used to store messed-with passwords locally so that the real passwords need not be kept live on the device. Exceptions to this include systems that make use of cram-md5 and similar services which require live-password storage. b) The accounts may not be stored in the device. EG, Radius and other AAA like mechanisms don't communicate the password to the device and thus the device can't bootstrap itself in the first place. c) What happens when account passwords change either locally or remotely. Those keys need to be updated too, and if they're not stored locally then you'd have to have notification of the new password or key to use. This should be avoided if at all possible for multiple reasons, including scalability. Synchronizing 2 independent user tables will be a pain to make work properly and be scalable, robust and not prone to severe errors. IMHO, There should be one database and snmp shouldn't have an independent one. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 23 16:27:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaJWG-0003iN-Q4; Mon, 23 May 2005 16:27:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaJWE-0003iI-R3 for isms@megatron.ietf.org; Mon, 23 May 2005 16:27:22 -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 QAA17851 for ; Mon, 23 May 2005 16:27:19 -0400 (EDT) Message-Id: <200505232027.QAA17851@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaJoA-0007oy-OJ for isms@ietf.org; Mon, 23 May 2005 16:45:59 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005052320264401100ov48ge>; Mon, 23 May 2005 20:26:44 +0000 From: "David B Harrington" To: "'Wes Hardaker'" , "'Khanh Nguyen \(khanhvn\)'" Subject: RE: [Isms] Re: Leverage existing infrastructure Date: Mon, 23 May 2005 16:26:39 -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: Thread-Index: AcVfwg04EoePuLHYRIeFqo4Lwt3esgAEvY0Q X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Tongue firmly in cheek ;-) > Khanh> In addition, I believe we should not focus only on leveraging > Khanh> *other* management interface (e.g. CLI) while ignore leveraging > Khanh> existing SNMP deployment itself (e.g. SNMPv1/v2). > > I agree that there is a large deployment of SNMPv1/SNMPv2c. However, > I don't think that operators are actually happy about that. I doubt > they wanted to configure community names in all their devices if they > didn't have to. This problem has already been solved; device vendors provide default passwords of "public", and most operators leave them configured that way. What could be simpler? ISMS problem solved! 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 May 23 20:46:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaNZJ-00027v-KG; Mon, 23 May 2005 20:46:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaNZH-00027q-VE for isms@megatron.ietf.org; Mon, 23 May 2005 20:46: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 UAA18512 for ; Mon, 23 May 2005 20:46:46 -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 1DaNrM-0003sQ-QD for isms@ietf.org; Mon, 23 May 2005 21:05:29 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 23 May 2005 17:46:38 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4O0jucU013459; Mon, 23 May 2005 17:46:33 -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); Mon, 23 May 2005 17:46:35 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 23 May 2005 17:46:33 -0700 Message-ID: Thread-Topic: Leverage existing infrastructure Thread-Index: AcVfwhe8g8WphCKCS6iB4FqXc+gSZQAAzz/g From: "Khanh Nguyen \(khanhvn\)" To: "Wes Hardaker" X-OriginalArrivalTime: 24 May 2005 00:46:35.0037 (UTC) FILETIME=[092D8CD0:01C55FFA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org Subject: [Isms] RE: Leverage existing infrastructure 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 Thanks for your comments. Please see inline... > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com]=20 > ... > Khanh> All other methods [!local accounts] are < 50%. So I think=20 > Khanh> leveraging local accounts should be #1 priority. >=20 > The problem is not so simple. Yes, local accounts are the=20 > most widely used but they also don't scale very well. I=20 > think to succeed we'll likely have to recommend=20 > implementation of 2 different services. Or, do something=20 > that will work for both local accounts and centralized=20 > accounts (eg, radius). Doing something that supports both=20 > will certainly have a huge impact in potential deployment and=20 > thus is probably what we should shoot for. Agree. >=20 > Khanh> In addition, I believe we should not focus only on leveraging > Khanh> *other* management interface (e.g. CLI) while ignore=20 > leveraging=20 > Khanh> existing SNMP deployment itself (e.g. SNMPv1/v2). >=20 > I agree that there is a large deployment of SNMPv1/SNMPv2c. =20 > However, I don't think that operators are actually happy=20 > about that. I doubt they wanted to configure community names=20 > in all their devices if they didn't have to. And they don't have to. LPSK can be either community-based *or*=20 user-based. It's up to operators to choose. >=20 > Khanh> I think SNMPv1/v2 installed base out there is huge, and that=20 > Khanh> should be the primary target of our new security model. >=20 > I disagree entirely. The purpose of this work was to try and=20 > move away from a SNMP-centric authentication system like=20 > SNMPv1/2c and communities and SNMPv3/USM and into a system=20 > they already use for everything else they do (CLI access,=20 > web-access, etc). Merely taking our existing system and=20 > transforming it into another SNMP-centric system will not=20 > help the situation at all. You mean SNMP security should *not* be SNMP-centric? I think it should be at least an option that SNMP can be operated independently. Sometime it may be desirable to=20 decouple SNMP users from, say, CLI users. For example, if=20 you have N snmp access views and M CLI access levels (e.g.=20 no CLI + regular + enable mode), then by joining SNMP and CLI users, you have NxM possible combinations of access levels to=20 manage. I am not saying that you should not reuse CLI users, but we need to give operators a choice. > Khanh> Imagine that you can convert the whole SNMPv1/v2=20 > infrastructure=20 > Khanh> of a company overnight to highly-secure SNMPv3 with=20 > "zero touch"=20 > Khanh> (except some automated software upgrade) and "zero=20 > dependence" on=20 > Khanh> other external infrastructure (PKI, kerberos, radius,=20 > CLI...) Is=20 > Khanh> that appealing? I don't want to do self-promoting,=20 > but the LPSK=20 > Khanh> proposal can do just that. >=20 > I've finally gotten around to reading the LPSK proposal, and=20 > I'm sorry it's taken so long, but in essence it is=20 > essentially a USM clone. I guess you misunderstood the LPSK proposal (may be that's my fault :) LPSK borrows USM key localization concepts, but for different purposes. In USM, localized keys (long term) are=20 used for MAC and encryption. In LPSK, MAC and encryp keys are=20 generated dynamically (short term), while localized secrets=20 are used for authentication (via SRP, CHAP, etc.)=20 In addition, LPSK is a generic method that can be used with=20 not only USM passwords but also other type of shared secrets (community strs, CLI passwds, local or remote accounts, etc.) > You're merely promoting a new way to generate SNMP-specific=20 > keys that could actually be done today with USM keys for that=20 > matter (there is no reason that at account creation time in a=20 > device you couldn't auto-populate the USM table based on the=20 > same information; but no one does this).=20 I think that's in part because USM does not specify a standard=20 way to auto-populate the USM table. It provides only some suggestions. LPSK should address that issue by clearly specify some standard localization method(s). > You're proposing=20 > having essentially a parallel user database that is populated=20 > either with community string to key conversions or existing=20 > password to key conversions. This doesn't meet my=20 > expectations on a number of levels: >=20 > 1) Most importantly, to summarize the above: you're not reusing > existing infrastructure other than SNMP's own infrastructure. > That's not what I believe is what operators want. They want you to > reuse *their* infrastructure, not SNMP's. SNMP *is* parts of *their* existing infrastructure too, right? Anyway, as mentioned above, LPSK can reuse other infrastructures too (CLI passwords, etc.) >=20 > 2) community strings have been sent in the clear already; I'd rather > not convert those previously-passed-unprotected strings to keys > when an attacker quite possibly may already know the starting data. Again, using comm str is just one of many LPSK options. Users who chooses to use community-based LPSK can reset the old comm=20 strs anytime after migration. Of course that will no longer be a "zero touch" migration, but it can still be automated using centralized management appl. >=20 > 2) You're making an assumption about being able to convert existing > users into LPSK users merely by taking their existing passwords and > converting them to keys. This has multiple issues with it: >=20 > a) The passwords may not be stored in the box in the clear. MD5 > sums, crypt sums, or other one-way hash functions are often used > to store messed-with passwords locally so that the real > passwords need not be kept live on the device. Exceptions to > this include systems that make use of cram-md5 and similar > services which require live-password storage. Clear-text passwds are not required to generate localized PSK values. =20 Anyway, you brought up a good point about different password formats. Different localization methods may need to be defined, depending on=20 whether the passswds are previously stored in clear-text or encrypted. >=20 > b) The accounts may not be stored in the device. EG, Radius and > other AAA like mechanisms don't communicate the password to the > device and thus the device can't bootstrap itself in the first > place. LPSK values can be stored remotely in AAA server. For example, device can ask TACACS+/RADIUS server (via CHAP) to authenticate a LPSK value. >=20 > c) What happens when account passwords change either locally or > remotely. Those keys need to be updated too, and if they're not > stored locally then you'd have to have notification of the new > password or key to use. This should be avoided if at all > possible for multiple reasons, including scalability. Password changes can be handled just like before: when a password is changed, the corresponding LPSK is updated. If LPSK values are stored locally, then each device needs to be updated, if they are=20 store centrally (AAA server), then the update can be done in one=20 place, just like in any other systems. > Synchronizing 2 independent user tables will be a pain to make > work properly and be scalable, robust and not prone to severe > errors. IMHO, There should be one database and snmp shouldn't > have an independent one. In the end, I think we should give operators both options:=20 (1) SNMP-centric (independent) authentication and=20 (2) reuse-something-else auth. Thanks again for giving me a chance to explain. Regards. Khanh >=20 > -- > Wes Hardaker > Sparta, Inc. >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon May 23 23:09:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaPnp-0004Ac-RI; Mon, 23 May 2005 23:09:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaPnn-00049q-Hv for isms@megatron.ietf.org; Mon, 23 May 2005 23:09:55 -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 XAA26728 for ; Mon, 23 May 2005 23:09:52 -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 1DaQ5p-0007uy-5y for isms@ietf.org; Mon, 23 May 2005 23:28:36 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 2D67111D8A4; Mon, 23 May 2005 20:09:44 -0700 (PDT) From: Wes Hardaker To: "Khanh Nguyen (khanhvn)" Organization: Sparta References: Date: Mon, 23 May 2005 20:09:43 -0700 In-Reply-To: (Khanh Nguyen's message of "Mon, 23 May 2005 17:46:33 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: isms@ietf.org Subject: [Isms] Re: Leverage existing infrastructure X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Mon, 23 May 2005 17:46:33 -0700, "Khanh Nguyen (khanhvn)" said: Khanh> You mean SNMP security should *not* be SNMP-centric? What the operators have indicated over and over to people that they want is a non-SNMP-centric authentication system. Yes. That was the primary purpose for the creation of the working group: to remove the burden of maintaining a SNMP-centric user base in addition to their own. The majority of the operators don't want a separate user space (*). Khanh> I think it should be at least an option that SNMP can be Khanh> operated independently. I actually agree with you, but that's what they have today and that's what they don't like. Some (* from above) may indeed want that, but if that's the case they already have USM today and are probably happy with it. Khanh> Sometime it may be desirable to decouple SNMP users from, say, Khanh> CLI users. For example, if you have N snmp access views and M Khanh> CLI access levels (e.g. no CLI + regular + enable mode), then Khanh> by joining SNMP and CLI users, you have NxM possible Khanh> combinations of access levels to manage. I am not saying that Khanh> you should not reuse CLI users, but we need to give operators a Khanh> choice. I don't think you can merge authorization (access control) between the systems and that is not a goal or even one that has been discussed (because it would likely impossible). I don't want to continue arguing this point since I think we'll simply disagree in the end anyway. What I'm more interested in is if anyone else agrees with you that they should be separate. I'm pretty sure we have consensus that the purpose of the WG is not to create another parallel user database like LPSK is proposing. >> 1) Most importantly, to summarize the above: you're not reusing >> existing infrastructure other than SNMP's own infrastructure. >> That's not what I believe is what operators want. They want you to >> reuse *their* infrastructure, not SNMP's. Khanh> SNMP *is* parts of *their* existing infrastructure too, right? SNMPv1/v2c may be in use, but a pre-existing community infrastructure or a USM infrastructure is actually what most want to get rid of even if they have successfully deployed it. Khanh> Again, using comm str is just one of many LPSK options. Users Khanh> who chooses to use community-based LPSK can reset the old comm Khanh> strs anytime after migration. Of course that will no longer be Khanh> a "zero touch" migration, but it can still be automated using Khanh> centralized management appl. USM today can be automated. And it is by many products. Users still don't want to use it even though it's possible. Khanh> In the end, I think we should give operators both options: Khanh> (1) SNMP-centric (independent) authentication and Khanh> (2) reuse-something-else auth. Agreed. For 1 we have USM. For 2 we have the results of ISMS that should *not* create another database to maintain. Maybe someone other than you will disagree with me about this. Who knows. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 24 16:00:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DafZZ-0005S5-Th; Tue, 24 May 2005 16:00:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DafZY-0005RW-5a for isms@megatron.ietf.org; Tue, 24 May 2005 16:00:16 -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 QAA11872 for ; Tue, 24 May 2005 16:00:14 -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 1Dafrj-0003y5-TJ for isms@ietf.org; Tue, 24 May 2005 16:19:06 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 24 May 2005 13:00:00 -0700 X-IronPort-AV: i="3.93,133,1115017200"; d="scan'208"; a="269165660:sNHT30269108" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4OJxplq025438; Tue, 24 May 2005 12:59:52 -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); Tue, 24 May 2005 12:59:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 May 2005 12:59:43 -0700 Message-ID: Thread-Topic: Leverage existing infrastructure Thread-Index: AcVgDjMWyy2JWXsgS1ScF70/0oQuVwAd+POw From: "Khanh Nguyen \(khanhvn\)" To: "Wes Hardaker" X-OriginalArrivalTime: 24 May 2005 19:59:44.0985 (UTC) FILETIME=[2199C490:01C5609B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org Subject: [Isms] RE: Leverage existing infrastructure 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 > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com]=20 >=20 > Khanh> In the end, I think we should give operators both options:=20 > Khanh> (1) SNMP-centric (independent) authentication and > Khanh> (2) reuse-something-else auth. >=20 > Agreed. For 1 we have USM. For 2 we have the results of=20 > ISMS that should *not* create another database to maintain. =20 > Maybe someone other than you will disagree with me about=20 > this. Who knows. Telling operators who don't want to (or cannot) reuse=20 to 'go away and use USM' is not quite a right solution, I think. Your survey indicated that none of the existing auth infrastructure except local accounts had more than 50% =20 deployment rate. No matter what reuse methods we try, we=20 cannot guarantee that we can have 100% coverage. Sometime=20 the device just has nothing available/suitable for reuse. Do you suggest that for these cases operator has no choice but to use USM? Even within the same company, you may have devices that are different in terms of auth reusability, e.g. some devices=20 support tacacs+, some may not. Would operators have to=20 deploy two SNMP security models, one for "reusable" devices, and a completely different one (USM) for "non-reusable" devices? I think it'll be much better if we can have a single=20 SNMP security model that can support both cases. And last but not least, as Uri Blumenthal pointed out last week, re-use is only one of the two problems we are=20 trying to solve here. The second problem is USM use of=20 long-term keys for encryp & MAC. The second problem is significant because it addresses USM security issues (perfect forward secrecy, off-line=20 dictionary attacks, and replay attacks). Forcing people who cannot reuse to go back to USM is to ignore that=20 second problem. =20 Again, pls don't take my arguments above as "against reuse". I am completely for it. My point is that both SNMP-centric and reuse-something-else auth should be supported in the=20 new security model, and I believe that's an achievable goal. Regards. Khanh >=20 > -- > Wes Hardaker > Sparta, Inc. >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 24 16:20:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daft8-0006nc-Bs; Tue, 24 May 2005 16:20:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daft7-0006lH-Qn for isms@megatron.ietf.org; Tue, 24 May 2005 16:20:29 -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 QAA20856 for ; Tue, 24 May 2005 16:20:27 -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 1DagBM-0007JW-7a for isms@ietf.org; Tue, 24 May 2005 16:39:21 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 75A6511D8A4; Tue, 24 May 2005 13:20:25 -0700 (PDT) From: Wes Hardaker To: "Khanh Nguyen (khanhvn)" Organization: Sparta References: Date: Tue, 24 May 2005 13:20:24 -0700 In-Reply-To: (Khanh Nguyen's message of "Tue, 24 May 2005 12:59:43 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: isms@ietf.org Subject: [Isms] Re: Leverage existing infrastructure X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Tue, 24 May 2005 12:59:43 -0700, "Khanh Nguyen (khanhvn)" said: Khanh> Your survey indicated that none of the existing auth Khanh> infrastructure except local accounts had more than 50% Khanh> deployment rate. No matter what reuse methods we try, we Khanh> cannot guarantee that we can have 100% coverage. Sometime Khanh> the device just has nothing available/suitable for reuse. Khanh> Do you suggest that for these cases operator has no choice Khanh> but to use USM? I never said we shouldn't support multiple other databases. In fact I hope we do. I hope that the end result will be able to use local accounts, remote accounts (AAA), maybe X.509 and hopefully ssh identities. What I don't want is adding yet another that doesn't exist which is a parallel DB like LPSK is proposing. The only reason to do that, IMHO, is if we can't create a solution without doing that. Since I'm sure we can, as multiple proposals have provided such solutions, I don't think that creating another DB is wise. It adds complex management burden to the operators and/or implementors that isn't needed. Khanh> And last but not least, as Uri Blumenthal pointed out Khanh> last week, re-use is only one of the two problems we are Khanh> trying to solve here. The second problem is USM use of Khanh> long-term keys for encryp & MAC. We've selected encapsulation as a transport mechanism, which means we'll likely be using that for the encr and message auth keys. That just leaves user authentication, which we should be using other existing frameworks for (without modification or duplication if at all possible, which it is). -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 24 17:15:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dagk4-0001CT-EO; Tue, 24 May 2005 17:15:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dagk2-0001CO-NH for isms@megatron.ietf.org; Tue, 24 May 2005 17:15:10 -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 RAA25089 for ; Tue, 24 May 2005 17:15:08 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dah2I-00011g-IR for isms@ietf.org; Tue, 24 May 2005 17:34:03 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA03518; Tue, 24 May 2005 14:15:00 -0700 (PDT) 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 j4OLF0n04181; Tue, 24 May 2005 14:15:00 -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); Tue, 24 May 2005 14:14:58 -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] RE: Leverage existing infrastructure Date: Tue, 24 May 2005 14:14:54 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC2DF@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] RE: Leverage existing infrastructure Thread-Index: AcVgDjMWyy2JWXsgS1ScF70/0oQuVwAd+POwAAeyASA= From: "Fleischman, Eric" To: "Khanh Nguyen \(khanhvn\)" X-OriginalArrivalTime: 24 May 2005 21:14:58.0181 (UTC) FILETIME=[A3ACD350:01C560A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 It is my hope and expectation that ISMS will define a secure SNMP alternative that will leverage one or more enterprise-wide authentication systems. For the large end user, PKI and Kerberos are the most important of these systems, with server-based systems (e.g., Radius, Diameter, COPS Servers, and even TACACS+) also being highly desirable. Account-based systems are **not** a scalable alternative for the large end user. -----Original Message----- From: Khanh Nguyen (khanhvn) [mailto:khanhvn@cisco.com]=20 Sent: Tuesday, May 24, 2005 1:00 PM To: Wes Hardaker Cc: isms@ietf.org Subject: [Isms] RE: Leverage existing infrastructure Telling operators who don't want to (or cannot) reuse=20 to 'go away and use USM' is not quite a right solution, I think. Your survey indicated that none of the existing auth infrastructure except local accounts had more than 50% =20 deployment rate. No matter what reuse methods we try, we=20 cannot guarantee that we can have 100% coverage. Sometime=20 the device just has nothing available/suitable for reuse. Do you suggest that for these cases operator has no choice but to use USM? Even within the same company, you may have devices that are different in terms of auth reusability, e.g. some devices=20 support tacacs+, some may not. Would operators have to=20 deploy two SNMP security models, one for "reusable" devices, and a completely different one (USM) for "non-reusable" devices? I think it'll be much better if we can have a single=20 SNMP security model that can support both cases. And last but not least, as Uri Blumenthal pointed out last week, re-use is only one of the two problems we are=20 trying to solve here. The second problem is USM use of=20 long-term keys for encryp & MAC. The second problem is significant because it addresses USM security issues (perfect forward secrecy, off-line=20 dictionary attacks, and replay attacks). Forcing people who cannot reuse to go back to USM is to ignore that=20 second problem. =20 Again, pls don't take my arguments above as "against reuse". I am completely for it. My point is that both SNMP-centric and reuse-something-else auth should be supported in the=20 new security model, and I believe that's an achievable goal. Regards. Khanh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 24 17:41:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dah9p-0006Om-5O; Tue, 24 May 2005 17:41:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dah9n-0006Ob-FZ for isms@megatron.ietf.org; Tue, 24 May 2005 17:41: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 RAA26570 for ; Tue, 24 May 2005 17:41:44 -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 1DahS1-00022d-EM for isms@ietf.org; Tue, 24 May 2005 18:00:39 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 May 2005 14:41:35 -0700 X-IronPort-AV: i="3.93,133,1115017200"; d="scan'208"; a="269202423:sNHT747217758" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4OLf8cE009757; Tue, 24 May 2005 14:41:30 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 14:41:30 -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] RE: Leverage existing infrastructure Date: Tue, 24 May 2005 14:41:30 -0700 Message-ID: Thread-Topic: [Isms] RE: Leverage existing infrastructure Thread-Index: AcVgDjMWyy2JWXsgS1ScF70/0oQuVwAd+POwAAeyASAAAEKqIA== From: "Khanh Nguyen \(khanhvn\)" To: "Fleischman, Eric" X-OriginalArrivalTime: 24 May 2005 21:41:30.0489 (UTC) FILETIME=[58C3BE90:01C560A9] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 > From: Fleischman, Eric [mailto:eric.fleischman@boeing.com]=20 >=20 > It is my hope and expectation that ISMS will define a secure=20 > SNMP alternative that will leverage one or more=20 > enterprise-wide authentication systems. For the large end=20 > user, PKI and Kerberos are the most important of these=20 > systems, with server-based systems (e.g., Radius, Diameter,=20 > COPS Servers, and even TACACS+) also being highly desirable.=20 > Account-based systems are **not** a scalable alternative for=20 > the large end user. Agree. My point is while supporting those reuse methods, we=20 should not eliminate SNMP-centric authentication as an option=20 in the new security model. And even w/ SNMP-centric authentication, you can still leverage existing infrastructure (e.g. reuse existing TACACS+/Radius setup to remotely authenticate SNMP entities) Khanh >=20 > -----Original Message----- > From: Khanh Nguyen (khanhvn) [mailto:khanhvn@cisco.com] > Sent: Tuesday, May 24, 2005 1:00 PM > To: Wes Hardaker > Cc: isms@ietf.org > Subject: [Isms] RE: Leverage existing infrastructure >=20 > Telling operators who don't want to (or cannot) reuse to 'go=20 > away and use USM' is not quite a right solution, I think. >=20 > Your survey indicated that none of the existing auth=20 > infrastructure except local accounts had more than 50%=20 > deployment rate. No matter what reuse methods we try, we=20 > cannot guarantee that we can have 100% coverage. Sometime=20 > the device just has nothing available/suitable for reuse. > Do you suggest that for these cases operator has no choice=20 > but to use USM? >=20 > Even within the same company, you may have devices that are=20 > different in terms of auth reusability, e.g. some devices=20 > support tacacs+, some may not. Would operators have to=20 > deploy two SNMP security models, one for "reusable" devices,=20 > and a completely different one (USM) for "non-reusable" devices? >=20 > I think it'll be much better if we can have a single SNMP=20 > security model that can support both cases. >=20 > And last but not least, as Uri Blumenthal pointed out last=20 > week, re-use is only one of the two problems we are trying to=20 > solve here. The second problem is USM use of long-term keys=20 > for encryp & MAC. >=20 > The second problem is significant because it addresses USM=20 > security issues (perfect forward secrecy, off-line dictionary=20 > attacks, and replay attacks). Forcing people who cannot=20 > reuse to go back to USM is to ignore that second problem. =20 >=20 > Again, pls don't take my arguments above as "against reuse". > I am completely for it. My point is that both SNMP-centric=20 > and reuse-something-else auth should be supported in the new=20 > security model, and I believe that's an achievable goal. >=20 > Regards. >=20 > Khanh >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 24 21:10:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DakPV-0007SI-5q; Tue, 24 May 2005 21:10:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DakPT-0007S8-RT for isms@megatron.ietf.org; Tue, 24 May 2005 21:10:11 -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 VAA13414 for ; Tue, 24 May 2005 21:10:10 -0400 (EDT) Received: from moby.atcorp.com ([204.72.172.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dakhk-0001B1-SK for isms@ietf.org; Tue, 24 May 2005 21:29:06 -0400 Received: from localhost ([127.0.0.1] helo=STRIPER ident=root) by moby.atcorp.com with asmtp (Exim 3.35 #1 (Debian)) id 1DakPF-0004Bq-00; Tue, 24 May 2005 20:09:57 -0500 From: "Wayne Kading" To: "'Wes Hardaker'" Subject: RE: [Isms] Re: Leverage existing infrastructure Date: Tue, 24 May 2005 20:09:56 -0500 Organization: ATC Message-ID: <002e01c560c6$7758da30$84aca8c0@STRIPER> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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 Wes, I believe that addressing the USM security issues identified below in Khanh's message are very significant. The next to the last question in = your survey indicates that even if all proposed reuse authentication = mechanisms were provided, that from a third to a half of the users polled would = still need to support SNMPv3/USM. Therefore, I feel this area needs to be addressed for both security and market penetration reasons. Wayne -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] = On Behalf Of Wes Hardaker Sent: Tuesday, May 24, 2005 3:20 PM To: Khanh Nguyen (khanhvn) Cc: isms@ietf.org Subject: [Isms] Re: Leverage existing infrastructure >>>>> On Tue, 24 May 2005 12:59:43 -0700, "Khanh Nguyen (khanhvn)" said: Khanh> Your survey indicated that none of the existing auth Khanh> infrastructure except local accounts had more than 50% =20 Khanh> deployment rate. No matter what reuse methods we try, we=20 Khanh> cannot guarantee that we can have 100% coverage. Sometime=20 Khanh> the device just has nothing available/suitable for reuse. Khanh> Do you suggest that for these cases operator has no choice Khanh> but to use USM? I never said we shouldn't support multiple other databases. In fact I hope we do. I hope that the end result will be able to use local accounts, remote accounts (AAA), maybe X.509 and hopefully ssh identities. What I don't want is adding yet another that doesn't exist which is a parallel DB like LPSK is proposing. The only reason to do that, IMHO, is if we can't create a solution without doing that. Since I'm sure we can, as multiple proposals have provided such solutions, I don't think that creating another DB is wise. It adds complex management burden to the operators and/or implementors that isn't needed. Khanh> And last but not least, as Uri Blumenthal pointed out Khanh> last week, re-use is only one of the two problems we are=20 Khanh> trying to solve here. The second problem is USM use of=20 Khanh> long-term keys for encryp & MAC. We've selected encapsulation as a transport mechanism, which means we'll likely be using that for the encr and message auth keys. That just leaves user authentication, which we should be using other existing frameworks for (without modification or duplication if at all possible, which it is). --=20 Wes Hardaker Sparta, Inc. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] = On Behalf Of Khanh Nguyen (khanhvn) Sent: Tuesday, May 24, 2005 3:00 PM To: Wes Hardaker Cc: isms@ietf.org Subject: [Isms] RE: Leverage existing infrastructure > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com]=20 >=20 > Khanh> In the end, I think we should give operators both options:=20 > Khanh> (1) SNMP-centric (independent) authentication and > Khanh> (2) reuse-something-else auth. >=20 > Agreed. For 1 we have USM. For 2 we have the results of=20 > ISMS that should *not* create another database to maintain. =20 > Maybe someone other than you will disagree with me about=20 > this. Who knows. . . . I think it'll be much better if we can have a single=20 SNMP security model that can support both cases. And last but not least, as Uri Blumenthal pointed out last week, re-use is only one of the two problems we are=20 trying to solve here. The second problem is USM use of=20 long-term keys for encryp & MAC. The second problem is significant because it addresses USM security issues (perfect forward secrecy, off-line=20 dictionary attacks, and replay attacks). Forcing people who cannot reuse to go back to USM is to ignore that=20 second problem. =20 . . . Regards. Khanh >=20 > -- > Wes Hardaker > Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 25 01:36:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaoZW-0002PA-2E; Wed, 25 May 2005 01:36:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaoZP-0002Nh-Go for isms@megatron.ietf.org; Wed, 25 May 2005 01:36: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 BAA01948 for ; Wed, 25 May 2005 01:36:42 -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 1DaorW-0001DX-Ca for isms@ietf.org; Wed, 25 May 2005 01:55:27 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 460FD11D8A4; Tue, 24 May 2005 22:36:24 -0700 (PDT) From: Wes Hardaker To: "Wayne Kading" Subject: Re: [Isms] Re: Leverage existing infrastructure Organization: Sparta References: <002e01c560c6$7758da30$84aca8c0@STRIPER> Date: Tue, 24 May 2005 22:36:23 -0700 In-Reply-To: <002e01c560c6$7758da30$84aca8c0@STRIPER> (Wayne Kading's message of "Tue, 24 May 2005 20:09:56 -0500") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Tue, 24 May 2005 20:09:56 -0500, "Wayne Kading" said: Wayne> I believe that addressing the USM security issues identified Wayne> below in Khanh's message are very significant. I agree with this entirely. I have always complained quite vocally about USM's security because it doesn't provide a number of things that I'd like it to do. But I'm more picky than most too. Wayne> The next to the last question in your survey indicates that Wayne> even if all proposed reuse authentication mechanisms were Wayne> provided, that from a third to a half of the users polled would Wayne> still need to support SNMPv3/USM. That result always confused me some. I'm not sure why USM would still be used. Potentially because it was satisfactory to them, or potentially because they didn't understand the question. Let me state carefully: 1) I would like a better security solution that USM provides, but we'll be getting that through the encapsulation mechanisms we've been discussing and thus I haven't talked about it. 2) I do want to reuse authentication databases that exist today (which is why SBSM was designed the way it was. A few things were sacrificed in order to get maximum flexibility). 3) I do not think that developing another SNMP-centric scheme is beneficial. I don't care if it's done, as long as it's not required. LPSK, as is, requires it which is all I've ever said I disagree with. It requires a separate authentication system for SNMP. You must keep separate information around to authenticate SNMP users, which I don't think is useful when trying to solve #2 above. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 25 13:03:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DazIR-0007K5-QL; Wed, 25 May 2005 13:03:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DazIQ-0007Jr-Kr for isms@megatron.ietf.org; Wed, 25 May 2005 13:03:54 -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 NAA00626 for ; Wed, 25 May 2005 13:03:52 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dazaq-00037E-4v for isms@ietf.org; Wed, 25 May 2005 13:22:57 -0400 Received: from pc6 (1Cust218.tnt101.lnd4.gbr.da.uu.net [213.116.50.218]) by galaxy.systems.pipex.net (Postfix) with SMTP id DFF82E0000C0; Wed, 25 May 2005 18:03:38 +0100 (BST) Message-ID: <003001c56142$b67b5900$0601a8c0@pc6> From: "Tom Petch" To: References: <3DEC199BD7489643817ECA151F7C592901220F36@pysmsx401.amr.corp.intel.com> <20050513171927.GA1191@boskop.local> Date: Wed, 25 May 2005 15:37:40 +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.8 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: [Isms] SSH key distribution 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 Juergen You have in the past expressed support for SSH (and TLS) on the grounds that they are best understood in your organisation. As I understand it, both depend on public/private key distribution. How are these created and distributed, particularly how do you get the private key into a low powered, remote device (comparable to a desktop switch or access router:-) because this is the issue that keeps making me shy away from them as options for isms? Tom Petch Schoenwaelder" To: "Blumenthal, Uri" Cc: Sent: Friday, May 13, 2005 7:19 PM Subject: Re: [Isms] TLS / SSH scalability concerns > On Fri, May 13, 2005 at 11:43:42AM -0400, Blumenthal, Uri wrote: > > > As for TLS solution turning out *more* > > efficient - forgive me for not entirely trusting those results (assuming > > apples-to-apples comparison, i.e. using SNMPv3 in both cases). > > Larger message sizes, reduced overhead due to session state, perhaps > better optimized libraries. Message size is a very important parameter. > There is a paper in the Fall issue of the IEEE electronic Transactions > on Network and Service Management (eTNSM) which compares SNMP performance > with Web Services and one of the conclusion is that several commercial > SNMP implementations exhibit interesting performance behaviour. It > seems that SNMP performance does not get that much attention and > things sometimes are less optimized than what one would expect. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 25 15:31:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db1bb-0006ld-VW; Wed, 25 May 2005 15:31:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db1ba-0006lY-AO for isms@megatron.ietf.org; Wed, 25 May 2005 15:31:50 -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 PAA12846 for ; Wed, 25 May 2005 15:31:48 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db1u0-0006To-VJ for isms@ietf.org; Wed, 25 May 2005 15:50:54 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-1.cisco.com with ESMTP; 25 May 2005 12:31:35 -0700 X-IronPort-AV: i="3.93,137,1115017200"; d="scan'208"; a="638571402:sNHT1086171006" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j4PJVR3U013612; Wed, 25 May 2005 12:31:32 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 12:31:31 -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] Re: Leverage existing infrastructure Date: Wed, 25 May 2005 12:31:30 -0700 Message-ID: Thread-Topic: [Isms] Re: Leverage existing infrastructure Thread-Index: AcVg67lM/+/8g4FUTj6DBjaXxB9HowAZbqYw From: "Khanh Nguyen \(khanhvn\)" To: "Wes Hardaker" , "Wayne Kading" X-OriginalArrivalTime: 25 May 2005 19:31:31.0481 (UTC) FILETIME=[5A9B5090:01C56160] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 > From: Wes Hardaker [mailto:hardaker@tislabs.com]=20 >=20 > Wayne> The next to the last question in your survey indicates that even=20 > Wayne> if all proposed reuse authentication mechanisms were provided,=20 > Wayne> that from a third to a half of the users polled would still need=20 > Wayne> to support SNMPv3/USM. >=20 > That result always confused me some. I'm not sure why USM=20 > would still be used. Potentially because it was satisfactory=20 > to them, or potentially because they didn't understand the question. I think USM's user-based auth is fine for these users. Nevertheless, they still need the enhanced security provided=20 by EK encryption & data integrity to fix USM security issues. So by using EK+LPSK auth, we can address the needs of these=20 users. USM's authKey database can be reused by LPSK directly=20 (i.e. no conversion needed). Instead of using authKeys for MAC as USM does, LPSK will use those keys for mutual authentication=20 of the TLS/SSH sessions (via SASL-CHAP or SASL-SRP). This=20 eliminates the need to install TLS certificate on every SNMP=20 device. (I think Tom Petch just brought up a good point about deploying certificate/private key in low-powered, remote devices). I have to admit that there are many re-use situations that LPSK is not useful, but for many other situations like the above,=20 LPSK can be a solution. =20 Khanh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 25 16:03:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db26Q-0005lQ-B6; Wed, 25 May 2005 16:03:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db26O-0005lC-Oe for isms@megatron.ietf.org; Wed, 25 May 2005 16:03:40 -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 QAA18098 for ; Wed, 25 May 2005 16:03:39 -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 1Db2Op-0008BC-Re for isms@ietf.org; Wed, 25 May 2005 16:22:45 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 199D111D8A4; Wed, 25 May 2005 13:03:31 -0700 (PDT) From: Wes Hardaker To: "Khanh Nguyen (khanhvn)" Subject: Re: [Isms] Re: Leverage existing infrastructure Organization: Sparta References: Date: Wed, 25 May 2005 13:03:30 -0700 In-Reply-To: (Khanh Nguyen's message of "Wed, 25 May 2005 12:31:30 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Wed, 25 May 2005 12:31:30 -0700, "Khanh Nguyen (khanhvn)" said: Khanh> I think USM's user-based auth is fine for these users. Khanh> Nevertheless, they still need the enhanced security provided Khanh> by EK encryption & data integrity to fix USM security issues. That's not at all how the question is worded and thus I don't think you can jump to that conclusion at all. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 25 16:59:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db2y4-0003It-6V; Wed, 25 May 2005 16:59:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db2y2-0003Hr-ED for isms@megatron.ietf.org; Wed, 25 May 2005 16:59:06 -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 QAA28632 for ; Wed, 25 May 2005 16:59:04 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db3GU-0003Fl-07 for isms@ietf.org; Wed, 25 May 2005 17:18:11 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 25 May 2005 13:58:56 -0700 X-IronPort-AV: i="3.93,137,1115017200"; d="scan'208"; a="638596693:sNHT33797432" Received: from kaushik-w2k03.cisco.com ([171.69.75.179]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4PKwolx018346; Wed, 25 May 2005 13:58:50 -0700 (PDT) Message-Id: <6.2.0.14.0.20050525135435.0328e998@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 25 May 2005 13:58:53 -0700 To: "Khanh Nguyen \(khanhvn\)" From: Kaushik Narayan Subject: RE: [Isms] Re: Leverage existing infrastructure In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [171.69.75.179] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Khanh, >I think USM's user-based auth is fine for these users. >Nevertheless, they still need the enhanced security provided >by EK encryption & data integrity to fix USM security issues. The ISMS WG was formed since there were few users that found USM's user-based auth. adequate. Infact the fundamental object of the ISMS WG was not to fix SNMP security since it was believed to be fine but primarily address the issue of integration with existing authentication systems such as RADIUS, TACACS+ , Local accounts, X.509 etc. regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 25 17:05:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db34V-0004Rn-Ll; Wed, 25 May 2005 17:05:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db34U-0004Ri-PR for isms@megatron.ietf.org; Wed, 25 May 2005 17:05: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 RAA29068 for ; Wed, 25 May 2005 17:05:44 -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 1Db3Mw-0003Nl-Dm for isms@ietf.org; Wed, 25 May 2005 17:24:51 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 25 May 2005 14:05:37 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4PL5Tbw025059; Wed, 25 May 2005 14:05:30 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 14:05:32 -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] Re: Leverage existing infrastructure Date: Wed, 25 May 2005 14:05:31 -0700 Message-ID: Thread-Topic: [Isms] Re: Leverage existing infrastructure Thread-Index: AcVhZQf2NjaZ1TdFTeumpEahukJdFQAB6rrA From: "Khanh Nguyen \(khanhvn\)" To: "Wes Hardaker" X-OriginalArrivalTime: 25 May 2005 21:05:33.0049 (UTC) FILETIME=[7D3E4690:01C5616D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 > From: Wes Hardaker [mailto:hardaker@tislabs.com]=20 >=20 > >>>>> On Wed, 25 May 2005 12:31:30 -0700, "Khanh Nguyen=20 > (khanhvn)" said: >=20 > Khanh> I think USM's user-based auth is fine for these users. > Khanh> Nevertheless, they still need the enhanced security=20 > provided by=20 > Khanh> EK encryption & data integrity to fix USM security issues. >=20 > That's not at all how the question is worded and thus I don't=20 > think you can jump to that conclusion at all. That why I said "I think" not "I conclude" ;) Anyway, can I have a copy of your survey? Sorry I missed it=20 and only heard its partial quote from this alias. Thanks. Khanh >=20 > -- > Wes Hardaker > Sparta, Inc. >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 25 17:17:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db3GH-0006N5-Dg; Wed, 25 May 2005 17:17:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db3GG-0006Mt-7m for isms@megatron.ietf.org; Wed, 25 May 2005 17:17: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 RAA29832 for ; Wed, 25 May 2005 17:17:54 -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 1Db3Yi-0003cq-0Z for isms@ietf.org; Wed, 25 May 2005 17:37:01 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 4B90011D8A4; Wed, 25 May 2005 14:17:49 -0700 (PDT) From: Wes Hardaker To: "Khanh Nguyen (khanhvn)" Subject: Re: [Isms] Re: Leverage existing infrastructure Organization: Sparta References: Date: Wed, 25 May 2005 14:17:47 -0700 In-Reply-To: (Khanh Nguyen's message of "Wed, 25 May 2005 14:05:31 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Wed, 25 May 2005 14:05:31 -0700, "Khanh Nguyen (khanhvn)" said: Khanh> That why I said "I think" not "I conclude" ;) Khanh> Anyway, can I have a copy of your survey? Sorry I missed it Khanh> and only heard its partial quote from this alias. The slides are in the proceedings of one of the IETFs (the second BOF). Now, which one was that is the question. I'm 99% sure it was San Diego. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 25 18:37:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db4VR-0003ou-Hy; Wed, 25 May 2005 18:37:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db4VQ-0003om-0U for isms@megatron.ietf.org; Wed, 25 May 2005 18:37:40 -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 SAA05341 for ; Wed, 25 May 2005 18:37:37 -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 1Db4ns-0005Ce-D7 for isms@ietf.org; Wed, 25 May 2005 18:56:45 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 25 May 2005 15:37:30 -0700 X-IronPort-AV: i="3.93,138,1115017200"; d="scan'208"; a="269691012:sNHT27555964" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4PMafcY025194 for ; Wed, 25 May 2005 15:37:27 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 15:37:23 -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] Re: Leverage existing infrastructure Date: Wed, 25 May 2005 15:37:23 -0700 Message-ID: Thread-Topic: [Isms] Re: Leverage existing infrastructure Thread-Index: AcVhbJD5fNsVGtLyTcmfO/nWup8N4gAAQxHw From: "Khanh Nguyen \(khanhvn\)" To: "Kaushik Narayan \(kaushik\)" X-OriginalArrivalTime: 25 May 2005 22:37:23.0886 (UTC) FILETIME=[51F544E0:01C5617A] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 tend to agree with Uri Blumenthal in his recent posting that there are two problems that need to be solved here: (1) reuse issues and (2) USM security issues due its use of long-term keys. And I guess it's not just Uri and me who think so. After all, our previous IBK/OOBK/EK discussion was about how to introduce short-term keys to replace USM long-term keys. Regards. Khanh > -----Original Message----- > From: Kaushik Narayan (kaushik)=20 > Sent: Wednesday, May 25, 2005 1:59 PM > To: Khanh Nguyen (khanhvn) > Cc: Wes Hardaker; Wayne Kading; isms@ietf.org > Subject: RE: [Isms] Re: Leverage existing infrastructure >=20 > Hi Khanh, >=20 >=20 > >I think USM's user-based auth is fine for these users. > >Nevertheless, they still need the enhanced security provided by EK=20 > >encryption & data integrity to fix USM security issues. >=20 > The ISMS WG was formed since there were few users that found=20 > USM's user-based auth. adequate. Infact the fundamental=20 > object of the ISMS WG was not to fix SNMP security since it=20 > was believed to be fine but primarily address the issue of=20 > integration with existing authentication systems such as=20 > RADIUS, TACACS+ , Local accounts, X.509 etc. >=20 > regards, > kaushik! >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 25 20:02:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db5p9-0000ny-18; Wed, 25 May 2005 20:02:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db5p8-0000nt-3Y for isms@megatron.ietf.org; Wed, 25 May 2005 20:02:06 -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 UAA09817 for ; Wed, 25 May 2005 20:02:05 -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 1Db67b-0006m3-9g for isms@ietf.org; Wed, 25 May 2005 20:21:12 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 25 May 2005 17:01:56 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4Q01em4006785; Wed, 25 May 2005 17:01:53 -0700 (PDT) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 17:01:52 -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] Re: Leverage existing infrastructure Date: Wed, 25 May 2005 17:01:51 -0700 Message-ID: Thread-Topic: [Isms] Re: Leverage existing infrastructure Thread-Index: AcVhbzxqmAAzj5k6SPmB3bUQ2gDa4wAD792Q From: "Khanh Nguyen \(khanhvn\)" To: "Wes Hardaker" X-OriginalArrivalTime: 26 May 2005 00:01:52.0711 (UTC) FILETIME=[1F369570:01C56186] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Thanks. I found it at: http://www.ietf.org/proceedings/04aug/slides/isms-1.pdf Great work. =20 Khanh > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com]=20 > Sent: Wednesday, May 25, 2005 2:18 PM > To: Khanh Nguyen (khanhvn) > Cc: isms@ietf.org > Subject: Re: [Isms] Re: Leverage existing infrastructure >=20 > >>>>> On Wed, 25 May 2005 14:05:31 -0700, "Khanh Nguyen=20 > (khanhvn)" said: >=20 > Khanh> That why I said "I think" not "I conclude" ;) >=20 > Khanh> Anyway, can I have a copy of your survey? Sorry I=20 > missed it and=20 > Khanh> only heard its partial quote from this alias. >=20 > The slides are in the proceedings of one of the IETFs (the=20 > second BOF). Now, which one was that is the question. I'm=20 > 99% sure it was San Diego. >=20 > -- > Wes Hardaker > Sparta, Inc. >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed May 25 20:09:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db5wa-00020N-Jh; Wed, 25 May 2005 20:09:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db5wa-00020I-0Q for isms@megatron.ietf.org; Wed, 25 May 2005 20:09:48 -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 UAA10453 for ; Wed, 25 May 2005 20:09:46 -0400 (EDT) Received: from i8b8a.i.pppool.de ([85.73.139.138] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db6F3-0006wH-Kb for isms@ietf.org; Wed, 25 May 2005 20:28:54 -0400 Received: by boskop.local (Postfix, from userid 501) id 0D9012F470D; Thu, 26 May 2005 02:09:35 +0200 (CEST) Date: Thu, 26 May 2005 02:09:35 +0200 From: Juergen Schoenwaelder To: Tom Petch Message-ID: <20050526000935.GB21284@boskop.local> Mail-Followup-To: Tom Petch , isms@ietf.org References: <3DEC199BD7489643817ECA151F7C592901220F36@pysmsx401.amr.corp.intel.com> <20050513171927.GA1191@boskop.local> <003001c56142$b67b5900$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003001c56142$b67b5900$0601a8c0@pc6> User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: isms@ietf.org Subject: [Isms] Re: SSH key distribution 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, May 25, 2005 at 03:37:40PM +0200, Tom Petch wrote: > Juergen > > You have in the past expressed support for SSH (and TLS) on the grounds > that they are best understood in your organisation. As I understand it, > both depend on public/private key distribution. How are these created > and distributed, particularly how do you get the private key into a low > powered, remote device (comparable to a desktop switch or access > router:-) because this is the issue that keeps making me shy away from > them as options for isms? My understanding is that SSH can be used in different ways. The first basic mechanism is that ssh has a notion of a hostkey which is generated when you install the ssh server and exchanged when you setup a connection. Clients usually learn hostkeys (by accepting them) and keep a list of previously accepted hostkeys. Once the hostkey has been accepted, a session key is generated which is used to encrypt subsequent interactions. In other words, the hostkey to some extend automatically propagates (of course it should be checked when a new client accepts it) and you simply get an encrypted pipe to the server. Once you have the encrypted pipe, you do user authentication. You can use different authentication mechanisms - the most important ones are probably passwords and public/private key pairs. If you use passwords, the box of course needs to know your password. If you use keys, then of course the public part of your key must have been copied to the box in some way. I have seen routers where I can install a user's public key and I have seen switches where I can only work with passwords (which happen to be the same as the good old CLI password). I believe TLS is in many applications used in a very similar way. You have to create a certificate which you store of the server and which is presented to the client. When the client connects to the server, it tries to validate the certificate and if successful sets up encryption. A common pattern is that a SASL exchange is then used to authenticate a user. Due to a weak cryptographic binding between SASL and TLS, there are some security concerns here. (But I believe that this issue will be solved sooner or later since this combination is quite popular in the context of SMTP/IMAP at least). You can use TLS to authenticate users based on certificates without SASL but then you have to manage certificates not only on the server but also on the clients, which in my very limited experience seems to be more hassle than dealing with ssh user keys. This description above is rather high-level and simplified and I am sure totally wrong from the security area member's perspective so I do apologize in advance. Back to your main question: > As I understand it, > both depend on public/private key distribution. How are these created > and distributed, particularly how do you get the private key into a low > powered, remote device (comparable to a desktop switch or access > router:-) because this is the issue that keeps making me shy away from > them as options for isms? If you use ssh with password authentication, basically the whole procedure is kind of automatic (you only have to create the hostkey once on the box). You directly reuse the local accounts (or radius accounts) configured on the box. If you use public key user authentication, you have to copy public keys on the box (and later remove them). The copying itself is not too much resource consuming - the question is more how you manage those keys on the boxes if people come and go. So the complexity is probably similar to managing USM keys. The difference, however, is that these ssh keys may be used to authenticate the same identity regardless whether she uses the CLI, SNMP or NETCONF. [The same is probably true as well for TLS certificates. However, I must admit that so far I only have practical experience with the combination of TLS and SASL (and of course TLS with HTTP authentication).] If I were allowed to make a choice, I would prefer ssh since ssh is well understood by operators and already on many boxes that I personally care about. That said, I do accept that there are other environments where other conclusions would be drawn (and in some environments SNMPv3/USM might actually be the best choice). But if I recall correctly the operator input we received in various places before this WG was created, I do believe that the operators who provided input liked to use ssh and this group should therefore be the most important target group. This seems to be inline with the decisions in other WG such as NETCONF where ssh was adopted as the mandatory to implement transport. (And it was kind of interesting to observe that nobody ever wrote a document specifying plain TLS transport for NETCONF - although I know that there was at least an attempt to implement something like that.) /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 May 25 22:32:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db8Ak-0005yo-0T; Wed, 25 May 2005 22:32:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db8Ah-0005xw-NM for isms@megatron.ietf.org; Wed, 25 May 2005 22:32: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 WAA24206 for ; Wed, 25 May 2005 22:32:29 -0400 (EDT) Message-Id: <200505260232.WAA24206@ietf.org> Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db8TB-0002ry-58 for isms@ietf.org; Wed, 25 May 2005 22:51:39 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <2005052602321901400icvcne>; Thu, 26 May 2005 02:32:20 +0000 From: "David B Harrington" To: "'Khanh Nguyen \(khanhvn\)'" , "'Kaushik Narayan \(kaushik\)'" Subject: RE: [Isms] Re: Leverage existing infrastructure Date: Wed, 25 May 2005 22:32:14 -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: Thread-Index: AcVhbJD5fNsVGtLyTcmfO/nWup8N4gAAQxHwAAs4ocA= X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, This sounds like feature creep to me ;-) The charter says "Although the enhanced protocol is secure, operators and administrators find that deploying it can be problematic in large distributions. This is due primarily to two synchronization problems. The first is the addition of yet another authentication system specific to SNMPv3 that needs to be maintained across all networking devices. [...] The ISMS working group will focus on finding and identifying a solution for the first of the two above mentioned problems: creating a security model for SNMPv3 that will meet the security and operational needs of network administrators. The solution should maximize useability in operational environments to achieve high deployment success and at the same time minimize implementation and deployment costs to minimize the time until deployment is possible. The work will include the ability to make use of existing and commonly deployed security infrastructure. " I don't see in the charter any agreement from the IESG/Ads that we should work on " USM security issues due its use of long-term keys." David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Khanh > Nguyen (khanhvn) > Sent: Wednesday, May 25, 2005 6:37 PM > To: Kaushik Narayan (kaushik) > Cc: isms@ietf.org > Subject: RE: [Isms] Re: Leverage existing infrastructure > > I tend to agree with Uri Blumenthal in his recent posting > that there are > two problems that need to be solved here: (1) reuse issues and (2) USM > security issues due its use of long-term keys. And I guess it's not > just Uri and me who think so. After all, our previous IBK/OOBK/EK > discussion was about how to introduce short-term keys to replace USM > long-term keys. > > Regards. > > Khanh > > > -----Original Message----- > > From: Kaushik Narayan (kaushik) > > Sent: Wednesday, May 25, 2005 1:59 PM > > To: Khanh Nguyen (khanhvn) > > Cc: Wes Hardaker; Wayne Kading; isms@ietf.org > > Subject: RE: [Isms] Re: Leverage existing infrastructure > > > > Hi Khanh, > > > > > > >I think USM's user-based auth is fine for these users. > > >Nevertheless, they still need the enhanced security provided by EK > > >encryption & data integrity to fix USM security issues. > > > > The ISMS WG was formed since there were few users that found > > USM's user-based auth. adequate. Infact the fundamental > > object of the ISMS WG was not to fix SNMP security since it > > was believed to be fine but primarily address the issue of > > integration with existing authentication systems such as > > RADIUS, TACACS+ , Local accounts, X.509 etc. > > > > regards, > > kaushik! > > > > _______________________________________________ > 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 May 26 09:42:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbIdL-0006JA-2o; Thu, 26 May 2005 09:42:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbIdI-0006Iv-UC for isms@megatron.ietf.org; Thu, 26 May 2005 09:42:45 -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 JAA28946 for ; Thu, 26 May 2005 09:42:42 -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 1DbIvt-0001KB-1R for isms@ietf.org; Thu, 26 May 2005 10:01:58 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 28AA611D8A4; Thu, 26 May 2005 06:42:41 -0700 (PDT) From: Wes Hardaker To: ietfdbh@comcast.net Subject: Re: [Isms] Re: Leverage existing infrastructure Organization: Sparta References: <200505260232.WAA24206@ietf.org> Date: Thu, 26 May 2005 06:42:40 -0700 In-Reply-To: <200505260232.WAA24206@ietf.org> (David B. Harrington's message of "Wed, 25 May 2005 22:32:14 -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: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Wed, 25 May 2005 22:32:14 -0400, "David B Harrington" said: David> I don't see in the charter any agreement from the IESG/Ads that we David> should work on " USM security issues due its use of long-term David> keys." Fortunately, EK will actually provide that for us due to the transports we're likely to pick. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu May 26 11:36:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKPl-0000O9-Mt; Thu, 26 May 2005 11:36:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKPh-0000Ny-Vr for isms@megatron.ietf.org; Thu, 26 May 2005 11:36: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 LAA06809 for ; Thu, 26 May 2005 11:36:47 -0400 (EDT) Message-Id: <200505261536.LAA06809@ietf.org> Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbKiI-0003lR-3x for isms@ietf.org; Thu, 26 May 2005 11:56:04 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <2005052615363601400i9cdde>; Thu, 26 May 2005 15:36:36 +0000 From: "David B Harrington" To: Date: Thu, 26 May 2005 11:36:33 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_02EF_01C561E7.2B8715A0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcViCLF/ha5g4XpkRY2CtC/2wZq29g== X-Spam-Score: 0.1 (/) X-Scan-Signature: 24e0a124948865f217f4938c02970e6c Cc: Subject: [Isms] draft-schoenw-snmp-tlsm-02.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_02EF_01C561E7.2B8715A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have requested the publication of draft-schoenw-snmp-tlsm-02.txt Here is a copy of the file for WG perusal until it shows up in the I-D directory. The primary changes have been in the text discussing the TMSM framework. Comments welcome, especially when accompanied by suggested text. We could use some help developing the sample mappings, especially from those familiar with the transport security protocols. Thanks, David Harrington dbharrington@comcast.net ------=_NextPart_000_02EF_01C561E7.2B8715A0 Content-Type: text/plain; name="draft-schoenw-snmp-tlsm-02.txt" Content-Disposition: attachment; filename="draft-schoenw-snmp-tlsm-02.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Harrington Internet-Draft Independent Expires: November 27, 2005 J. Schoenwaelder International University Bremen May 26, 2005 Transport Mapping Security Model (TMSM) for the Simple Network Management Protocol version 3 (SNMPv3) draft-schoenw-snmp-tlsm-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 27, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes a Transport Mapping Security Model (TMSM) for the Simple Network Management Protocol (SNMP) architecture defined in RFC3411. At this stage, this document describes a framework, not a protocol. It does not provide a complete solution - it rather identifies and discusses some key aspects that need discussion and future work. Harrington & Schoenwaelder Expires November 27, 2005 [Page 1] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements of a Transport Mapping Security Model . . . . . . 5 3.1 Security Requirements . . . . . . . . . . . . . . . . . . 5 3.1.1 Security Protocol Requirements . . . . . . . . . . . . 5 3.1.2 Session Requirements . . . . . . . . . . . . . . . . . 6 3.2 Architectural Modularity Requirements . . . . . . . . . . 6 3.2.1 USM and the RFC3411 Architecture . . . . . . . . . . . 9 3.2.2 TMSM and the RFC3411 Architecture . . . . . . . . . . 10 3.3 Passing Messages between Subsystems . . . . . . . . . . . 11 3.4 Security Parameter Passing Requirement . . . . . . . . . . 12 3.4.1 Define an Abstract Service Iinterface . . . . . . . . 13 3.4.2 Using an encapsulating header . . . . . . . . . . . . 13 3.4.3 Modifying Existing Fields in an SNMP Message . . . . . 13 3.4.4 Using a cache . . . . . . . . . . . . . . . . . . . . 14 3.5 Architectural Requirements for Access Control . . . . . . 14 3.5.1 securityName Binding . . . . . . . . . . . . . . . . . 14 3.5.2 Separation of Authentication and Authorization . . . . 15 4. Integration with the SNMPv3 message format . . . . . . . . . . 16 4.1 msgVersion . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2 msgGlobalData . . . . . . . . . . . . . . . . . . . . . . 16 4.3 securityLevel and msgFlags . . . . . . . . . . . . . . . . 17 4.4 The tmStateReference for Passing Security Parameters . . . 18 4.5 securityStateReference Cached Security Data . . . . . . . 18 4.5.1 Prepare an Outgoing SNMP Message . . . . . . . . . . . 19 4.5.2 Prepare Data Elements from an Incoming SNMP Message . 20 4.6 Notifications . . . . . . . . . . . . . . . . . . . . . . 20 5. Transport Mapping Security Model Samples . . . . . . . . . . . 21 5.1 TLS/TCP Transport Mapping Security Model . . . . . . . . . 21 5.1.1 tmStateReference for TLS . . . . . . . . . . . . . . . 21 5.1.2 MPSP for TLS TM-Security Model . . . . . . . . . . . . 22 5.1.3 MIB Module for TLS Security . . . . . . . . . . . . . 22 5.2 DTLS/UDP Transport Mapping Security Model . . . . . . . . 22 5.2.1 tmStateReference for DTLS . . . . . . . . . . . . . . 23 5.3 SASL Transport Mapping Security Model . . . . . . . . . . 24 5.3.1 tmStateReference for SASL DIGEST-MD5 . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1 Normative References . . . . . . . . . . . . . . . . . . . 25 8.2 Informative References . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 A. Questions about msgFlags: . . . . . . . . . . . . . . . . . . 27 A.1 msgFlags versus actual security . . . . . . . . . . . . . 27 A.2 Message security versus session security . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . 30 Harrington & Schoenwaelder Expires November 27, 2005 [Page 2] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 1. Introduction This document describes a Transport Mapping Security Model (TMSM) for the Simple Network Management Protocol (SNMP) architecture defined in RFC3411. At this stage, this document describes a framework, not a protocol. It does not provide a complete solution - it rather identifies and discusses some key aspects that need discussion and future work. There are multiple ways to secure one's home or business, but they largely boil down to a continuum of alternatives. Let's consider three general approaches. In the first approach, an individual could buy a gun, learn to use it, and sit on your front porch waiting for intruders. In the second approach, one could hire an employee with a gun, schedule the employee, position the employee to guard what you want protected, hire a second guard to cover if the first gets sick, and so on. In the third approach, you could hire a security company, tell them what you want protected, and they could hire employees, train them, buy the guns, position the guards, schedule the guards, send a replacement when a guard cannot make it, etc., thus providing the security you want, with no significant effort on your part other than identifying requirements and verifying the quality of the service being provided. The User-based Security Model (USM) as defined in [RFC3414] largely uses the first approach - it provides its own security. It utilizes existing mechanisms (MD5=3Dthe gun), but provides all the = coordination. USM provides for the authentication of a principal, message encryption, data integrity checking, timeliness checking, etc. USM was designed to be independent of other existing security infrastructures. USM therefore requires a separate user and key management infrastructure. Operators have reported that deploying another user and key management infrastructure in order to use SNMPv3 is a reason for not deploying SNMPv3 at this point in time. It is possible but difficult to define external mechanisms that handle the distribution of keys for use by the USM approach. A solution based on the second approach might use a USM-compliant architecture, but replace the authentication mechanism with an external mechanism, such as RADIUS, to provide the authentication service. It might be possible to utilize an external protocol to encrypt a message, to check timeliness, to check data integrity, etc. It is difficult to cobble together a number of subcontracted services and coordinate them however, because it is difficult to build solid security bindings between the various services, and potential for gaps in the security is significant. Harrington & Schoenwaelder Expires November 27, 2005 [Page 3] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 A solution based on the third approach might utilize one or more lower-layer security mechanisms to provide the message-oriented security services required. These would include authentication of the sender, encryption, timeliness checking, and data integrity checking. There are a number of IETF standards available or in development to address these problems at lower layers, frequently at the transport layer. A solution based on this approach might also utilize a "transport application" that is actually another application operating at the application layer, such as SSH [SSHauth] This document proposes a Transport Mapping Security Model (TMSM), as an extension of the SNMPv3 architecture, that would allow security to be provided by an external protocol connected to the SNMP engine through an SNMP transport-mapping. Such a TMSM would then enable the use of existing security mechanisms such as (TLS) [RFC2246], Kerberos [RFC1510] or SASL [RFC2222] within the SNMPv3 architecture. As pointed out in the EUSM proposal [EUSM], it is desirable to use mechanisms that could "unify the approach for administrative security for SNMPv3 and CLI" and other management interfaces. The use of security services provided by lower layers or other applications is the approach commonly used for the CLI, and is the approach being proposed for NETCONF This document describes the motivation for leveraging transport layer security mechanisms for secure SNMP communication, identifies some key issues and provides some proposals for design choices that may be made to provide a workable solution that meets operational requirements and fits into the SNMP architecture defined in [RFC3411] 2. Motivation There are a number of Internet security protocols and mechanisms that are in wide spread use. Many of them try to provide a generic infrastructure to be used by many different application layer protocols. The motivation behind TMSM is to leverage these protocols where it seems useful. There are a number of challenges to be addressed to map the security provided by a secure transport into the SNMP architecture so that SNMP continues to work without any surprises. These are discussed in detail below. Some points requiring further WG research and discussion are identified by [todo] markers in the text. Harrington & Schoenwaelder Expires November 27, 2005 [Page 4] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 3. Requirements of a Transport Mapping Security Model 3.1 Security Requirements Transport mapping security protocols SHOULD ideally provide the protection against the following message-oriented threats [RFC3411]: 1. modification of information 2. masquerade 3. message stream modification 4. disclosure According to [RFC3411], it is not required to protect against denial of service or traffic analysis. 3.1.1 Security Protocol Requirements There are a number of standard protocols that could be proposed as possible solutions within the TMSM framework. Some factors should be considered when selecting a protocol for use within this framework. Using a protocol in a manner for which it was not designed has numerous problems. The advertised security characteristics of a protocol may depend on its being used as designed; when used in other ways, it may not deliver the expected security characteristics. It is recommended that any proposed model include a discussion of the applicability statement of the protocols to be used. A protocol used for the TMSM framework should ideally require no modifications to the protocol. Modifying the protocol may change its security characteristics in ways that would impact other existing usages. If a change is necessary, the change should be an extension that has no impact on the existing usages. It is recommended that any proposed model include a discussion of potential impact on other usages of the protocol. It has been a long-standing requirement that SNMP be able to work when the network is unstable, to enable network troubleshooting and repair. The UDP approach has been considered to meet that need well, with an assumption that getting small messages through, even if out of order, is better than gettting no messages through. There has been a long debate about whether UDP actually offers better support than TCP when the underlying IP or lower layers are unstable. There has been recent discussion of whether operators actually use SNMP to troubleshoot and repair unstable networks. There has been discussion of ways SNMP could be extended to better support management/monitoring needs when a network is running just Harrington & Schoenwaelder Expires November 27, 2005 [Page 5] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 fine. Use of a TCP transport, for example, could enable larger message sizes and more efficient table retrievals. TMSM models MUST be able to coexist with other protocol models, and may be designed to utilize either TCP or UDP, depending on the transport. 3.1.2 Session Requirements Sessions are not part of RFC3411 architecture, but are considered desirable because the cost of authentication can be amortized over potentially many transactions. For transports that utilize sessions, a session should have a single user and security level associated with it. If an exchange between communicating engines would require a different security level or would be on behalf of a different user, then another session would be needed. An immediate consequence of this is that implementations should be able to maintain some reasonable number of concurrent sessions. 3.2 Architectural Modularity Requirements [RFC3411] section 3 describes a modular architecture to allow the evolution of the SNMP protocol standards over time, and to minimize side effects between subsystems when changes are made. This architecture includes a Security Subsystem which is responsible for realizing security services. In SNMPv2, there were many problems of side effects between subsystems caused by the manipulation of MIB objects, especially those related to authentication and authorization, because many of the parameters were stored in shared MIB objects, and different models and protocols could assign different values to the objects. Contributors assumed slightly different shades of meaning depending on the models and protocols being used. As the shared MIB module design was modified to accommodate a specific model, other models which used the same MIB objects were broken. ASIs were developed to pass model-independent parameters. The models were required to translate from their model-dependent formats into a model-independent format, defined using model-independent semantics, which would not impact other models. Parameters have been provided in the ASIs to pass model-independent information about the authentication that has been provided. These parameters include a model-independent identifier of the security "principal", the security model used to perform the authentication, Harrington & Schoenwaelder Expires November 27, 2005 [Page 6] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 and which SNMP-specific security features were applied to the message (authentication and/or privacy). The design of a transport mapping security model must abide the goals of the RFC3411 architecture. To that end, this transport mapping security model proposal focuses on a modular subsystem that can be advanced through the standards process independently of other proposals, and independent of other subsystems as much as possible. There has been some discussion of maintaining multiple tunnels or sessions for different security levels or for different applications.The ability to have an application select different sessions or connections on a per-message basis would likely require a modification to the SNMP architecture to provide new ASIs, which is out of scope for this document. IETF standards typically require one mandatory-to-implement solution, with the capability of adding new security mechanisms in the future. Any transport mapping security model should define one minimum- compliance mechanism, preferably one which is already widely deployed within the transport layer security protocol used. The TMSM subsystem is designed as an architectural extension that permits additional transport security protocols to be "plugged into" the RFC3411 architecture, supported by corresponding transport- security-aware transport mapping models. The RFC3411 architecture, and the USM approach, assume that a security model is called by a message-processing model and will perform multiple security functions. The TMSM approach performs similar functions but performs them in different places within the archtitecture, so we need to distinguish the two locations for security processing. Transport mapping security is by its very nature a security layer which is plugged into the RFC3411 architecture between the transport layer and the message dispatcher. Conceptually, transport mapping security processing will be called from within the Transport Mapping functionality of an SNMP engine dispatcher to perform the translation of transport security parameters to/from security-model-independent parameters. This transport mapping security processor will be referred to in this document as TMSP. Additional functionality may be performed as part of the message processing function, i.e. in the security subsystem of the RFC3411 architecture. This document will refer to message processor's security processor as the MPSP. Harrington & Schoenwaelder Expires November 27, 2005 [Page 7] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 Thus a TMSM is composed of both a TPSP and an MPSP. +------------------------------+ | Network | +------------------------------+ ^ ^ ^ | | | v v v +-----+ +-----+ +-------+ | UDP | | TCP | . . . | other | +-----+ +-----+ +-------+ ^ ^ ^ | | | v v v +------+ +-----+ +-------+ | DTLS | | TLS | . . . | other | +------+ +-----+ +-------+ (traditional SNMP agent) +-------------------------------------------------------------------+ | ^ | | | | | Dispatcher v | | +-------------------+ | | | Transport | +--------------------+ | | | Mapping |<---> | Transport Mapping | | | | (e.g., RFC 3417) | | Security Processor | | | | | +--------------------+ | | | | | | | | +---------------------+ +----------------+ | | | | | Message Processing | | Security | | | | | | Subsystem | | Subsystem | | | | | | +------------+ | | | | | | | | +->| v1MP * |<--->| +------------+ | | | | | | | +------------+ | | | Other | | | | | | | | +------------+ | | | Security | | | | | | | +->| v2cMP * |<--->| | Model | | | | | Message | | | +------------+ | | +------------+ | | | | Dispatcher <--------->| +------------+ | | +------------+ | | | | | | +->| v3MP * |<--->| | User-based | | | | | | | | +------------+ | | | Security | | | | | PDU Dispatcher | | | +------------+ | | | Model | | | | +-------------------+ | +->| otherMP * |<--->| +------------+ | | | ^ | +------------+ | | | | | | +---------------------+ +----------------+ | | v | | +-------+-------------------------+---------------+ | | ^ ^ ^ | | | | | | Harrington & Schoenwaelder Expires November 27, 2005 [Page 8] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 | v v v | | +-------------+ +---------+ +--------------+ +-------------+ | | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | | | application | | | | applications | | application | | | +-------------+ +---------+ +--------------+ +-------------+ | | ^ ^ | | | | | | v v | | +----------------------------------------------+ | | | MIB instrumentation | SNMP entity | +-------------------------------------------------------------------+ 3.2.1 USM and the RFC3411 Architecture This following diagrams illustrate the difference in the security processing done by the USM model and the security processing done by a TMSM model. The USM security model is encapsulated by the messaging model, because the messaging model needs to (for incoming messages) 1) decode the ASN.1 (messaging model) 2) determine the SNMP security model and parameters (messaging model) 3) decrypt the encrypted portions of the message (security model) 4) translate parameters to model-independent parameters (security model) 5) determine which application should get the decrypted portions (messaging model), and 6) pass on the decrypted portions with model-independent parameters. The USM approach uses SNMP-specific message security and parameters. Harrington & Schoenwaelder Expires November 27, 2005 [Page 9] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 | -----------------------------------------------| | transport layer | | -----------------------------------------------| ^ | v -------------------------------------------------- | -----------------------------------------------| | | transport mapping | | -----------------------------------------------| | ^ | | | v | --------------------------------------------- | | --------------------- ------------------ | | SNMP messaging <--> | decryption + | | | | translation | | | --------------------- ------------------ | | ^ | | | v | --------------------- ------------------ | | | SNMP applications | <--> | access control | | | --------------------- ------------------ | | --------------------------------------------- | 3.2.2 TMSM and the RFC3411 Architecture In the TMSM approach, the order of the steps differ and may be handled by different subsystems: 1) decrypt the encrypted portions of the message (transport layer) 2) determine the SNMP security model and parameters (transport mapping) 3*) translate parameters to model- independent parameters (transport mapping) 4) decode the ASN.1 (messaging model) 5) determine which application should get the decrypted portions (messaging model) 6*) translate parameters to model-independent parameters (security model) 7) pass on the decrypted portions with model-independent security parameters This is largely based on having non-SNMP-specific message security and parameters. The transport mapping model might provide the translation from (e.g.) TLS user to securityName in step 3, OR The TLS user might be passed to the messaging model to pass to a TMSM security model to do the translation in step 6, if the WG decides all translations should use the same translation table (e.g. the USM MIB). Harrington & Schoenwaelder Expires November 27, 2005 [Page 10] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 | -----------------------------------------------| | ------------------ | | transport layer <--> | decryption | | | ------------------ | | -----------------------------------------------| ^ | v -------------------------------------------------- | -----------------------------------------------| | ------------------ | | transport mapping <--> | translation* | | | ------------------ | | -----------------------------------------------| | ^ | | | v | --------------------------------------------- | | ------------------ | | SNMP messaging <--> | translation* | | | ------------------ | | --------------------- ------------------ | | ^ | | | v | --------------------- ------------------ | | | SNMP applications | <--> | access control | | | --------------------- ------------------ | | --------------------------------------------- | 3.3 Passing Messages between Subsystems RFC3411 defines ASIs that describe the passing of messages between subsystem within an engine, and the parameters which are expected to be passed between the subsystems. The ASIs generally pass model- independent information. A TMSM model will establish an encrypted tunnel between the transport mappings of two SNMP engines. One transport mapping security model instance encrypts all messages, and the other transport mapping security model instance decrypts the messages. After the transport layer tunnel is established, then SNMP messages can conceptually be sent through the tunnel from one SNMP message Harrington & Schoenwaelder Expires November 27, 2005 [Page 11] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 dispatcher to another SNMP message dispatcher. Once the tunnel is established, multiple SNMP messages may be able to be passed through the same tunnel. Within an engine, outgoing SNMP messages are passed unencrypted from the message dispatcher to the transport mapping, and incoming messages are passed unencrypted from the transport mapping to the message dispatcher. 3.4 Security Parameter Passing Requirement [RFC3411] section 4 describes primitives to describe the abstract service interfaces used to conceptually pass information between the various subsystems, models and applications within the architecture. The security parameters include a model-independent identifier of the security "principal", the security model used to perform the authentication, and which SNMP-specific security services were (should be) applied to the message (authentication and/or privacy). In the RFC3411 architecture, the messaging model must unpack SNMP- specific security parameters from the message before calling a security model to authenticate and decrypt an incoming message, perform integrity checking, and translate model-specific security parameters into model-independent parameters. In the TMSM approach, the security -model specific parameters are not all carried in the SNMP message, and can be determined from the transport layer by the transport mapping, before the message processing begins. [todo] For outgoing messages, it is necessary to have an MPSP because it is the MPSP that actually creates the message from it scomponent parts. Does the MPSP need to know the transport address or the actual transport security capabilities, or can this be handled in the TMSP, given the model-independent (and message-version-independent) parameters? Are there any security services provided by the MPSP for an outgoing message? [todo] For incoming messages, is there security functionality that can only be handled after the message version is known, such as the comparison of transport security capabilities and msgFlags? Does that functionality need to know the transport address and session or just the model-independent security parameters (securityName, model, level)? Are there any SNMP-specific parameters that need to be unpacked from the message for MPSP handling? msgFlags, securityLevel, etc.? The RFC3411 architecture has no ASI parameters for passing security information between the transport mapping and the dispatcher, and Harrington & Schoenwaelder Expires November 27, 2005 [Page 12] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 between the dispatcher and the message processing model. If there is a need to have an MPSP called from the message processing model to, for example, verify that msgFlags and the transport security are consistent, then it will be necessary to pass the model-independent security parameters from the TPSP through to the MPSP. There are four approaches that could be used for passing information between the TMSP and an MPSP. 1. we could define an ASI to supplement the existing ASIs, or 2. the TMSM could add a header to encapsulate the SNMP message, 3. the TMSM could utilize fields already defined in the existing SNMPv3 message, or 4. the TMSM could pass the information in an implementation-specific cache or via a MIB module. 3.4.1 Define an Abstract Service Iinterface Abstract service interfaces [RFC3411] are defined by a set of primitives that specify the services provided and the abstract data elements that are to be passed when the services are invoked. Defining additional ASIs to pass the security and transport information from the transport mapping to a messaging security model has the advantage of being consistent with existing RFC3411/3412 practice, and helps to ensure that any TMSM proposals pass the necessary data, and do not cause side effects by creating model- specific dependencies between itself and other models or other subsystems other than those that are clearly defined by an ASI. 3.4.2 Using an encapsulating header A header could encapsulate the SNMP message to pass necessary information from the TMSP to the dispatcher and then to a messaging security model. The message header would be included in the wholeMessage ASI parameter, and would be removed by a corresponding messaging model. This would imply the (one and only) messaging dispatcher would need to be modified to determine which SNMP message version was involved, and a new message processing model would need to be developed that knew how to extract the header from the message and pass it to the MPSP. 3.4.3 Modifying Existing Fields in an SNMP Message [RFC3412] describes the SNMPv3 message, which contains fields to pass security related parameters. The TMSM could use these fields in an SNMPv3 message, or comparable fields in other message formats to pass information between transport mapping security models in different SNMP engines, and to pass information between a transport mapping security model and a corresponding messaging security model. Harrington & Schoenwaelder Expires November 27, 2005 [Page 13] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 If the fields in an incoming SNMPv3 message are changed by the TMSP before passing it to the MPSP, then the TMSP will need to decode the ASN.1 message, modify the fields, and re-encode the message in ASN.1 before passing the message on to the message dispatcher or to the transport layer. This would require an intimate knowledge of the message format and message versions so the TMSP knew which fields could be modified. This would seriously violate the modularity of the architecture. 3.4.4 Using a cache A cache mechanism could be used, into which the TMSP puts information about the security applied to an incoming message, and an MPSP extracts that information from the cache. Given that there may be multiple TM-security caches, a cache ID would need to be passed through an ASI so the MPSP knows which cache of information to consult. The cache reference could be thought of as an additional parameter in the ASIs between the transport mapping and the messaging security model. The RFC3411 ASIs would not need to be changed since the SNMPv3 WG expected that additional parameters could be passed for value-add features of specific implementations. This approach does create dependencies between a model-specific TPSP and a corresponding specific MPSP. If a TMSM-model-independent ASI parameter is passed, this approach would be consistent with the securityStateReference cache already being passed around in the ASI. This document will describe a cache-based approach. 3.5 Architectural Requirements for Access Control 3.5.1 securityName Binding For SNMP access control to function properly, the security mechanism must establish a security model identifier, a securityLevel, and a securityName, which is the security model independent identifier for a principal. The SNMPv3 message processing architecture subsystem relies on a security model, such as USM, to play a role in security that goes beyond protecting the message - it provides a mapping between the USM-specific principal to a security-model independent securityName which can be used for subsequent processing, such as for access control. The TMSM is a two-stage security model, with a transport mapping security process (TMSP) and a message processing security process (MPSP). Depending on the design of the specific TMSM model, i.e. Harrington & Schoenwaelder Expires November 27, 2005 [Page 14] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 which transport layer protocol is used, different features might be provided by the TMSP or by the MPSP. For example, the translation from a mechanism-specific authenticated identity to a securityName might be done by the TMSP or by the MPSP. [todo] It may be possible to define a consistent division of stages regardless of the transport layer protocol used, and a consistent division of functionality would be preferred. The SNMP architecture distinguishes between messages with no authentication and no privacy (noAuthNoPriv), authentication without privacy (authNoPriv) and authentication with privacy (authPriv). Hence, the authentication of a transport layer identity plays an important role and must be considered by any TMSM, and user authentication must be available via the transport layer security protocol. If the type of authentication provided by the transport layer (e.g. host-based or anonymous) is considered adequate to secure and/or encrypt the message, but inadequate to provide the desired granularity of access control (e.g. user-based), a second authentication, e.g. one provided by a AAA server, may be used to provide the authentication identity which is bound to the securityName. This approach would require a good analysis of the potential for man-in-the-middle attacks or masquerade possibilities. 3.5.2 Separation of Authentication and Authorization A TMSM security model should take care to not violate the separation of authentication and authorization in the RFC3411 architecture.. The isAccessAllowed() primitive is used for passing security-model independent parameters between the subsystems of the architecture. Mapping of (securityModel, securityName) to an access control policy should be handled within the access control subsystem, not the security subsystem, to be consistent with the modularity of the RFC3411 architecture. This separation was a deliberate decision of the SNMPv3 WG, to allow support for authentication protocols which did not provide authorization capabilities, and to support authorization schemes, such as VACM, that do not perform their own authentication. An authorization model MAY require authentication by certain securityModels and a minimum securityLevel to allow access to the data. TMSM is an enhancement for the SNMPv3 privacy and authentication provisions, but it is not a significant improvement for the authorization needs of SNMPv3. TMSM provides all the model- Harrington & Schoenwaelder Expires November 27, 2005 [Page 15] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 independent parameters for the isAccessAllowed() primitive [RFC3411]. TMSM does not specify how the securityModel and securityName could be dynamically mapped to a VACM-style groupName. The mapping of (securityModel, securityName) to a groupName is a VACM-specific mechanism for naming an access control policy, and for tying the named policy to the addressing capabilities of the data modeling language (e.g. SMIv2), the operations supported, and other factors. Providing a binding outside the Access Control subsystem might create dependencies that could make it harder to develop alternate models of access control, such as one built on UNIX groups, Windows domains, XML hierarchies, or task-based controls. The preferred approach is to pass the model-independent security parameters via the isAccessAllowed() ASI, and perform the mapping within the access control model. To provide support for protocols which simultaneously send information for authentication and authorization, such as RADIUS, model-specific authorization information MAY be cached or otherwise made available to the access control subsystem, e.g. via a MIB table similar to the vacmSecurityToGroupTable, so the access control subsystem can create an approrpiate binding between the model- independent securityModel and securityName and a model-specific access control policy. This may be highly undesirable, however, if it creates a dependency between a security model and an access control model, just as it is undesirable that the TMSM approach creates a dependency between a TMSP and an MPSP. 4. Integration with the SNMPv3 message format TMSM proposals can use the SNMPv3 message format, defined in RFC3412, section 6. This seection discusses how the fields could be reused. 4.1 msgVersion For proposals that reuse the SNMPv3 message format, this field should contain the value 3. 4.2 msgGlobalData msgID and msgMaxSize are used identically for the TMSM models as for the USM model. msgSecurityModel should be set to a value from the SnmpSecurityModel enumeration [RFC3411] to identify the specific TMSM model. Each standards-track TMSM model should have an enumeration assigned by IANA. Each enterprise-specific security model should have an enumeration assigned following instructions in the description of the Harrington & Schoenwaelder Expires November 27, 2005 [Page 16] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 SnmpSecurityModel TEXTUAL-CONVENTION from RFC3411. msgSecurityParameters would carry security information required for message security processing. It is unclear whether this field would be useful or what parameters would be carried to support security, since message security is provided by an external process, and msgSecurityParameters are not used by the access control subsystem. RFC3412 defines two primitives, generateRequestMsg() and processIncomingMsg() which require the specification of an authoritative SNMP entity. [todo] We need to discuss what the meaning of authoritative would be in a TMSM environment, whether the specific services provided in USM security from msgSecurityParameters still are needed, and how the Message Processing model provides this information to the security model via generateRequestMsg() and processIncomingMsg() primitives. RFC3412 specifies that "The data in the msgSecurityParameters field is used exclusively by the Security Model, and the contents and format of the data is defined by the Security Model. This OCTET STRING is not interpreted by the v3MP, but is passed to the local implementation of the Security Model indicated by the msgSecurityModel field in the message." msgFlags have the same values for the TMSM models as for the USM model. "The authFlag and privFlag fields indicate the securityLevel that was applied to the message before it was sent on the wire." 4.3 securityLevel and msgFlags For an outgoing message, msgFlags is the requested security for the message; if a TMSM cannot provide the requested securityLevel, the model MUST describe a standard behavior that is followed for that situation. If the TMSM cannot provide at least the requested level of security, the TMSM MUST discard the request and SHOULD notify the message processing model that the request failed. [dbh: how is yet to be determined, and may be model-specific or implementation-specific.] For an outgoing message, if the TMSM is able to provide stronger than requested security, that may be acceptable. The transport layer protocol would need to indicate to the receiver what security has been applied to the actual message. To avoid the need to mess with the ASN.1 encoding, the SNMPv3 message carries the requested msgFlags, not the actual securityLevel applied to the message. If a message format other than SNMPv3 is used, then the new message may carry the more accurate securityLevel in the SNMP message. For an incoming message, the receiving TMSM knows what must be done to process the message based on the transport layer mechanisms. If the underlying transport security mechanisms for the receiver cannot Harrington & Schoenwaelder Expires November 27, 2005 [Page 17] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 provide the matching securityLevel, then the message should follow the standard behaviors for the transport security mechanism, or be discarded silently. Part of the responsibility of the TMSM is to ensure that the actual security provided by the underlying transport layer security mechanisms is configured to meet or exceed the securityLevel required by the msgFlags in the SNMP message. When the MPSP processes the incoming message, it should compare the msgFlags field to the securityLevel actually provided for the message by the transport layer security. If they differ, the MPSP should determine whether the changed securityLevel is acceptable. If not, it should discard the message. Depending on the model, the MPSP may issue a reportPDU with the XXXXXXX model-specific counter. 4.4 The tmStateReference for Passing Security Parameters A tmStateReference is used to pass data between the TMSP and the MPSP, similar to the securityStateReference described in RFC3412. This can be envisioned as being appended to the ASIs between the TM and the MP or as being passed in an encapsulating header. The TMSP may provide only some aspects of security, and leave some aspects to the MPSP. tmStateReference should be used to pass any parameters, in a model- and mechanism-specific format, that will be needed to coordinate the activities of the TMSP and MPSP, and the parameters subsequently passed in securityStateReference . For example, the TMSP may provide privacy and data integrity and authentication and authorization policy retrievals, or some subset of these features, depending on the features available in the transport mechanisms. A field in tmStateReference should identify which services were provided for each received message by the TMSP, the securityLevel applied to the received message, the model-specific security identity, the session identifier for session based transport security, and so on. 4.5 securityStateReference Cached Security Data From RFC3411: "For each message received, the Security Model caches the state information such that a Response message can be generated using the same security information, even if the Local Configuration Datastore is altered between the time of the incoming request and the outgoing response. A Message Processing Model has the responsibility for explicitly releasing the cached data if such data is no longer needed. To enable this, an abstract securityStateReference data element is passed from the Security Model to the Message Processing Model. The Harrington & Schoenwaelder Expires November 27, 2005 [Page 18] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 cached security data may be implicitly released via the generation of a response, or explicitly released by using the stateRelease primitive, as described in RFC3411 section 4.5.1." For the TMSM approach, the TMSP may need to provide information to the message processing model, such as the security-model-independent securityName, securityLevel, and securityModel parameters, and for responses, the messaging model may need to pass the parameters back to the TMSP. To differentiate what information needs to be provided to the message processing model by the TMSP, and vice-versa, this document will differentiate the tmStateReference provide by the TMSP from the securityStateReference provided by the MPSP. An implementation MAY use one cache and one reference to serve both functions, but an implementor must be aware of the cache-release issues to prevent the cache from being released before the transport mapping has had an opportunity to extract the information it needs. 4.5.1 Prepare an Outgoing SNMP Message Following RFC3412, section 7.1, the SNMPv3 message processing model uses the generateResponseMsg() or generateRequestMsg() primitives, to call the MPSP. The message processing model, or the MPSP it calls, may need to put information into the tmStateReference cache for use by the TMSP, such as: tmSecurityStateReference - the unique identifier for the cached information tmTransportDomain tmTransportAddress tmSecurityModel - an indicator of which mechanisms to use tmSecurityName - a model-specific identifier of the security principal tmSecurityLevel - an indicator of which security services are requested and may contain additional information such as tmSessionID tmSessionKey tmSessionMsgID According to RFC3411, section 4.1.1, the application provides the transportDomain and transportAddress to the PDU dispatcher via the sendPDU() primitive. If we permit multiple sessions per transportAddress, then we would need to define how session identifiers get passed from the application to the PDU dispatcher (and then to the MP model). The SNMP over TCP Transport Mapping document [RFC3430] says that TCP connections can be recreated dynamically or kept for future use and actually leaves all that to the transport mapping. Harrington & Schoenwaelder Expires November 27, 2005 [Page 19] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 [todo] we might define a new transportDomain and transportAddress, which includes the address and session identifier. For situations where a session has not yet been established, we could pass a 0x0000 session identifier (or whatever) to indicate that a session should be established. We might have a MIB module that records the session information for subsequent use by the applications and other subsytems, or it might be passed in the tmStateReference cache. For notifications, I assume the SNMPv3 notification tables would be a place to find the address, but I'm not sure how to identify the presumably-dynamic session identifiers. The MIB module could identify whether the session was initiated by the remote engine or initiated by the current engine, and possibly assigned a purpose (incoming request/response or outgoing notifications). First we need to decide whether to handle notifications and requests in one or two (or more) sessions, which might depend on the transport protocol we choose (the same problem netconf faced). 4.5.2 Prepare Data Elements from an Incoming SNMP Message For an incoming message, the TMSP will need to put information from the transport mechanisms used into the tmStateReference so the MPSP can extract the information and add it conceptually to the securityStateReference. The tmStateReference cache will likely contain at least the following information: tmStateReference - a unique identifier for the cached information tmSecurityStateReference - the unique identifier for the cached information tmTransportDomain tmTransportAddress tmSecurityModel - an indicator of which mechanisms to use tmSecurityName - a model-specific identifier of the security principal tmSecurityLevel - an indicator of which security services are requested tmAuthProtocol tmPrivProtocol and may contain additional information such as tmSessionID tmSessionKey tmSessionMsgID 4.6 Notifications For notifications, if the cache has been released and then session Harrington & Schoenwaelder Expires November 27, 2005 [Page 20] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 closed, then the MPSP will request the TMSP to establish a session, populate the cache, and pass the securityStateReference to the MPSP. [todo] We need to determine what state needs to be saved here. 5. Transport Mapping Security Model Samples There are a number of standard protocols that could be proposed as possible solutions within the TMSM framework. Some factors should be considered when selecting a protocol for use within this framework. Using a protocol in a manner for which is was not designed has numerous problems. The advertised security characteristics of a protocol may depend on its being used as designed; when used in other ways, it may not deliver the expected security characteristics. It is recommended that any proposed model include a discussion of the applicability statement of the protocols to be used. 5.1 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]. 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 TLS. The TLS TMSP MUST provide authentication if auth is requested in the securityLevel of the SNMP message request (RFC3412 4.1.1). The 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 TLS TM-security model MUST support the TLS Handshake Protocol with mutual authentication. 5.1.1 tmStateReference for TLS Upon establishment of a 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 Harrington & Schoenwaelder Expires November 27, 2005 [Page 21] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 tmSecurityStateReference tmTransportDomain =3D TCP/IPv4 tmTransportAddress =3D x.x.x.x:y tmSecurityModel - TLS TMSM tmSecurityName =3D "dbharrington" tmSecurityLevel =3D "authPriv" tmAuthProtocol =3D Handshake MD5 tmPrivProtocol =3D Handshake DES tmSessionID =3D Handshake session identifier tmSessionKey =3D Handshake peer certificate tmSessionMasterSecret =3D master secret tmSessionParameters =3D compression method, cipher spec, is- resumable 5.1.2 MPSP for TLS TM-Security Model messageProcessingModel =3D SNMPv3 securityModel =3D TLS TMSM securityName =3D tmSecurityName securityLevel =3D msgSecurityLevel 5.1.3 MIB Module for TLS Security Each security model should use its own MIB module, rather than utilizing the USM MIB, to eliminate dependencies on a model that could be replaced some day. See RFC3411 section 4.1.1. The TLS MIB module needs to provide the mapping from model-specific identity to a model independent securityName. [todo] Module needs to be worked out once things become stable... 5.2 DTLS/UDP Transport Mapping Security Model DTLS has been proposed as a UDP-based TLS. Transport Layer Security (TLS) [RFC2246] traditionally requires a connection-oriented transport and is usually used over TCP. Datagram Transport Layer Security (DTLS) [DTLS] provides security services equivalent to TLS for connection-less transports such as UDP. DTLS provides all the security services needed from an SNMP architectural point of view. Although it is possible to derive a securityName from the public key certificates (e.g. the subject field), this approach requires installing certificates on all SNMP entities, leading to a certificate management problem which does not integrate well with established AAA systems. [todo] why does this not integrate well with existing AAA systems? Harrington & Schoenwaelder Expires November 27, 2005 [Page 22] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 Another option is to run an authentication exchange which is integrated with TLS, such as Secure Remote Password with TLS [SRP- TLS]. A similar option would be to use Kerberos authentication with TLS as defined in [RFC2712]. It is important to stress that the authentication exchange must be integrated into the TLS mechanism to prevent man-in-the-middle attacks. While SASL [RFC2222] is often used on top of a TLS encrypted channel to authenticate users, this choice seems to be problematic until the mechanism to cryptographically bind SASL into the TLS mechanism has been defined. DTLS 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 DTLS. The DTLS TM-security model MUST provide authentication if auth is requested in the securityLevel of the SNMP message request (RFC3412 4.1.1). The 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 DTLS TM-security model MUST support the TLS Handshake Protocol with mutual authentication. 5.2.1 tmStateReference for DTLS Upon establishment of a DTLS 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 =3D UDP/IPv4 tmTransportAddress =3D x.x.x.x:y tmSecurityModel - DTLS TMSM tmSecurityName =3D "dbharrington" tmSecurityLevel =3D "authPriv" tmAuthProtocol =3D Handshake MD5 tmPrivProtocol =3D Handshake DES tmSessionID =3D Handshake session identifier tmSessionKey =3D Handshake peer certificate tmSessionMasterSecret =3D master secret tmSessionParameters =3D compression method, cipher spec, is- resumable Harrington & Schoenwaelder Expires November 27, 2005 [Page 23] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 tmSessionSequence =3D epoch, sequence [todo] Need to discuss to what extent DTLS is a reasonable choice for SNMP interactions. What is the status of the work to cryptographically bind SASL to DTLS? More details need to be worked out... 5.3 SASL Transport Mapping Security Model The Simple Authentication and Security Layer (SASL) [RFC2222] provides a hook for authentication and security mechanisms to be used in application protocols. SASL supports a number of authentication and security mechanisms, among them Kerberos via the GSSAPI mechanism. This sample will use DIGEST-MD5 because it supports authentication, integrity checking, and confidentiality. DIGEST-MD5 supports auth, auth with integrity, and auth with confidentiality. Since SNMPv3 assumes integrity checking is part of authentication, if msgFlags is set to authNoPriv, the qop-value should be set to auth-int; if msgFlags is authPriv, then qop-value should be auth-conf. Realm is optional, but can be utilized by the securityModel if desired. SNMP does not use this value, but a TMSM could map the realm into SNMP processing in various ways. For example, realm and username could be concatenated to be the securityName value, e.g. helpdesk::username", or the realm could be used to specify a groupname to use in the VACM access control. This would be similar to having the securityName-to-group mapping done by the external AAA server. 5.3.1 tmStateReference for SASL DIGEST-MD5 The tmStateReference cache: tmStateReference tmSecurityStateReference tmTransportDomain =3D TCP/IPv4 tmTransportAddress =3D x.x.x.x:y tmSecurityModel - SASL TMSM tmSecurityName =3D username tmSecurityLevel =3D [auth-conf] tmAuthProtocol =3D md5-sess Harrington & Schoenwaelder Expires November 27, 2005 [Page 24] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 tmPrivProtocol =3D 3des tmServicesProvided =3D mutual authentication, reauthentication, integrity, encryption tmParameters =3D "realm=3Dhelpdesk, serv-type=3DSNMP 6. Security Considerations This document describes an architectural approach and multiple proposed configurations that would permit SNMPv3 to utilize transport layer security services. Each section containing a proposal should discuss the security considerations of that approach. [todo] expand as needed. Perfect forward secrecy guarantees that compromise of long term secret keys does not result in disclosure of past session keys. It is considered desirable by some industry segements that TMSM security models should utilize transport layer security that addresses perfect forward secrecy at least for encryption keys. 7. Acknowledgments The authors would like to thank Ira McDonald, Ken Hornstein, and Nagendra Modadugu for their comments and suggestions. 8. References 8.1 Normative References [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message processing and Dispatching for SNMP", STD 62, RFC 3412, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3417] Presuhn (Editor), R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. Harrington & Schoenwaelder Expires November 27, 2005 [Page 25] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 [RFC3430] Schoenwaelder, J., "Simple Network Management Protocol (SNMP) over Transmission Control Protocol (TCP) Transport Mapping", RFC 3430, December 2002. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", STD 62, RFC RFC2222, October 1997. [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", ID draft-rescorla-dtls-01.txt, July 2004. 8.2 Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, October 1999. [SRP-TLS] Taylor, D., Wu, T., Mavroyanopoulos, M., and T. Perrin, "Using SRP for TLS Authentication", ID draft-ietf-tls-srp-08.txt, August 2004. [EUSM] Narayan, D., McCloghrie, K., Salowey, J., and C. Elliot, "External USM for SNMPv3", ID draft-kaushik-snmp-external-usm-00.txt, July 2004. [NETCONF] Enns, R., "NETCONF Configuration Protocol", ID draft-ietf-netconf-prot-04.txt, October 2004. [SSHauth] Lonvick, C., "SSH Authentication Protocol", ID draft-ietf-secsh-userauth-21.txt, June 2004. Harrington & Schoenwaelder Expires November 27, 2005 [Page 26] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 Authors' Addresses David Harrington Independent Harding Rd Portsmouth NH USA Phone: +1 603 436 8634 Email: dbharrington@comcast.net Juergen Schoenwaelder International University Bremen Campus Ring 1 28725 Bremen Germany Phone: +49 421 200-3587 Email: j.schoenwaelder@iu-bremen.de Appendix A. Questions about msgFlags: [todo] many of these questions can be resolved by deciding whether the TMSP or MPSP provides the service of comparing msgFlags (from inside the message) to actual capabilities of the transport layer security (external to the message). It may however be necessary to provide this service for two slightly different purposes depending on whether the message is outgoing (and may need to be checked by the TMSP when a new transport session might be created) or the message is incoming ( the capabilities of the transport layer session are already known, but msgFlags has not been unpacked yet at the TMSP, so the comparison must be done at the MPSP). Of course, we really only need to compare the authflag and the privflag, i.e. the securityLevel, so if we pass the securityLevel between the two stages, then they each have the info they need to do their respective comparisons. There have been a large number of questions about msgFlags in the TMSM approach, mostly concerning the msgFlags value and the actual security provided, and whether msgFlags can be used to initiate per- message or per-session security. A.1 msgFlags versus actual security Using IPSEC, SSH, or SSL/TLS to provide security services "below" the SNMP message, the use of securityName and securityLevel will differ from the USM/VACM approach to SNMP access control. VACM uses the Harrington & Schoenwaelder Expires November 27, 2005 [Page 27] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 "securityName" and the "securityLevel" to determine if access is allowed. With the SNMPv3 message and USM security model, both securityLevel and securityName are contained in every SNMPv3 message. Any proposal for a security model using IPSEC, SSH, or SSL/TLS needs to specify how this info is made available to the SNMPv3 message processing, and how it is used. One specific case to consider is the relationship between the msgFlags of an SNMPv3 message, and the actual services provided by the lower layer security. For example, if a session is set up with encryption, is the priv bit always (or never) set in the msgFlags field, and is the PDU never (or always) encrypted? Do msgFlags have to match the security services provided by the lower layer, or are the msgFlags ignored and the values from the lower layer used? Is the securityLevel looked at before the security model gets to it.? No. the security model has two parts - the TMSP and the MPSP. The securityLevel is looked at by the TMSP before it gets to the MPSP, but both are parts of the same security model. Would it be legal for the security model to ignore the incoming flags and change them before passing them back up? If it changed them, it wouldn't necessarily be ignoring them. The TMSP should pass both an actual securityLevel applied to the message, and the msgFlags in the SNMP message to the MPSP for consideration related to access control.. The msgFlags parameter in the SNMP message is never changed when processing an incoming message. Would it be legal for the security model to ignore the outgoing flags and change them before passing them out? no; because the two stages are parts of the same security model, either the MPSP should recognize that a securityLevel cannot be met or exceeded, and reject the message during the message-build phase, or the TMSP should determine if it is possible to honor the request. It is possible to apply an increased securityLevel for an outgoing request, but the procedure to do so must be spelled out clearly in the model design. The security model MUST check the incoming security level flags to make sure they matched the transport session setup. and if not drop the message. Yes, mostly. Depending on the model, either the TMSP or the MPSP MUST verify that the actual processing met or exceeded the securityLevel requested by the msgFlags and that it is acceptable to the specific-model processing (or operator configuration) for this different securityLevel to be applied to the message. This is also true (especially) for outgoing messages. You might legally be able to have a authNoPriv message that is actually encrypted via the transport (but not the other way around of course). Yes, a TMSM could define that as the behavior (or Harrington & Schoenwaelder Expires November 27, 2005 [Page 28] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 permit an operator to specify that is acceptable behavior) when a requested securityLevel cannot be provided, but a stronger securityLevel can be provided. A.2 Message security versus session security For SBSM, and for many TMSM models, securityName is specified during session setup, and associated with the session identifier. Is it possible for the request (and notification) originator to specify per message auth and encryption services, or are they are "fixed" by the transport/session model? If a session is created as 'authPriv', then keys for encryption would still be negotiated once at the beginning of the session. But if a message is presented to the session with a security level of authNoPriv, then that message could simply be authenticated and not encrypted. Wouldn't that also have some security benefit, in that it reduces the encrypted data available to an attacker gathering packets to try and discover the encryption keys? Some SNMP entities are resource-constrained. Adding sessions increases the need for resources, we shouldn't require two sessions when one can suffice. 2 bytes per session structure and a compare or two is much less of a resource burden than two separate sessions. It's not just about CPU power of the device but the percentage of CPU cycles that are spent on network management. There isn't much value in using encryption for a performance management system polling PEs for performance data on thousands of interfaces every ten minutes,it just adds significant overhead to processing of the packet. Using an encrypted TLS channel for everything may not work for use cases in performance management wherein we collect massive amounts of non sensitive data at periodic intervals. Each SNMP "session" would have to negotiate two separate protection channels (authPriv and authNoPriv) and for every packet the SNMP engine will use the appropriate channel based on the desired securityLevel. If the underlying transport layer security was configurable on a per-message basis, a TMSM could have a MIB module with configurable maxSecurityLevel and a minSecurityLevel objects to identify the range of possible levels, and not all messages sent via that session are of the same level. A session's maxSecurityLevel would identify the maximum security it could provide, and a session created with a minSecurityLevel of authPriv would reject an attempt to send an authNoPriv message. Harrington & Schoenwaelder Expires November 27, 2005 [Page 29] =0C Internet-Draft SNMP Transport Mapping Security Model May 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Harrington & Schoenwaelder Expires November 27, 2005 [Page 30] =0C ------=_NextPart_000_02EF_01C561E7.2B8715A0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms ------=_NextPart_000_02EF_01C561E7.2B8715A0-- From isms-bounces@lists.ietf.org Thu May 26 16:13:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbOhf-0004yC-1v; Thu, 26 May 2005 16:11:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbOhe-0004y2-0y for isms@megatron.ietf.org; Thu, 26 May 2005 16:11: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 QAA06470 for ; Thu, 26 May 2005 16:11:35 -0400 (EDT) Message-Id: <200505262011.QAA06470@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbP0H-0004o6-DW for isms@ietf.org; Thu, 26 May 2005 16:30:54 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005052620112601100ot47he>; Thu, 26 May 2005 20:11:26 +0000 From: "David B Harrington" To: Date: Thu, 26 May 2005 16:11:22 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_034B_01C5620D.8FEF51D0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcViLfrCLH6mpKYHRWCcQFdxUQj2LwAAQZjA X-Spam-Score: 0.1 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: Subject: [Isms] FW: I-D ACTION:draft-schoenw-snmp-tlsm-02.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_034B_01C5620D.8FEF51D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, May 26, 2005 3:48 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-schoenw-snmp-tlsm-02.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Transport Mapping Security Model > (TMSM) for the > Simple Network Management Protocol > version 3 (SNMPv3) > Author(s) : D. Harrington, J. Schoenwaelder > Filename : draft-schoenw-snmp-tlsm-02.txt > Pages : 30 > Date : 2005-5-26 > > This document describes a Transport Mapping Security Model (TMSM) for > the Simple Network Management Protocol (SNMP) architecture > defined in > RFC3411. At this stage, this document describes a framework, not a > protocol. It does not provide a complete solution - it rather > identifies and discusses some key aspects that need discussion and > future work. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-schoenw-snmp-tlsm-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-schoenw-snmp-tlsm-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ------=_NextPart_000_034B_01C5620D.8FEF51D0 Content-Type: Message/External-body; name="ATT00820.dat" Content-Disposition: attachment; filename="ATT00820.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-5-26161921.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-schoenw-snmp-tlsm-02.txt ------=_NextPart_000_034B_01C5620D.8FEF51D0 Content-Type: Message/External-body; name="draft-schoenw-snmp-tlsm-02.txt" Content-Disposition: attachment; filename="draft-schoenw-snmp-tlsm-02.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-5-26161921.I-D@ietf.org> ------=_NextPart_000_034B_01C5620D.8FEF51D0 Content-Type: text/plain; name="ATT00823.txt" Content-Disposition: attachment; filename="ATT00823.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_034B_01C5620D.8FEF51D0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms ------=_NextPart_000_034B_01C5620D.8FEF51D0-- From isms-bounces@lists.ietf.org Mon May 30 09:31:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DckMX-000493-NO; Mon, 30 May 2005 09:31:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbU78-0004bG-AC for isms@megatron.ietf.org; Thu, 26 May 2005 21:58:19 -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 VAA02946 for ; Thu, 26 May 2005 21:58:16 -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 1DbUPp-0004qT-6Z for isms@ietf.org; Thu, 26 May 2005 22:17:38 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 0EC2FE0063; Thu, 26 May 2005 21:58:09 -0400 (EDT) To: Tom Petch Subject: Re: [Isms] TLS / SSH scalability concerns References: <3DEC199BD7489643817ECA151F7C592901220891@pysmsx401.amr.corp.intel.com> <6.2.0.14.0.20050512131355.039ae338@email.cisco.com> <20050512210958.GA1254@boskop.local> <01fa01c55ac6$c08b3460$0601a8c0@pc6> From: Sam Hartman Date: Thu, 26 May 2005 21:58:09 -0400 In-Reply-To: <01fa01c55ac6$c08b3460$0601a8c0@pc6> (Tom Petch's message of "Tue, 17 May 2005 11:40:06 +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 X-Mailman-Approved-At: Mon, 30 May 2005 09:31:24 -0400 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> There is an assumption buried in this thread that I would Tom> challenge, namely that all SNMP sessions will be the same and Tom> will be equally secure. From a security standpoint alone, I Tom> think this wrong. The more a security technology is used, Tom> the less secure it is, Long term keys are sometimes valuable to protect. For example I don't use signed mail except when I need to because keeping my signing key available in a way taht would be useful for sending all my mail would increase the probability that the key would be compromised. Similarly you might want to protect the key you use for sets to the OrbitalAdjustment MIB on your satellite more than you protect the key you use to read the IFTable. However limiting the use of confidentiality and integrity keys in an encapsulation security mechanism is unlikely to improve the security of anything. Remember that you generate a fresh key for each session. Also, remember that we typically design AES-based symmetric security systems to allow a key to be used for 2^64 blocks (2^64*16 bytes). There are a few ways you could reasonably design things that would only give you 2^32 blocks on each session key. But the general thing to take away is that the traffic encryption for encapsulation is likely to support as much use of security as you need. If you exceed some lifetime then generating a new key is relatively easy. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 31 10:09:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd7R6-0007cn-UG; Tue, 31 May 2005 10:09:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd7R5-0007ch-T4 for isms@megatron.ietf.org; Tue, 31 May 2005 10:09:39 -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 KAA12050 for ; Tue, 31 May 2005 10:09:34 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd7kd-0003Gx-OW for isms@ietf.org; Tue, 31 May 2005 10:29:53 -0400 Received: from pc6 (1Cust182.tnt101.lnd4.gbr.da.uu.net [213.116.50.182]) by astro.systems.pipex.net (Postfix) with SMTP id BAEF3E000156; Tue, 31 May 2005 15:09:16 +0100 (BST) Message-ID: <01e201c565e1$5355b520$0601a8c0@pc6> From: "Tom Petch" To: , References: <200505261536.LAA06809@ietf.org> Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt Date: Tue, 31 May 2005 15:03:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.9 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 Good stuff; when the question arose recently of what next, I did think a revision of this would be useful and here it is:-) A general question; what is the distinction you are making between ssh and tls, as in A solution based on this approach might also utilize a "transport application" that is actually another application operating at the application layer, such as SSH [SSHauth] which is your only reference to ssh and so might seem to be the reason why it gets no further coverage. I had seen ssh and tls as equal alternatives (assuming a reliable transport) and had expected them to be covered equally. The ietf architecture tends to bundle everything above tcp/udp as application and so in this sense, ssl, tls and ssh are all equally applications - or tranport layer extensions, depending on your point of view. Tom Petch ----- Original Message ----- From: "David B Harrington" To: Sent: Thursday, May 26, 2005 5:36 PM Subject: [Isms] draft-schoenw-snmp-tlsm-02.txt > Hi, > > I have requested the publication of draft-schoenw-snmp-tlsm-02.txt > Here is a copy of the file for WG perusal until it shows up in the I-D > directory. > > The primary changes have been in the text discussing the TMSM > framework. > Comments welcome, especially when accompanied by suggested text. > > We could use some help developing the sample mappings, especially from > those familiar with the transport security protocols. > > Thanks, > David Harrington > dbharrington@comcast.net > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 31 11:31:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd8hw-0003ug-BQ; Tue, 31 May 2005 11:31:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd8hv-0003uX-JO for isms@megatron.ietf.org; Tue, 31 May 2005 11:31:07 -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 LAA18780 for ; Tue, 31 May 2005 11:31:05 -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 1Dd91X-0004tJ-7B for isms@ietf.org; Tue, 31 May 2005 11:51:25 -0400 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO0053B2; 31 May 2005 11:31:39 -0400 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 31 May 2005 11:31:31 -0400 Received: from connotech.com (209.71.204.117) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG0053B1; 31 May 2005 11:31:26 -0400 Message-ID: <429C89F7.2090808@connotech.com> Date: Tue, 31 May 2005 11:59:51 -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: dbharrington@comcast.net Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt References: <200505261536.LAA06809@ietf.org> In-Reply-To: <200505261536.LAA06809@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.3 (+) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 David B Harrington wrote: > Hi, > > I have requested the publication of draft-schoenw-snmp-tlsm-02.txt A quick feedback about the draft draft-schoenw-snmp-tlsm-02.txt in the isms working group activities. My bias is towards a clarification of key management principles in support of SNMPv3 security improved with an isms solution. Basically, the SNMPv3 security is an application-level security concern. The usefulness of the draft draft-schoenw-snmp-tlsm-02.txt is to present a roadmap to adapt transport-layer security (or perhaps network- layer security since IPSEC is not excluded from the options) to the application-level security requirements. The key management principles are mainly stated in the draft by the following sentence: "The TLS TM-security model MUST support the TLS Handshake Protocol with mutual authentication." Such mutual authentication requires provisioning of keys in the systems where the SNMPv3 engine resides, and this is where AAA infrastructure reuse comes into play (hinted by isms charter). This limits the available options for transport-layer security protocols that fits the TMSM, which is productive because the surviving options would meet the requirements with greater certainty. However, the working group should watch the pitfalls of protocol usage diversion (using a protocol for a usage that was not envisioned in the first place). There is no explicit recognition of a trust relationship (and corresponding key material provisioning requirement) between an SNMPv3 engine and a owner organization, the one who would be authorized to set up authorization tables. The draft is explicit in not addressing authorization tables provisioning. However, provisioning VACM tables was seen as one of the major obstacles to SNMPv3 adoption (isms charter). Perhaps this other aspect of isms deserves another draft standard. The isms faces a demanding target of providing application-level SNMPv3 security with no incremental burden on initial provisioning of configuration material. Some progress is being made with this draft. Looks like good material. -- - 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 May 31 12:59:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdA5m-0000HB-5m; Tue, 31 May 2005 12:59:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdA5j-0000H6-V8 for isms@megatron.ietf.org; Tue, 31 May 2005 12:59:48 -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 MAA25438 for ; Tue, 31 May 2005 12:59:45 -0400 (EDT) Message-Id: <200505311659.MAA25438@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdAPN-0006hH-NA for isms@ietf.org; Tue, 31 May 2005 13:20:06 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc13) with SMTP id <2005053116593701600re4q8e>; Tue, 31 May 2005 16:59:37 +0000 From: "David B Harrington" To: "'Tom Petch'" , Subject: RE: [Isms] draft-schoenw-snmp-tlsm-02.txt Date: Tue, 31 May 2005 12:59:31 -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: <01e201c565e1$5355b520$0601a8c0@pc6> Thread-Index: AcVl6lkCC5FZS2mWSO2cJrX+0OwQRAAEfXCg X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 Tom, TLS is "transport layer security", so it appears to me to be categorized as being an extension of the transport layer. But I could be wrong. SSH, SASL, BEEP, and other security-related protocols that are often layered atop TLS seem to be application layer protocols. I would be happy to modify the document to reflect the official categories. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Tuesday, May 31, 2005 9:04 AM > To: dbharrington@comcast.net; isms@ietf.org > Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt > > Good stuff; when the question arose recently of what next, I > did think a > revision of this would be useful and here it is:-) > > A general question; what is the distinction you are making > between ssh and tls, > as in > > A solution based on this approach might also > utilize a "transport application" that is actually another > application operating at the application layer, such as > SSH [SSHauth] > > which is your only reference to ssh and so might seem to be > the reason why it > gets no further coverage. I had seen ssh and tls as equal > alternatives > (assuming a reliable transport) and had expected them to be > covered equally. > The ietf architecture tends to bundle everything above > tcp/udp as application > and so in this sense, ssl, tls and ssh are all equally > applications - or > tranport layer extensions, depending on your point of view. > > Tom Petch > > ----- Original Message ----- > From: "David B Harrington" > To: > Sent: Thursday, May 26, 2005 5:36 PM > Subject: [Isms] draft-schoenw-snmp-tlsm-02.txt > > > > Hi, > > > > I have requested the publication of draft-schoenw-snmp-tlsm-02.txt > > Here is a copy of the file for WG perusal until it shows up > in the I-D > > directory. > > > > The primary changes have been in the text discussing the TMSM > > framework. > > Comments welcome, especially when accompanied by suggested text. > > > > We could use some help developing the sample mappings, > especially from > > those familiar with the transport security protocols. > > > > Thanks, > > David Harrington > > dbharrington@comcast.net > > > > > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 31 13:06:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdAC4-0001Hl-De; Tue, 31 May 2005 13:06:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdAC2-0001Hg-BS for isms@megatron.ietf.org; Tue, 31 May 2005 13:06:18 -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 NAA25900 for ; Tue, 31 May 2005 13:06:15 -0400 (EDT) Received: from iaf79.i.pppool.de ([85.73.175.121] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdAVh-0006oo-0v for isms@ietf.org; Tue, 31 May 2005 13:26:37 -0400 Received: by boskop.local (Postfix, from userid 501) id 7A31330C39E; Tue, 31 May 2005 17:57:52 +0200 (CEST) Date: Tue, 31 May 2005 17:57:52 +0200 From: Juergen Schoenwaelder To: Thierry Moreau Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt Message-ID: <20050531155752.GB27171@boskop.local> Mail-Followup-To: Thierry Moreau , dbharrington@comcast.net, isms@ietf.org References: <200505261536.LAA06809@ietf.org> <429C89F7.2090808@connotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <429C89F7.2090808@connotech.com> User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: dbharrington@comcast.net, 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:59:51AM -0400, Thierry Moreau wrote: > There is no explicit recognition of a trust > relationship (and corresponding key material > provisioning requirement) between an SNMPv3 engine and > a owner organization, the one who would be authorized > to set up authorization tables. The draft is explicit > in not addressing authorization tables provisioning. > However, provisioning VACM tables was seen as one of > the major obstacles to SNMPv3 adoption (isms charter). > Perhaps this other aspect of isms deserves another > draft standard. The charter identifies two major problems in the first paragraph and then starts the second paragraph saying that ISMS focusses on the first of the two identified problems. So VACM provisioning according to my reading of the charter not in scope of this work. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 31 13:09:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdAFK-0001cG-5b; Tue, 31 May 2005 13:09:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdAFI-0001cB-Ot for isms@megatron.ietf.org; Tue, 31 May 2005 13:09:40 -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 NAA26053 for ; Tue, 31 May 2005 13:09:38 -0400 (EDT) Received: from iaf79.i.pppool.de ([85.73.175.121] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdAYx-0006s7-HG for isms@ietf.org; Tue, 31 May 2005 13:29:59 -0400 Received: by boskop.local (Postfix, from userid 501) id CF59C30C416; Tue, 31 May 2005 19:09:30 +0200 (CEST) Date: Tue, 31 May 2005 19:09:30 +0200 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt Message-ID: <20050531170930.GA27363@boskop.local> Mail-Followup-To: David B Harrington , 'Tom Petch' , isms@ietf.org References: <01e201c565e1$5355b520$0601a8c0@pc6> <200505311659.MAA25438@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505311659.MAA25438@ietf.org> User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Tue, May 31, 2005 at 12:59:31PM -0400, David B Harrington wrote: > SSH, SASL, BEEP, and other security-related protocols that are often > layered atop TLS seem to be application layer protocols. SSH layered atop of TLS??? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 31 13:18:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdAOE-0002io-HC; Tue, 31 May 2005 13:18:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdAOD-0002ie-2b for isms@megatron.ietf.org; Tue, 31 May 2005 13:18:53 -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 NAA26752 for ; Tue, 31 May 2005 13:18:50 -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 1DdAhq-00074W-UN for isms@ietf.org; Tue, 31 May 2005 13:39:12 -0400 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO0054E4; 31 May 2005 13:19:25 -0400 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 31 May 2005 13:19:11 -0400 Received: from connotech.com (209.71.204.117) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG0054E3; 31 May 2005 13:19:10 -0400 Message-ID: <429CA338.50304@connotech.com> Date: Tue, 31 May 2005 13:47:36 -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: j.schoenwaelder@iu-bremen.de Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt References: <200505261536.LAA06809@ietf.org> <429C89F7.2090808@connotech.com> <20050531155752.GB27171@boskop.local> In-Reply-To: <20050531155752.GB27171@boskop.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.3 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit 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 Juergen Schoenwaelder wrote: > The charter identifies two major problems in the first paragraph > and then starts the second paragraph saying that ISMS focusses > on the first of the two identified problems. So VACM provisioning > according to my reading of the charter not in scope of this work. Your reading of the charter seems appropriate. My apologies for any inconvenience from my incorrect reading. -- - 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 May 31 13:21:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdAQn-0002xF-73; Tue, 31 May 2005 13:21:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdAQl-0002wy-T4 for isms@megatron.ietf.org; Tue, 31 May 2005 13:21:32 -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 NAA26970 for ; Tue, 31 May 2005 13:21:29 -0400 (EDT) Message-Id: <200505311721.NAA26970@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdAkL-00076x-9P for isms@ietf.org; Tue, 31 May 2005 13:41:47 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc13) with SMTP id <2005053117211701600rdne6e>; Tue, 31 May 2005 17:21:17 +0000 From: "David B Harrington" To: "'Thierry Moreau'" Subject: RE: [Isms] draft-schoenw-snmp-tlsm-02.txt Date: Tue, 31 May 2005 13:21:11 -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: <429C89F7.2090808@connotech.com> Thread-Index: AcVl9cBxsmELZP+bTwma4PmzLsD2wAADO8RA X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org 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 Thierry, The ISMS WG charter has recognized two synchronization problems - authentication and authorization. The charter limits our current scope to the authentication problem. The authorization problem will need to be solved in a separate effort, although solutions to the first might provide some means of interfacing to a solution of the second problem (preferably in a manner consistent with the RFC3411 architecture). TMSM provides an architecture for building security models that layer atop other security layers (or applications), such as TLS, SSH, SASL. The statement about the TLS TM-security model mutual authentication you quoted was explicit to a TLS-based solution, not all possible TMSM solutions. The MUST was requested by some, so I changed it from the original document; I'm not sure it will remain as currently written. So I would avoid extrapolating too much from that one sentence. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Thierry Moreau [mailto:thierry.moreau@connotech.com] > Sent: Tuesday, May 31, 2005 12:00 PM > To: dbharrington@comcast.net > Cc: isms@ietf.org > Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt > > > > David B Harrington wrote: > > Hi, > > > > I have requested the publication of draft-schoenw-snmp-tlsm-02.txt > > A quick feedback about the draft > draft-schoenw-snmp-tlsm-02.txt in the isms working > group activities. My bias is towards a clarification of > key management principles in support of SNMPv3 security > improved with an isms solution. > > Basically, the SNMPv3 security is an application-level > security concern. The usefulness of the draft > draft-schoenw-snmp-tlsm-02.txt is to present a roadmap > to adapt transport-layer security (or perhaps network- > layer security since IPSEC is not excluded from the > options) to the application-level security > requirements. > > The key management principles are mainly stated in the > draft by the following sentence: > "The TLS TM-security model MUST support the TLS > Handshake Protocol with mutual authentication." > Such mutual authentication requires provisioning of > keys in the systems where the SNMPv3 engine resides, > and this is where AAA infrastructure reuse comes into > play (hinted by isms charter). This limits the > available options for transport-layer security > protocols that fits the TMSM, which is productive > because the surviving options would meet the > requirements with greater certainty. However, the > working group should watch the pitfalls of protocol > usage diversion (using a protocol for a usage that was > not envisioned in the first place). > > There is no explicit recognition of a trust > relationship (and corresponding key material > provisioning requirement) between an SNMPv3 engine and > a owner organization, the one who would be authorized > to set up authorization tables. The draft is explicit > in not addressing authorization tables provisioning. > However, provisioning VACM tables was seen as one of > the major obstacles to SNMPv3 adoption (isms charter). > Perhaps this other aspect of isms deserves another > draft standard. > > The isms faces a demanding target of providing > application-level SNMPv3 security with no incremental > burden on initial provisioning of configuration > material. Some progress is being made with this draft. > Looks like good material. > > -- > > - 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 May 31 13:30:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdAZH-0004Hv-Um; Tue, 31 May 2005 13:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdAZF-0004Hq-Rd for isms@megatron.ietf.org; Tue, 31 May 2005 13:30:18 -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 NAA27711 for ; Tue, 31 May 2005 13:30:15 -0400 (EDT) Message-Id: <200505311730.NAA27711@ietf.org> Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdAst-0007MC-Nj for isms@ietf.org; Tue, 31 May 2005 13:50:36 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <2005053117300701400dkli6e>; Tue, 31 May 2005 17:30:07 +0000 From: "David B Harrington" To: Subject: RE: [Isms] draft-schoenw-snmp-tlsm-02.txt Date: Tue, 31 May 2005 13:30:00 -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: <20050531170930.GA27363@boskop.local> Thread-Index: AcVmA4MUtCVwWpemR9eGYzaTnXfvCQAAkSfA X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: isms@ietf.org 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 Whoops! David Harrington dbharrington@comcast.net > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Tuesday, May 31, 2005 1:10 PM > To: David B Harrington > Cc: 'Tom Petch'; isms@ietf.org > Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt > > On Tue, May 31, 2005 at 12:59:31PM -0400, David B Harrington wrote: > > > SSH, SASL, BEEP, and other security-related protocols that are often > > layered atop TLS seem to be application layer protocols. > > SSH layered atop of TLS??? > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue May 31 22:39:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdJ9B-0002N2-Ow; Tue, 31 May 2005 22:39:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdJ99-0002Mx-4T for isms@megatron.ietf.org; Tue, 31 May 2005 22:39:55 -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 WAA19543 for ; Tue, 31 May 2005 22:39: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 1DdJSs-0005CE-0E for isms@ietf.org; Tue, 31 May 2005 23:00:19 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id BE65FE0063; Tue, 31 May 2005 22:39:43 -0400 (EDT) To: dbharrington@comcast.net Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt References: <200505311659.MAA25438@ietf.org> From: Sam Hartman Date: Tue, 31 May 2005 22:39:43 -0400 In-Reply-To: <200505311659.MAA25438@ietf.org> (David B. Harrington's message of "Tue, 31 May 2005 12:59:31 -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: 7d33c50f3756db14428398e2bdedd581 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "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 From isms-bounces@lists.ietf.org Tue May 31 23:42:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdK7v-0003Ks-WD; Tue, 31 May 2005 23:42:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdK7u-0003Kn-Md for isms@megatron.ietf.org; Tue, 31 May 2005 23:42:42 -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 XAA23104 for ; Tue, 31 May 2005 23:42:40 -0400 (EDT) Message-Id: <200506010342.XAA23104@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdKRe-0008IX-2P for isms@ietf.org; Wed, 01 Jun 2005 00:03:07 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005060103423201100mh51ne>; Wed, 1 Jun 2005 03:42:32 +0000 From: "David B Harrington" To: "'Sam Hartman'" Subject: RE: [Isms] draft-schoenw-snmp-tlsm-02.txt Date: Tue, 31 May 2005 23:42:25 -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: Thread-Index: AcVmUzBiUmv9BWKEQ7aYjKfOH6ck/gAA670Q X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org 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 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