From owner-snmpv3@lists.tislabs.com Wed Aug 6 18:36:06 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08864 for ; Wed, 6 Aug 2003 18:36:05 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07084 Wed, 6 Aug 2003 17:34:04 -0400 (EDT) Message-ID: <008a01c35c63$7d89b3c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: References: <5B58696DB20B9140AD20E0685C573A6402992DC4@xch-nw-09.nw.nos.boeing.com> Subject: Re: Securing SNMPv3 via SSH tunnels Date: Wed, 6 Aug 2003 14:41:27 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Hi - > From: "Fleischman, Eric" > To: > Sent: Wednesday, August 06, 2003 8:42 AM > Subject: Securing SNMPv3 via SSH tunnels > > I am seeking to secure SNMPv3 communications (e.g., RFC 3414), > trying to protect against its well-known vulnerabilities such as spoofing. ... Although this discussion probably belongs on the snmpv3 WG mailing list, I'd appreciate a pointer to these "well-known vulnerabilities", since protection against spoofing (masquerade) is an explicit goal in section 1.1 of 3414. Randy From owner-snmpv3@lists.tislabs.com Thu Aug 7 15:10:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28054 for ; Thu, 7 Aug 2003 15:10:24 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11529 Thu, 7 Aug 2003 14:11:46 -0400 (EDT) Message-ID: <00c001c35d10$50a730a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Fleischman, Eric" Cc: "Uri Blumenthal" , "Wijnen, Bert \(Bert\)" , , "Eliot Lear" , "EXT-Weller, Michael K" , References: <5B58696DB20B9140AD20E0685C573A6402992DC9@xch-nw-09.nw.nos.boeing.com> Subject: Re: SNMPv3 security Date: Thu, 7 Aug 2003 11:18:34 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Hi - > From: "Fleischman, Eric" > To: "Randy Presuhn" > Cc: "Uri Blumenthal" ; "Wijnen, Bert (Bert)" ; ; "Eliot Lear" ; "EXT-Weller, Michael K" > Sent: Thursday, August 07, 2003 9:31 AM > Subject: RE: SNMPv3 security > > Thanks for your feedback, Randy. I concur with you that this belongs on the SNMPv3 list, but if it is moved > there, then I will have no access to what is being posted, due to the fact that I am not a list member. subscribing is not that painful, and the list administrator has, at least in my past experience, been very good about granting posting rights. > I disagree with your analysis paragraph below. Moving DES to AES will have almost no (zero) > impact upon the SNMPv3 system because it doesn't address SNMPv3's totally broken Session > Key approach. ??? Key lifetime is under control of the user / security administrator. If you want to update your keys every ten minutes, you can, though it doesn't address the more fundamental question of the strength of the crypto algorithm > All you are doing by transitioning from using DES to AES is perhaps delaying the bad guys a few > hours before these keys are broken. That's almost nothing -- a false sense of security that accomplishes little. You must know something about AES that I don't. Any references to back up this claim of relative lack of strength vis-a-vis DES? > The interrelationship of the keys means that breaking one key greatly eases the breaking of them all, > even if we are talking about dozens-of-remote-admins * thousands-of-SNMP-agents worth of keys, > as we are in our system. The whole thing can be rolled up fairly quickly by security professionals > because encryption in SNMPv3 is being applied in a barefoot manner. It sounds like you're assuming that the key localization algorithm is insufficiently one-way. I know there's been some speculation that MD5 might be inadequate for this purpose, but has anyone actually demonstrated it? In any case, I think Uri's AES i-d addresses this (at least earlier versions did). > The only way this can be remedied is not by doing minor tweaks of encryption algorithms > but rather by redesigning the security system to place it upon a solid footing. Session > Keys should have very short, finite lifetimes. Nice in theory, but brings other costs and other risks, like the possibility that session establishment will fail in highly stressed networks. > They should be established in real time for a predetermined time period by a Diffie-Hellman > variant (e.g., consider the Oakley Key Determination Protocol). [If this is too heavy, then > encrypt the session key with the localized key for that quorum or else look at the composite > key approaches that have been considered by the secure multicast and IPSec working groups.] Did you look at RFC 2786? I still challenge your original assertion that SNMPv3 USM (possibly with AES) is inadequate. All this speculation about other ways that it might have been done doesn't prove that any real problem exists. > This may mean that either you switch to TCP as your underlying transport or else you invent an > association of UDP packets having the same source-destination addresses within a > bounded timeframe quorum. [Note: using UDP makes things difficult, but no harder than > what one has to do at the IP Layer.] There should be no algorithmic relationship between > any keys -- each should be independent from the other. The decision to use key localization was made because implementation and deployment experience with various flavours of SNMPv2 showed that using totally independent keys scaled badly. The assertion that key localization presents a point of attack is based on the assumption that compromising a localized key would provide information that would be useful in deriving either the initial passphrase or some other localized key. As far as I know, no one has been able to justify such an assumption. > These keys should be distributable > via already existing key distribution systems (e.g., Kerberos, PKI), perhaps by using "seed > key values", or else composite keys. In addition, whatever you do at the SNMPv3 application > layer should be designed to work with security provisions at another layer. Sure, the architecture allows you to define other security models like these, but see the SNMPv3 WG archives for lots of reasons why one wouldn't want to mandate this. > This means leveraging either the IP Layer using IPSec or the Transport layer using TLS > or the application layer using SSH port forwarding (tunneling) -- or any or all of them -- > should be available to supplement SNMPv3's security provisions by SNMPv3's basic design. > That is, when a deployment (i.e., an end user) is feeling exposed, SNMP is in a > much better position offering many security options ranging from light-weight to > extremely heavy, rather than the current posture of saying "we only play by ourselves > so take it or leave it." It sounds like you've missed the point of RFC 3411. > --Eric > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Wednesday, August 06, 2003 5:33 PM > To: Fleischman, Eric > Subject: Re: SNMPv3 security > > > Hi - > >> From: "Fleischman, Eric" >> To: "Randy Presuhn" >> Sent: Wednesday, August 06, 2003 4:47 PM >> Subject: FW: SNMPv3 security >... > >> I'm sorry, Randy, but I didn't notice your request to be part of this discussion until after I had sent my reply >> (below) to Uri and Bert. >... > >Thanks. > >As a procedural matter, this *really* belongs on the snmpv3 WG mailing list. > >I prefer to avoid back-room discussions. FWIW, all the issues you raise have been >discussed in some form in that WG in the past. The important ones from my perspective >are the concern about cryptographic strength, which is addressed by Uri's AES I-D, >and the fact that key management is a pain. The latter is partially addressed by >RFC 2786, but initial key establishment for "headless" boxes is simply hard >to do well, and PKI doesn't make it any easier. > >Randy Randy From owner-snmpv3@lists.tislabs.com Thu Aug 7 17:20:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03444 for ; Thu, 7 Aug 2003 17:20:21 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA12092 Thu, 7 Aug 2003 16:22:20 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: SNMPv3 security Date: Thu, 7 Aug 2003 13:22:39 -0700 Message-ID: <5B58696DB20B9140AD20E0685C573A6402992DCA@xch-nw-09.nw.nos.boeing.com> Thread-Topic: SNMPv3 security Thread-Index: AcNdELVWXLqF7mq5Q7Cj/DXvXlydzwABJP+w From: "Fleischman, Eric" To: "Randy Presuhn" Cc: "Uri Blumenthal" , "Wijnen, Bert (Bert)" , , "Eliot Lear" , "EXT-Weller, Michael K" , X-OriginalArrivalTime: 07 Aug 2003 20:22:40.0118 (UTC) FILETIME=[A6426960:01C35D21] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA12067 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >??? Key lifetime is under control of the user / security administrator. If you want to update >your keys every ten minutes, you can, though it doesn't address the more fundamental >question of the strength of the crypto algorithm >From my knothole, the most important information I have conveyed is that one must have Session Keys with very short lifetimes in order to reduce the amount of available ciphertext that can be used for cryptanalysis. Because SNMPv3 keys have indefinitely long lifetimes, a great deal of relevant ciphertext accumulates. For SNMPv3, the cracker knows that any communication between the same source and destination IP addresses has a high degree of probability of using the same DES encryption key -- especially if the attacker has operational information about the types of systems (e.g., single user or multi-user) residing at each IP address, which is not difficult to obtain. Thus, the cracker has plenty of ciphertexts from which to apply cryptanalysis in order to break the DES encryption keys. Once the session key has been broken, then the attacker can concentrate on cracking the authentication keys, which are "the keys to the kingdom", especially because of the weak authenticati! on ! approach used by SNMPv3 (e.g., no capability for two factor authentication thus anybody knowing the authentication key can freely pretend to be that administrator). It is therefore essential that the Session Key have a short lifetime in order to reduce the amount of available ciphertext encrypted by the same key and to introduce doubts whether any two ciphertexts were encrypted by the same or different keys. This is the most fundamental defense available to us as SNMPv3 end users. Your statement above is disingenuous -- as I trust you knew when you wrote it. No user or security administrator can bear the overhead of redistributing tens of thousands of SNMPv3 passwords. They certainly can't regularly do this within an adequately short key lifetime quantum in order to make the current SNMPv3 approach begin to be viable. Egads!!! >> All you are doing by transitioning from using DES to AES is perhaps delaying the bad guys a few >> hours before these keys are broken. That's almost nothing -- a false sense of security that >>accomplishes little. >You must know something about AES that I don't. Any references to back up this claim >of relative lack of strength vis-a-vis DES? Randy, I am confident that you already know that TRIPLE-DES is usually stronger than DES and that AES with long keys is stronger than TRIPLE-DES. However, you seem to think that any of these algorithms is adequately strong to defeat cryptanalysis done by a security professional, even in environments with long key life and an abundance of ciphertext. I am not at liberty to discuss this type of issue with you. I realize that this may seem unfriendly or non-professional to you and I apologize for this perception. Rather, let's just recall together that communities exist who are not tremendously impressed with the strength of non-classified algorithms, particularly in environments with substantial amount of ciphertext available to the well-financed cracker. >> The interrelationship of the keys means that breaking one key greatly eases the breaking of them all, >> even if we are talking about dozens-of-remote-admins * thousands-of-SNMP-agents worth of keys, >> as we are in our system. The whole thing can be rolled up fairly quickly by security professionals >> because encryption in SNMPv3 is being applied in a barefoot manner. >It sounds like you're assuming that the key localization algorithm is insufficiently one-way. >I know there's been some speculation that MD5 might be inadequate for this purpose, >but has anyone actually demonstrated it? In any case, I think Uri's AES i-d addresses >this (at least earlier versions did). The current approach presumes that SHA-1 or MD5 hashes provide enough key randomization to thwart the underlying algorithmic relationship between these keys. I can understand why you may think this. However, if you spent some time figuring out how to break these keys, then a possibility exists that you perhaps may agree with me that this underlying relationship provides a helpful mechanism to exploit for breaking these keys, particularly with a great abundance of ciphertext to work with. >> The only way this can be remedied is not by doing minor tweaks of encryption algorithms >> but rather by redesigning the security system to place it upon a solid footing. Session >> Keys should have very short, finite lifetimes. >Nice in theory, but brings other costs and other risks, like >the possibility that session establishment will fail in highly >stressed networks. Yes, you are correct. I simplified a difficult problem. However, until SNMPv3 can have session keys with short lifetimes, the protocol is essentially unsecurable -- which is why I am currently seeking to secure SNMPv3 at a lower protocol layer (i.e., the beginning of this email thread). >The decision to use key localization was made because implementation and >deployment experience with various flavours of SNMPv2 showed that using >totally independent keys scaled badly. The assertion that key localization >presents a point of attack is based on the assumption that compromising a localized >key would provide information that would be useful in deriving either the initial >passphrase or some other localized key. As far as I know, no one has been able >to justify such an assumption. Yes, it is obvious that something had to be done to reduce the overhead burden of distributing two symmetric keys between each SNMP-agent and network-administrator pairing. SNMP adopted a creative solution to this problem. However, if the protocol were to be redesigned today, other solutions would be available, including the ones I mentioned in my email, which would offer greater protections and lower the existing administrative burden. For example, if SNMP were secured in a parallel manner as even one other IETF protocol, then the administrative burden for administrators supporting both protocols would be materially eased. The fact that the algorithmic relationship between the keys can be leveraged to break additional keys, once an original key has been broken, may or may not be evident to the readers of this email. Certainly, I am offering no proof, other than implying I have an idea for how to do so. However, this fact is far less important than fixing the primary weakness of the system, which is the lack of a viable session key mechanism, which exposes all the SNMPv3 keys to compromise, even if they hadn't had an underlying algorithmic relationship to leverage. >> These keys should be distributable >> via already existing key distribution systems (e.g., Kerberos, PKI), perhaps by using "seed >> key values", or else composite keys. In addition, whatever you do at the SNMPv3 application >> layer should be designed to work with security provisions at another layer. >Sure, the architecture allows you to define other security models like these, but >see the SNMPv3 WG archives for lots of reasons why one wouldn't want to mandate this. I am not telling your working group what algorithm or approach to use because these are weighty issues, far outside the scope of my posting. Rather, I am merely saying that the existing system is unsecurable unless supplemented by the security provisions of additional protocol layers. As you may recall, my original intent was not to question or debate SNMPv3 security at all, but rather to query the IETF list to see whether SSH port forwarding had been successfully used by others to partially secure SNMP. Has anybody on this list used SSH port forwarding for SNMP? If so, do you believe the approach to be viable or not? Was any other approach more successful? (Please respond directly to me because I am not yet a member of the snmpv3 list.) --Eric From owner-snmpv3@lists.tislabs.com Thu Aug 7 18:21:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06625 for ; Thu, 7 Aug 2003 18:21:06 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA12326 Thu, 7 Aug 2003 17:15:19 -0400 (EDT) Date: Thu, 7 Aug 2003 17:21:56 -0400 (EDT) From: David Spakes To: "Fleischman, Eric" cc: "EXT-Weller, Michael K" , Randy Presuhn , Uri Blumenthal , "Wijnen, Bert (Bert)" , bill@strahm.net, Eliot Lear , snmpv3@lists.tislabs.com Subject: RE: SNMPv3 security In-Reply-To: <5B58696DB20B9140AD20E0685C573A6402992DCA@xch-nw-09.nw.nos.boeing.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk On Thu, 7 Aug 2003, Fleischman, Eric wrote: > No user or security administrator can bear the overhead of > redistributing tens of thousands of SNMPv3 passwords. They certainly > can't regularly do this within an adequately short key lifetime > quantum in order to make the current SNMPv3 approach begin to be > viable. Egads!!! Hi Eric, SNMP Research has a policy-based configuration tool for SNMPv3 called Simple PolicyPro. It is part of a suite of applications called EnterPol (http://www.snmp.com/products/enterpol.html). Redistributing tens of thousands of SNMPv3 passwords on a regular basis is one of the design goals of Simple PolicyPro. Changing one user's password in the policy definition takes just a few mouse clicks and keystrokes in the GUI. A background process performs the necessary Set requests to the usmUserTable on all of the remote agents to which that policy is assigned. When a company has so many hosts, there's bound to be at least a few that are down or unreachable at any given point in time. Simple PolicyPro stores policy changes in a database so retries can be made over several days or longer if necessary--the behavior is configurable. Let me know if you would like a free evaluation copy. Regards, David Spakes ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- SNMPv3 is now... the Full Internet Management Framework (RFC 3410-3418) Are your management tools secure, open, flexible, and scalable? Rely on the proven experts when taking your next step From owner-snmpv3@lists.tislabs.com Thu Aug 7 18:39:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07193 for ; Thu, 7 Aug 2003 18:39:47 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA12438 Thu, 7 Aug 2003 17:41:30 -0400 (EDT) Date: Thu, 7 Aug 2003 14:40:14 -0700 (PDT) From: Michael Kirkham To: "Fleischman, Eric" cc: Randy Presuhn , Uri Blumenthal , "Wijnen, Bert (Bert)" , , Eliot Lear , "EXT-Weller, Michael K" , Subject: RE: SNMPv3 security In-Reply-To: <5B58696DB20B9140AD20E0685C573A6402992DCA@xch-nw-09.nw.nos.boeing.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk On Thu, 7 Aug 2003, Fleischman, Eric wrote: > It is therefore essential that the Session Key have a short lifetime in > order to reduce the amount of available ciphertext encrypted by the same > key and to introduce doubts whether any two ciphertexts were encrypted > by the same or different keys. This is the most fundamental defense > available to us as SNMPv3 end users. Not to argue either way, but are you taking into account the fact that each message is encrypted using a different initialization vector (derived from the static localized key and a salt that changes with each message)? (RFC 3414 section 8.1.1.1 for reference.) -- Michael Kirkham www.muonics.com From owner-snmpv3@lists.tislabs.com Thu Aug 7 20:12:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09244 for ; Thu, 7 Aug 2003 20:12:49 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12837 Thu, 7 Aug 2003 19:10:43 -0400 (EDT) Message-Id: <5.2.0.9.2.20030807160140.02942dc0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 07 Aug 2003 16:17:41 -0700 To: "Fleischman, Eric" From: "David T. Perkins" Subject: RE: SNMPv3 security Cc: snmpv3@lists.tislabs.com In-Reply-To: <5B58696DB20B9140AD20E0685C573A64025CBED7@xch-nw-09.nw.nos. boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA12834 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit HI, On the below (and all of this applies to USM, but not necessarily to other security models for SNMPv3): 1) A user's passphrase is not ever kept on the managed system (unless you want security to be easily compromised for the network)! 2) What is held in persistent storage on a managed system is auth and privacy keys. (And how these are protected is a local matter, and it better be good) 3) The keys don't have to be generated via the pass phrase to localized key algorithm! 4) Learning the SNMP engine ID of any system is not secured, and is a "normal" part of interacting with a managed system. There are no assumptions in the USM that an SNMP engine ID is sensitive info. But the critical part is that determining a user's pass phrase basically gives access to all devices managable by the user (as long as the keys have been created via the pass phrase to localized key algorithm) without any need for crypto breaking tools. (It's like stealing an ID card). >4) SNMP symmetric keys assembled from passwords >Section 2.6 of RFC 3414 states that the administrator's localized key, Kul, is created by that user's password plus the snmpEngineID for that specific SNMP engine (i.e., that SNMP agent). This result is then hashed by either MD5 or SHA-1 to create the localized key. (As such, this represents an improvement to the earlier algorithm that was previously described in RFC 2274. By the way, how can we know whether the remote systems are using the algorithm of 2274 or the one for 3414 to create the symmetric keys?) > >I haven't spent as much time with RFC 3414 as I have with RFC 2274, which it obsoleted, but I assume that the MD5 or SHA-1 HMAC, which is used for SNMPv3 message authentication and integrity, as well as the DES key in CBC mode, which is used for message privacy, still are directly computed from the localized key, as it was in RFC 2274 (i.e., this point is not as obvious in RFC 3414 as it was in RFC 2274). If this is indeed the case, then you can readily understand my concern that the common derivation of the these symmetric keys system-wide means that the compromising of the one half of a user's key, greatly eases the compromization of the remainder of that key. Furthermore, the compromization of one user's key greatly eases the compromization of another user's key. For example, if we assume that that even one administrator's password was exposed, then it is a somewhat straightforward matter to learn the snmpEngineID for that device. Once that is known, then one can see how e! asy it is to systematically compute other user passwords for that snmpEngineID, and from there other passwords on other snmpEngineIDs, thereby fully exposing the entire SNMPv3 cryptographic system, since these keys are all algorithmically related. I know of no other IETF protocol with similar key composition dependencies. Regards, /david t. perkins From owner-snmpv3@lists.tislabs.com Thu Aug 7 23:48:55 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14254 for ; Thu, 7 Aug 2003 23:48:54 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA13500 Thu, 7 Aug 2003 22:54:55 -0400 (EDT) Cc: Bill Strahm , Randy Presuhn , "Wijnen, Bert (Bert)" , Eliot Lear , "EXT-Weller, Michael K" , snmpv3@lists.tislabs.com Message-ID: <3F331280.8020103@lucent.com> Date: Thu, 07 Aug 2003 23:01:20 -0400 From: Uri Blumenthal Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: "Fleischman, Eric" Original-CC: Bill Strahm , Randy Presuhn , "Wijnen, Bert (Bert)" , Eliot Lear , "EXT-Weller, Michael K" , snmpv3@lists.tislabs.com Subject: Re: SNMPv3 security References: <5B58696DB20B9140AD20E0685C573A6402992DCB@xch-nw-09.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 7bit On 8/7/2003 6:02 PM, Fleischman, Eric wrote: >>I have no idea why you don't think a simple application can't be written that >>will update SNMP passphrases as often as you want to on your network........ Only (localized) keys would be sent over the network. And if there's a good automated management environment, then there would be no passphrase at all. > Sending passwords out to thousands of devices on a small quantum basis > consumes large amounts of bandwidth, which is very limited in many > wireless systems. Sending passwords out? Nobody sane is doing that, nor is there any provision for it in the protocol. But you contradict yourself - if session keys were used, establishing those would consume tremendous amount of bandwidth (because it takes more than just "sending passwords out" to complete key negotiation). Looks like you lack understanding of several key (no pun intended) points. 1. Passphrases are not required - they're simply ALLOWED to accomodate for the existing practices of network administrators. And measures are taken to minimize the security impact of passphrase existence (minimize - but not eliminate). A secure installation doesn't need them. 2. Traffic protection keys (under which actual encryption and auth are done) are cryptographically independent. Since it looks like I need to explain what it means: knowing any subset of the localized keys, it is not feasible to deduce any bit of any key outside of that set. If you feel cryptographically up to it, please show otherwise. 3. SNMP does not have a concept of Session (nor state), so no session keys. On the other hand, it is reasonably safe to protect about 2^60 messages before rekeying is necessary. This is for both AES and HMAC (actually, HMAC treshold is even higher, but...). If you can show how even one bit of a localized key (which encrypts the traffic) can be deduced from say, 2^64 SNMP messages, please be nice to all of us and show the attack. Otherwise, consider speaking of what you know, not of what you think you heard. If a localized key gets compromised (e.g. bad guys applied a hacksaw to a stolen router and pried the key out of its dead memory :-), can you show how to derive ANY knowledge of ANY other key in the network? 4. Diffie-Hellman is way too heavy for routine SNMP operations. It may be (and actually is) used for the initial key distribution - check RFC 2786. It might be used [seldom] to achieve PFS in rekeying. 5. Regarding changing the IV value. It is very significant. If you aren't doing that, the chance of an adversary collecting a ciphertext dictionary becomes real. But your admission of lack of insight on this subject (which is coupled with the lack of understanding of SNMP) suggests that it may be premature for you to jump to analysis of SNMPv3 security. 6. SNMP is an asymmetric protocol - very much unlike IPsec. Thus the NMS "controls" the security (actually, including the policy) of managed boxes. So it has the complete control of what the new key should be (unlike bilateral key agreements in other protocols). What might be useful is defining MIB objects "keyLifeTime" that counts the traffic protected by a given key, and treshold for it. But then, again unless the NMS decides to change the key on the box, the box can do nothing about it. And NMS doesn't need MIB to perform that kind of management. I'm sure David Spakes from SNMP Research can talk more about it. 7. Dave Perkins gave an excellent example. IF passphrase is used by an admin, then stealing it gives access to all the devices managed by that admin - just like stealing an ID card gives an access to all the doors that the given card unlocks. Conclusion - if your net uses passphrases for security - you better guard them well. 8. You said "weak authentication approach" used in SNMPv3. First of all, this very approach is used everywhere throughout IETF: including IPsec and TLS, not just SNMP. Second - would you care to to explain what's so weak about it? 9. You said "authentication keys....'are the keys to the kingdom'". How so? Assuming [practically] impossible - you cracked one auth key. Now what? How are you going to attack other boxes (this key was localized)? 10.Yes, I fully support Randy who "seems to think that [AES] is adequately strong to defeat cryptanalysis done by a security professional". Only we call them "cryptographers" and "cryptanalysts". And I'm not at liberty to discuss this type of issue with you. 11.Yes, the current approach presumes that SHA-1 is [practically] non-invertible. And not only I "spent some time figuring how to break those keys", but people whose job is to attack crypto hashes. "Great abundance of ciphertext" gives you little, considering the algorithms used (how many known plaintext pairs to you need to get a few bits of the AES128 key?). But even if you steal one key, how are you planning to reverse SHA-1? 12. You say "The fact that the algorithmic relationship between the keys can be leveraged to break additional keys, once an original key has been broken, may or may not be evident to the readers of this email. Certainly, I am offering no proof, other than implying I have an idea for how to do so." Please, pretty please - share your idea with us! Even if it's rediculous, I want to see it, and promise not to comment on it. Oh, and explaining what you mean by the "original key" would help. For if you rediscovered America (i.e. figured out how to compute localized keys if the administrator's passphrase became known) - it's neither very interesting nor very new. 13. Enough already. > Automatically initiating key changes after the quantum expires would > eliminate this objection, but it would need to be well thought out > to eliminate possible coordination problems. Management station can do both - keep track of the amount of traffic protected by a given key, and initiate the key update when it thinks necessary. Talk to David Spakes. No protocol change is necessary for that. > I think that this is an appropriate topic for the SNMPv3 working group > to address because, if it is not done here, then we would not have a > consistent and interoperable solution spanning many implementations. First one has to ascertain that there's a problem to solve. > I never once used the word "proprietary". I did use the > word "classified" once. AES-USM approach should be adaptable to any classified crypto, be it block or stream cipher (because it uses CFB mode - close enough to stream cipher to be "portable"). Just replace AES with XXX. > Changing topics, I remain interested in any insights this group may care to > offer me on approaches to supplement SNMPv3 security by protocols operating > at a different layer. It looks like the first insight necessary is to understand why SNMPv3 is the way it is. Like - why there is no concept of session (hint: designers have heard of the "session" idea, contrary to what you may think). [And there were attempts to introduce it in circa 1994.] > It does not appear that my postings have resonated with this group, > perhaps because the group would have a tremendous lot of new work > cut out for it should it admit to the validity of these concerns. Perhaps because your postings reveal serious lack of understanding of both cryptographic issues and SNMP protocol specifics. So their credibility is too low to create resonance. > I will try to privately respond to anyone who wishes to continue a > private discussion with me, however. You can start with substantiating your claims - show the exploits, for example. From owner-snmpv3@lists.tislabs.com Fri Aug 8 10:20:20 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13039 for ; Fri, 8 Aug 2003 10:20:20 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15230 Fri, 8 Aug 2003 09:17:31 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: SNMPv3 security Date: Thu, 7 Aug 2003 15:02:59 -0700 Message-ID: <5B58696DB20B9140AD20E0685C573A6402992DCB@xch-nw-09.nw.nos.boeing.com> Thread-Topic: SNMPv3 security Thread-Index: AcNdKXK86+bF3WfSRxS6FA2NQTNTWgAAclPw From: "Fleischman, Eric" To: "Bill Strahm" Cc: "Randy Presuhn" , "Uri Blumenthal" , "Wijnen, Bert (Bert)" , "Eliot Lear" , "EXT-Weller, Michael K" , X-OriginalArrivalTime: 07 Aug 2003 22:03:00.0622 (UTC) FILETIME=[AAC26AE0:01C35D2F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA12564 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit >I have no idea why you don't think a simple application can't be written that >will update SNMP passphrases as often as you want to on your network. Yes it >will take protocol overhead time, but then so does renegotiating IPsec >session keys in IPsec. For that matter you can make it a simple policy on >either end of the control that automatically initiates a keychange when a >certain crypto quantia happens (up to after every other message, once for the >key exchange, once to get data). This is simple software that has nothing to >do with the underlying protocol - other than the underlying protocol allows >keys to be negotiated over it. Sending passwords out to thousands of devices on a small quantum basis consumes large amounts of bandwidth, which is very limited in many wireless systems. Automatically initiating key changes after the quantum expires would eliminate this objection, but it would need to be well thought out to eliminate possible coordination problems. I think that this is an appropriate topic for the SNMPv3 working group to address because, if it is not done here, then we would not have a consistent and interoperable solution spanning many implementations. >Now I want to know who you are talking to that says proprietary algorithms >are trusted more than publicly available ones. I know of no serious crypto >researcher that believes this. That said, you might be using other supplied >crypto for your custommers, if so, just plug the algorythm into your SNMPv3 >implementations and you are off to the races (I plugged in the AES candidates >many years ago for fun, guess what it worked w/out an RFC, and the eventual >AES RFC looks just like my implementation of AES did, of course I had to >throw out the other candidates) I never once used the word "proprietary". I did use the word "classified" once. Changing topics, I remain interested in any insights this group may care to offer me on approaches to supplement SNMPv3 security by protocols operating at a different layer. It does not appear that my postings have resonated with this group, perhaps because the group would have a tremendous lot of new work cut out for it should it admit to the validity of these concerns. Doubtlessly, everyone is already exceedingly busy, as I am, and so the prospect of additional work is unattractive. Thus, it does not appear that anything constructive will be achieved by continuing this discussion. I will try to privately respond to anyone who wishes to continue a private discussion with me, however. --Eric From owner-snmpv3@lists.tislabs.com Fri Aug 8 10:23:35 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13101 for ; Fri, 8 Aug 2003 10:23:35 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15216 Fri, 8 Aug 2003 09:17:07 -0400 (EDT) Date: Thu, 7 Aug 2003 16:58:06 -0400 From: Bill Strahm To: "Fleischman, Eric" Cc: Randy Presuhn , Uri Blumenthal , "Wijnen, Bert (Bert)" , Eliot Lear , "EXT-Weller, Michael K" , snmpv3@lists.tislabs.com Subject: Re: SNMPv3 security Message-ID: <20030807165806.A6519@strahm.net> References: <5B58696DB20B9140AD20E0685C573A6402992DCA@xch-nw-09.nw.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5B58696DB20B9140AD20E0685C573A6402992DCA@xch-nw-09.nw.nos.boeing.com>; from eric.w.fleischman@boeing.com on Thu, Aug 07, 2003 at 01:22:39PM -0700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA12296 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit Ok, I have to ask... What security protocol defines session key timeout values as a part of the standard. I certainly don't know of any including IPsec and SSL/TLS. All things associated with session key timeouts resides within administrative control as a policy on top of the protocol for example IKE negotiates session key timeouts in the IPsec protocol, IPsec has nothing to do with it, now where does IKE get the value to negotiate for well that is a system policy set by the adminstrator, there isn't ANYTHING in the IKE RFCs that determine what value to negotiate. That said there are a HOST of research done on the appropriate ammount of data to send under a key of given strength to give an appropriate amount of security. With AES 128 my understanding is that it provides about 10000 years of protection given the current ramp of hardware and a governmental sized budget... The numbers grow exponentially to AES 256. Now there is quite a bit of research showing that AES may only be about 1000th the stength that it might be (known hacks at 9-10 rounds given a rediculous amount of memory vs. the 16 rounds in the algorithm) so lets say AES 128 is good to protect your management traffic for 10 years (1 year if they have an obscene budget)... is your management traffic THAT valuable after 1 year ? I have no idea why you don't think a simple application can't be written that will update SNMP passphrases as often as you want to on your network. Yes it will take protocol overhead time, but then so does renegotiating IPsec session keys in IPsec. For that matter you can make it a simple policy on either end of the control that automatically initiates a keychange when a certain crypto quantia happens (up to after every other message, once for the key exchange, once to get data). This is simple software that has nothing to do with the underlying protocol - other than the underlying protocol allows keys to be negotiated over it. Now I want to know who you are talking to that says proprietary algorithms are trusted more than publicly available ones. I know of no serious crypto researcher that believes this. That said, you might be using other supplied crypto for your custommers, if so, just plug the algorythm into your SNMPv3 implementations and you are off to the races (I plugged in the AES candidates many years ago for fun, guess what it worked w/out an RFC, and the eventual AES RFC looks just like my implementation of AES did, of course I had to throw out the other candidates) Time to end my discussion for now... Bill Strahm On Thu, Aug 07, 2003 at 01:22:39PM -0700, Fleischman, Eric wrote: > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > >??? Key lifetime is under control of the user / security administrator. If you want to update > >your keys every ten minutes, you can, though it doesn't address the more fundamental > >question of the strength of the crypto algorithm > > >From my knothole, the most important information I have conveyed is that one must have Session Keys with very short lifetimes in order to reduce the amount of available ciphertext that can be used for cryptanalysis. Because SNMPv3 keys have indefinitely long lifetimes, a great deal of relevant ciphertext accumulates. For SNMPv3, the cracker knows that any communication between the same source and destination IP addresses has a high degree of probability of using the same DES encryption key -- especially if the attacker has operational information about the types of systems (e.g., single user or multi-user) residing at each IP address, which is not difficult to obtain. Thus, the cracker has plenty of ciphertexts from which to apply cryptanalysis in order to break the DES encryption keys. Once the session key has been broken, then the attacker can concentrate on cracking the authentication keys, which are "the keys to the kingdom", especially because of the weak authentica! ti! on approach used by SNMPv3 (e.g., no capability for two factor authentication thus anybody knowing the authentication key can freely pretend to be that administrator). > > It is therefore essential that the Session Key have a short lifetime in order to reduce the amount of available ciphertext encrypted by the same key and to introduce doubts whether any two ciphertexts were encrypted by the same or different keys. This is the most fundamental defense available to us as SNMPv3 end users. > > Your statement above is disingenuous -- as I trust you knew when you wrote it. No user or security administrator can bear the overhead of redistributing tens of thousands of SNMPv3 passwords. They certainly can't regularly do this within an adequately short key lifetime quantum in order to make the current SNMPv3 approach begin to be viable. Egads!!! > > >> All you are doing by transitioning from using DES to AES is perhaps delaying the bad guys a few > >> hours before these keys are broken. That's almost nothing -- a false sense of security that > >>accomplishes little. > > >You must know something about AES that I don't. Any references to back up this claim > >of relative lack of strength vis-a-vis DES? > > Randy, I am confident that you already know that TRIPLE-DES is usually stronger than DES and that AES with long keys is stronger than TRIPLE-DES. However, you seem to think that any of these algorithms is adequately strong to defeat cryptanalysis done by a security professional, even in environments with long key life and an abundance of ciphertext. I am not at liberty to discuss this type of issue with you. I realize that this may seem unfriendly or non-professional to you and I apologize for this perception. Rather, let's just recall together that communities exist who are not tremendously impressed with the strength of non-classified algorithms, particularly in environments with substantial amount of ciphertext available to the well-financed cracker. > > >> The interrelationship of the keys means that breaking one key greatly eases the breaking of them all, > >> even if we are talking about dozens-of-remote-admins * thousands-of-SNMP-agents worth of keys, > >> as we are in our system. The whole thing can be rolled up fairly quickly by security professionals > >> because encryption in SNMPv3 is being applied in a barefoot manner. > > >It sounds like you're assuming that the key localization algorithm is insufficiently one-way. > >I know there's been some speculation that MD5 might be inadequate for this purpose, > >but has anyone actually demonstrated it? In any case, I think Uri's AES i-d addresses > >this (at least earlier versions did). > > The current approach presumes that SHA-1 or MD5 hashes provide enough key randomization to thwart the underlying algorithmic relationship between these keys. I can understand why you may think this. However, if you spent some time figuring out how to break these keys, then a possibility exists that you perhaps may agree with me that this underlying relationship provides a helpful mechanism to exploit for breaking these keys, particularly with a great abundance of ciphertext to work with. > > >> The only way this can be remedied is not by doing minor tweaks of encryption algorithms > >> but rather by redesigning the security system to place it upon a solid footing. Session > >> Keys should have very short, finite lifetimes. > > >Nice in theory, but brings other costs and other risks, like > >the possibility that session establishment will fail in highly > >stressed networks. > > Yes, you are correct. I simplified a difficult problem. However, until SNMPv3 can have session keys with short lifetimes, the protocol is essentially unsecurable -- which is why I am currently seeking to secure SNMPv3 at a lower protocol layer (i.e., the beginning of this email thread). > > >The decision to use key localization was made because implementation and > >deployment experience with various flavours of SNMPv2 showed that using > >totally independent keys scaled badly. The assertion that key localization > >presents a point of attack is based on the assumption that compromising a localized > >key would provide information that would be useful in deriving either the initial > >passphrase or some other localized key. As far as I know, no one has been able > >to justify such an assumption. > > Yes, it is obvious that something had to be done to reduce the overhead burden of distributing two symmetric keys between each SNMP-agent and network-administrator pairing. SNMP adopted a creative solution to this problem. However, if the protocol were to be redesigned today, other solutions would be available, including the ones I mentioned in my email, which would offer greater protections and lower the existing administrative burden. For example, if SNMP were secured in a parallel manner as even one other IETF protocol, then the administrative burden for administrators supporting both protocols would be materially eased. > > The fact that the algorithmic relationship between the keys can be leveraged to break additional keys, once an original key has been broken, may or may not be evident to the readers of this email. Certainly, I am offering no proof, other than implying I have an idea for how to do so. However, this fact is far less important than fixing the primary weakness of the system, which is the lack of a viable session key mechanism, which exposes all the SNMPv3 keys to compromise, even if they hadn't had an underlying algorithmic relationship to leverage. > > >> These keys should be distributable > >> via already existing key distribution systems (e.g., Kerberos, PKI), perhaps by using "seed > >> key values", or else composite keys. In addition, whatever you do at the SNMPv3 application > >> layer should be designed to work with security provisions at another layer. > > >Sure, the architecture allows you to define other security models like these, but > >see the SNMPv3 WG archives for lots of reasons why one wouldn't want to mandate this. > > I am not telling your working group what algorithm or approach to use because these are weighty issues, far outside the scope of my posting. Rather, I am merely saying that the existing system is unsecurable unless supplemented by the security provisions of additional protocol layers. > > As you may recall, my original intent was not to question or debate SNMPv3 security at all, but rather to query the IETF list to see whether SSH port forwarding had been successfully used by others to partially secure SNMP. Has anybody on this list used SSH port forwarding for SNMP? If so, do you believe the approach to be viable or not? Was any other approach more successful? (Please respond directly to me because I am not yet a member of the snmpv3 list.) > > --Eric From owner-snmpv3@lists.tislabs.com Fri Aug 8 11:46:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15635 for ; Fri, 8 Aug 2003 11:46:17 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15611 Fri, 8 Aug 2003 10:43:50 -0400 (EDT) To: snmpv3@lists.tislabs.com Subject: Call for Papers: WiOpt'04 Message-Id: From: Holger Karl Date: Fri, 08 Aug 2003 16:00:01 +0200 X-Virus-Scanned: Sophos MailMonitor on mail.zrz.tu-berlin.de; Fri, 08 Aug 2003 16:40:04 +0200 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Apologies if you receive multiple copies of this call! ---------------------------------------------------------------------- Note: The submission deadline is 5th of November, 2003. *************************************************** ******** CALL FOR PAPERS ******** *************************************************** * * * WiOpt '04 * * * * 2nd Workshop on Modeling and Optimization * * in Mobile, Ad Hoc and Wireless Networks * * * * March 24 - 26, 2004, Cambridge, UK * * * * * *************************************************** Workshop Website: http://www.cl.cam.ac.uk/Research/SRG/wiopt04/ This workshop is intended to bring together leading researchers from both academia and industry to present both foundations and practical methods and tools for modeling and optimisation of mobile and ad hoc networks. The workshop will bring together researchers studying optimisation issues of mobile networks from both the network performance and the mobile networking perspectives: * Mobile Network Optimisation: Applications and Algorithms * Performance characterisation and optimisation of mobile/wireless networks and systems * Protocol design (MAC, Routing) for optimal mobile network utilisation * Tools for network optimisation * Energy efficiency in mobile networks * Security and co-operation models for mobile networks * Pricing and incentives in mobile and ad hoc networks. Papers to be presented at WiOpt'04 will be selected based on extended abstracts of up to 8 pages, double-spaced, 12 point font size. The submission should not exceed 3000 words including tables and figures, each of which count as 250 words. Authors of accepted presentations will have the opportunity to publish either the extended abstract or the full paper in a proceedings volume. Full papers will further be considered for publication in a special issue of the MONET journal. Plenary Speakers: Bruce Hajek (University of Illinois at Urbana-Champaign, USA) Ian Akyildiz (Georgia Institute of Technology, USA) IMPORTANT DATES: Submission of extended abstract: Nov. 5, 2003. Notification of acceptance: Jan. 15, 2003. Camera ready copy: Feb. 15, 2003. (Further details on the workshop website, http://www.cl.cam.ac.uk/Research/SRG/wiopt04/) General chairman: Imrich Chlamtac Vice General Chair: Roger Whitaker Program Co-Chairs: Marco Conti and Tamer Basar Program committee of the conference: Eitan Altman, Venkat Anantharam, Konstantin Avrachenkov, Andrew Campbell, A. Chockalingam, Jon Crowcroft, Silvia Giordano, Stephen V. Hanly, Jean-Pierre Hubaux, Holger Karl, Peter Key, P. R. Kumar, Peter Marbach, Philippe Nain, Sven Oestring, Yoshikuni Onozato, Ramesh Rao, Ness Shroff, Violet Syrotiuk, Thierry Turletti, Adam Wolisz, Jeff Wieselthier Local Arrangements Co-Chair: Sven Oestring and Julian Chesterfield Publicity Chair: Holger Karl Sponsors: The workshop is co-sponsored by * Univ. of Cambridge * IIT (Istituto di Informatica e Telematica) * Intel * Microsoft * IEEE IT Society (technical co-sponsorship) (ACM sponsorship is pending.) From owner-snmpv3@lists.tislabs.com Fri Aug 8 13:19:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18288 for ; Fri, 8 Aug 2003 13:19:03 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16020 Fri, 8 Aug 2003 12:22:34 -0400 (EDT) To: "Fleischman, Eric" Cc: "Bill Strahm" , "Randy Presuhn" , "Uri Blumenthal" , "Wijnen, Bert (Bert)" , "Eliot Lear" , "EXT-Weller, Michael K" , , Ken Hornstein Subject: Re: SNMPv3 security References: <5B58696DB20B9140AD20E0685C573A6402992DCB@xch-nw-09.nw.nos.boeing.com> From: Wes Hardaker Organization: Sparta Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXotKX87e8eDA4GAQbQgmlzNycHAwizYkruzul2AAACaUlEQVR4nFXUTW/jIBAGYFI56jWutuq1S9b2dddW6dWtQFxbq4jzwq73Glmg+fv7DiT9QJGS+GEGhiER67TWEQ5CtOeh21ZcIIbmOPq5QvMZYlyV6u+/gsJLTSrGIL/CxEPxQuPAcP0JYlQsq3x5B3UJmUaEyB6yZ+CQ+pwXCzKsbXtbIhg4KtZypPz+AVGtlxH69c87qAqRY6Rc5QUmZMGeAj+TfVjjUwE1lflKys5JGXpM+V0hltqCJ0qL7Plkft4wRM6lxi5p3Wyy7O7fB8TgtdZivxy5rvAB6wSYhbA9vn+GOCaOEGJRPO2mHgk+q1Chyf0Up3AG0NjhOXI19ogEFziq6M+ZtN3kUZ13NW4qUCprC3CW668C06M5jihON1Vsjq8F1CPJB8LINNeQfscwxUEvAwM5Xghvsq2pBr3hnKhbDIrMS3cBRDx70uS9JW2dy667gM0AbZFFmyvn3GOBGB8wG9kppaSNz357LaCmUdtSny5LU9qeCrglvJmyH20TwkjnXQE0usscIWayCWZJ7OpZ4QbUVGRnhuTub3cMYRk99oSplDIfibzfn0FyXyk7z8XThuvC0P/dGCwee7O8aZJBmh0vPixy0NrYhDaR02aR3W0BbyT6h23OB5Hzybj+DOm5w6XCOZG13p5Oh/bursJVh9S+bBiFnPCDuntpcTH080AO+7GlW1i3bRphBM04dZ2dI6yMLjmGFqnIok/cB1YU8sJAACTeuHOd5+lumQHfDM6KyLqEm4aWkkcc1m4PqBewZxBZOg44lT+aJiexDteewboiVhxAjSHxQwhiYJEdCR6tMN1/uckirDRNbsgAAAAASUVORK5CYII= Date: Fri, 08 Aug 2003 09:29:51 -0700 In-Reply-To: <5B58696DB20B9140AD20E0685C573A6402992DCB@xch-nw-09.nw.nos.boeing.com> (Eric Fleischman's message of "Thu, 7 Aug 2003 15:02:59 -0700") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk >>>>> On Thu, 7 Aug 2003 15:02:59 -0700, "Fleischman, Eric" said: Eric> Changing topics, I remain interested in any insights this group Eric> may care to offer me on approaches to supplement SNMPv3 security Eric> by protocols operating at a different layer. Eric, FYI: 1) snmp can run over TCP (thus your snmp over ssh over tcp should work just fine), though not every implementation supports it (SNMP research products do not, for example). 2) A snmp/krb5 draft was written a while back by Ken Hornstein and myself (though it's now out of date... Ken, we really need to republish this and send it to the IESG), and an implementation of it is available in the Net-SNMP toolkit. -- Wes Hardaker Sparta From owner-snmpv3@lists.tislabs.com Fri Aug 8 13:25:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18440 for ; Fri, 8 Aug 2003 13:25:13 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16061 Fri, 8 Aug 2003 12:32:57 -0400 (EDT) To: "Randy Presuhn" Cc: "Fleischman, Eric" , "Uri Blumenthal" , "Wijnen, Bert (Bert)" , , "Eliot Lear" , "EXT-Weller, Michael K" , Subject: Re: SNMPv3 security References: <5B58696DB20B9140AD20E0685C573A6402992DC9@xch-nw-09.nw.nos.boeing.com> <00c001c35d10$50a730a0$7f1afea9@oemcomputer> From: Wes Hardaker Organization: Sparta Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXotKX87e8eDA4GAQbQgmlzNycHAwizYkruzul2AAACaUlEQVR4nFXUTW/jIBAGYFI56jWutuq1S9b2dddW6dWtQFxbq4jzwq73Glmg+fv7DiT9QJGS+GEGhiER67TWEQ5CtOeh21ZcIIbmOPq5QvMZYlyV6u+/gsJLTSrGIL/CxEPxQuPAcP0JYlQsq3x5B3UJmUaEyB6yZ+CQ+pwXCzKsbXtbIhg4KtZypPz+AVGtlxH69c87qAqRY6Rc5QUmZMGeAj+TfVjjUwE1lflKys5JGXpM+V0hltqCJ0qL7Plkft4wRM6lxi5p3Wyy7O7fB8TgtdZivxy5rvAB6wSYhbA9vn+GOCaOEGJRPO2mHgk+q1Chyf0Up3AG0NjhOXI19ogEFziq6M+ZtN3kUZ13NW4qUCprC3CW668C06M5jihON1Vsjq8F1CPJB8LINNeQfscwxUEvAwM5Xghvsq2pBr3hnKhbDIrMS3cBRDx70uS9JW2dy667gM0AbZFFmyvn3GOBGB8wG9kppaSNz357LaCmUdtSny5LU9qeCrglvJmyH20TwkjnXQE0usscIWayCWZJ7OpZ4QbUVGRnhuTub3cMYRk99oSplDIfibzfn0FyXyk7z8XThuvC0P/dGCwee7O8aZJBmh0vPixy0NrYhDaR02aR3W0BbyT6h23OB5Hzybj+DOm5w6XCOZG13p5Oh/bursJVh9S+bBiFnPCDuntpcTH080AO+7GlW1i3bRphBM04dZ2dI6yMLjmGFqnIok/cB1YU8sJAACTeuHOd5+lumQHfDM6KyLqEm4aWkkcc1m4PqBewZxBZOg44lT+aJiexDteewboiVhxAjSHxQwhiYJEdCR6tMN1/uckirDRNbsgAAAAASUVORK5CYII= Date: Fri, 08 Aug 2003 09:40:18 -0700 In-Reply-To: <00c001c35d10$50a730a0$7f1afea9@oemcomputer> (Randy Presuhn's message of "Thu, 7 Aug 2003 11:18:34 -0700") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk >>>>> On Thu, 7 Aug 2003 11:18:34 -0700, "Randy Presuhn" said: Randy> ??? Key lifetime is under control of the user / security Randy> administrator. If you want to update your keys every ten Randy> minutes, you can, though it doesn't address the more Randy> fundamental question of the strength of the crypto algorithm This has been discussed several times. Just one more point that I think Eric is trying to get across but most people are missing: Having the key lifetime controlled by the manager means that if the box gets disconnected from the network then the key can't be updated. This is important if the box contains critical data. An attacker that can sever the network connection (a simple DoS attack would suffice for this) between the manager and the agent can then spend all the time the needs to figure out the keys and access the contents of the box. This is a big difference between other protocols (kerberos, IKE, etc) that hold a key to a given lifetime at the box itself. IE, after a period of time the box itself refuses to reuse the key in question. Eric's concern in this area is valid, IMHO, but is also nothing new. Still, I think many people are missing this point. -- Wes Hardaker Sparta From owner-snmpv3@lists.tislabs.com Fri Aug 8 14:10:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19622 for ; Fri, 8 Aug 2003 14:10:36 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16320 Fri, 8 Aug 2003 13:17:12 -0400 (EDT) To: Wes Hardaker , "Randy Presuhn" Cc: "Fleischman, Eric" , "Uri Blumenthal" , "Wijnen, Bert (Bert)" , , "Eliot Lear" , "EXT-Weller, Michael K" , Content-Type: text/plain; charset="windows-1251" From: Uri Blumenthal Original-To: Wes Hardaker , "Randy Presuhn" Subject: Re: SNMPv3 security Date: Fri, 8 Aug 2003 13:32:17 -0400 User-Agent: KMail/1.4.1 Original-Cc: "Fleischman, Eric" , "Uri Blumenthal" , "Wijnen, Bert (Bert)" , , "Eliot Lear" , "EXT-Weller, Michael K" , References: <5B58696DB20B9140AD20E0685C573A6402992DC9@xch-nw-09.nw.nos.boeing.com> <00c001c35d10$50a730a0$7f1afea9@oemcomputer> In-Reply-To: MIME-Version: 1.0 Message-Id: <200308081332.17029.uri@elliptic> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA16317 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit On Friday 08 August 2003 12:40 pm, Wes Hardaker wrote: > Randy> ??? Key lifetime is under control of the user / security > Randy> administrator. If you want to update your keys every ten > Randy> minutes, you can, though it doesn't address the more > Randy> fundamental question of the strength of the crypto algorithm > > This has been discussed several times. Just one more point that I > think Eric is trying to get across but most people are missing: Having > the key lifetime controlled by the manager means that if the box gets > disconnected from the network then the key can't be updated. And if the key update is not controlled by the manager and the box got disconnected or DoS'ed - how will the box and the manager run their key renegtiation? > that can > sever the network connection (a simple DoS attack would suffice for > this) between the manager and the agent can then spend all the time > the needs to figure out the keys and access the contents of the box. How? By sending messages to the box and watching how the box responds? Please consider that the underlying crypto algorithms are designed to withstand such an attack. And also, mis-encrypted packets will elicit no response at all, and mis-authenticated packets will at best (for the attacker) elicit a trap. There's no known cryptanalytic attack (even if you're using DES :-) against such setup - and the exhaustive search (guessing of the key going through every possible one) isn't likely to succeed against either AES or HMAC (success probability 2^-127). > This is a big difference between other protocols (kerberos, IKE, etc) > that hold a key to a given lifetime at the box itself. I agree that it may be a good idea to add a MIB object "keyLifeTime" measured in bytes, 64-bit counter. > IE, after a > period of time the box itself refuses to reuse the key in question. OK, from security point of view it's fine. In practical language it may mean that somebody has to go to the device and change the key. (In a smart setup there would a "privilleged" user/key used only for key updates and not for traffic :-). > Eric's concern in this area is valid, IMHO, but is also nothing new. > Still, I think many people are missing this point. :-) [You don't know how difficult it was to just get agreement to move from plain MD5 to HMAC. And it wouldn't have happened without Jeff Schiller. :-] From owner-snmpv3@lists.tislabs.com Fri Aug 8 14:12:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19717 for ; Fri, 8 Aug 2003 14:12:21 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16326 Fri, 8 Aug 2003 13:17:55 -0400 (EDT) Message-Id: <5.2.1.1.0.20030808160243.00b581e0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 08 Aug 2003 18:09:15 +0100 To: Bill Strahm , "Fleischman, Eric" From: Bruno Dias Subject: Re: SNMPv3 security Cc: Randy Presuhn , Uri Blumenthal , "Wijnen, Bert (Bert)" , Eliot Lear , "EXT-Weller, Michael K" , snmpv3@lists.tislabs.com In-Reply-To: <20030807165806.A6519@strahm.net> References: <5B58696DB20B9140AD20E0685C573A6402992DCA@xch-nw-09.nw.nos.boeing.com> <5B58696DB20B9140AD20E0685C573A6402992DCA@xch-nw-09.nw.nos.boeing.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_12906027==.ALT" X-OriginalArrivalTime: 08 Aug 2003 17:09:04.0340 (UTC) FILETIME=[C5211940:01C35DCF] Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk --=====================_12906027==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable At 21:58 07-08-2003, Bill Strahm wrote: >Ok, I have to ask... > >What security protocol defines session key timeout values as a part of the >standard. I certainly don't know of any including IPsec and SSL/TLS. All >things associated with session key timeouts resides within administrative >control as a policy on top of the protocol for example IKE negotiates >session key timeouts in the IPsec protocol, IPsec has nothing to do with= it, >now where does IKE get the value to negotiate for well that is a system= policy >set by the adminstrator, there isn't ANYTHING in the IKE RFCs that= determine >what value to negotiate. That said there are a HOST of research done on >the appropriate ammount of data to send under a key of given strength to >give an appropriate amount of security. With AES 128 my understanding is= that >it provides about 10000 years of protection given the current ramp of= hardware >and a governmental sized budget... The numbers grow exponentially to AES= 256. >Now there is quite a bit of research showing that AES may only be about= 1000th >the stength that it might be (known hacks at 9-10 rounds given a rediculous >amount of memory vs. the 16 rounds in the algorithm) so lets say AES 128 is >good to protect your management traffic for 10 years (1 year if they have= an >obscene budget)... is your management traffic THAT valuable after 1 year ? I just like the way the we're talking about these security protocols... Statements like "about 10000 years of protection given the current ramp of= =20 hardware and a governmental sized budget..." is quite funny for a non expert like me= =20 and a complete joke for a "network computer security professional" (yes, there's a lot more=20 about security on computer networks than cryptoanalisis!). I'd love to read the article where this was= =20 written... Eric was criticized by his apparent lack of cryptography background, but on= =20 a generic discussion about symmetric cripytography his toughts are a safer approach=20 than we all normally tend to assume... The "amount of data to send under a key of given strength to give an appropriate amount of security", as I understand it, is not exactly= =20 the same as the time of "protection" a key can assure. In fact, these are two= different types of security strengths. The first is about security strength to=20 cryptoanalisis attacks and the second is about security strength to brute force attacks. While the later is=20 "only" dependent on the key size vs computer power (you need to increase key size to figth the computer power=20 evolution), the first one is much more hard to evaluate but it is believed that the larger the amount= =20 of data analised the better are the chances to compromise the key. Well, on a communication=20 between two (or more) network entities the amount of data transmited, and prone to be=20 cryptoanalised, increases as time passes, so is the chance of the key to be compromised. Also, in general,=20 the amount of time need to crack a key by cryptoanalisis is much smaller than the brute=20 force attack when the some weekenesses are discovered on the crypto algorithm or on the key= itself. But the real intention beyond limited key time life spans has to do about=20 compromised keys due to bad key management (week key values, management applications and=20 operating systems security weekenesses, unsecure key storage, etc) than compromised keys from= =20 brute force or cryptoanalisis attacks. That's where a protocol imposing a limited key time life span (or key=20 sessions) woud help to reduce the amount of this data. Not such a bad (or new) idea... even if not directly applicable on current= =20 SNMP standards, but the regular changing of passphrases by some sort of application could be=20 usefull (as someone as already discovered *;o), although it brings some "third=20 party trust" security problems that makes this key distribution a not so simple matter... Regards, -- Bruno Dias >I have no idea why you don't think a simple application can't be written= that >will update SNMP passphrases as often as you want to on your network. Yes= it >will take protocol overhead time, but then so does renegotiating IPsec >session keys in IPsec. For that matter you can make it a simple policy on >either end of the control that automatically initiates a keychange when a >certain crypto quantia happens (up to after every other message, once for= the >key exchange, once to get data). This is simple software that has nothing= to >do with the underlying protocol - other than the underlying protocol allows >keys to be negotiated over it. > >Now I want to know who you are talking to that says proprietary algorithms >are trusted more than publicly available ones. I know of no serious crypto >researcher that believes this. That said, you might be using other= supplied >crypto for your custommers, if so, just plug the algorythm into your SNMPv3 >implementations and you are off to the races (I plugged in the AES= candidates >many years ago for fun, guess what it worked w/out an RFC, and the eventual >AES RFC looks just like my implementation of AES did, of course I had to >throw out the other candidates) > >Time to end my discussion for now... > >Bill Strahm > >On Thu, Aug 07, 2003 at 01:22:39PM -0700, Fleischman, Eric wrote: > > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > > >??? Key lifetime is under control of the user / security=20 > administrator. If you want to update > > >your keys every ten minutes, you can, though it doesn't address the=20 > more fundamental > > >question of the strength of the crypto algorithm > > > > >From my knothole, the most important information I have conveyed is=20 > that one must have Session Keys with very short lifetimes in order to=20 > reduce the amount of available ciphertext that can be used for=20 > cryptanalysis. Because SNMPv3 keys have indefinitely long lifetimes, a=20 > great deal of relevant ciphertext accumulates. For SNMPv3, the cracker=20 > knows that any communication between the same source and destination IP=20 > addresses has a high degree of probability of using the same DES=20 > encryption key -- especially if the attacker has operational information= =20 > about the types of systems (e.g., single user or multi-user) residing at= =20 > each IP address, which is not difficult to obtain. Thus, the cracker has= =20 > plenty of ciphertexts from which to apply cryptanalysis in order to break= =20 > the DES encryption keys. Once the session key has been broken, then the=20 > attacker can concentrate on cracking the authentication keys, which are=20 > "the keys to the kingdom", especially because of the weak authentica! > ti! >on approach used by SNMPv3 (e.g., no capability for two factor=20 >authentication thus anybody knowing the authentication key can freely=20 >pretend to be that administrator). > > > > It is therefore essential that the Session Key have a short lifetime in= =20 > order to reduce the amount of available ciphertext encrypted by the same= =20 > key and to introduce doubts whether any two ciphertexts were encrypted by= =20 > the same or different keys. This is the most fundamental defense=20 > available to us as SNMPv3 end users. > > > > Your statement above is disingenuous -- as I trust you knew when you=20 > wrote it. No user or security administrator can bear the overhead of=20 > redistributing tens of thousands of SNMPv3 passwords. They certainly=20 > can't regularly do this within an adequately short key lifetime quantum=20 > in order to make the current SNMPv3 approach begin to be viable. Egads!!! > > > > >> All you are doing by transitioning from using DES to AES is perhaps= =20 > delaying the bad guys a few > > >> hours before these keys are broken. That's almost nothing -- a false= =20 > sense of security that > > >>accomplishes little. > > > > >You must know something about AES that I don't. Any references to=20 > back up this claim > > >of relative lack of strength vis-a-vis DES? > > > > Randy, I am confident that you already know that TRIPLE-DES is usually= =20 > stronger than DES and that AES with long keys is stronger than=20 > TRIPLE-DES. However, you seem to think that any of these algorithms is=20 > adequately strong to defeat cryptanalysis done by a security=20 > professional, even in environments with long key life and an abundance of= =20 > ciphertext. I am not at liberty to discuss this type of issue with you. I= =20 > realize that this may seem unfriendly or non-professional to you and I=20 > apologize for this perception. Rather, let's just recall together that=20 > communities exist who are not tremendously impressed with the strength of= =20 > non-classified algorithms, particularly in environments with substantial= =20 > amount of ciphertext available to the well-financed cracker. > > > > >> The interrelationship of the keys means that breaking one key=20 > greatly eases the breaking of them all, > > >> even if we are talking about dozens-of-remote-admins *=20 > thousands-of-SNMP-agents worth of keys, > > >> as we are in our system. The whole thing can be rolled up fairly=20 > quickly by security professionals > > >> because encryption in SNMPv3 is being applied in a barefoot manner. > > > > >It sounds like you're assuming that the key localization algorithm is= =20 > insufficiently one-way. > > >I know there's been some speculation that MD5 might be inadequate for= =20 > this purpose, > > >but has anyone actually demonstrated it? In any case, I think Uri's=20 > AES i-d addresses > > >this (at least earlier versions did). > > > > The current approach presumes that SHA-1 or MD5 hashes provide enough=20 > key randomization to thwart the underlying algorithmic relationship=20 > between these keys. I can understand why you may think this. However, if= =20 > you spent some time figuring out how to break these keys, then a=20 > possibility exists that you perhaps may agree with me that this=20 > underlying relationship provides a helpful mechanism to exploit for=20 > breaking these keys, particularly with a great abundance of ciphertext to= =20 > work with. > > > > >> The only way this can be remedied is not by doing minor tweaks of=20 > encryption algorithms > > >> but rather by redesigning the security system to place it upon a=20 > solid footing. Session > > >> Keys should have very short, finite lifetimes. > > > > >Nice in theory, but brings other costs and other risks, like > > >the possibility that session establishment will fail in highly > > >stressed networks. > > > > Yes, you are correct. I simplified a difficult problem. However, until= =20 > SNMPv3 can have session keys with short lifetimes, the protocol is=20 > essentially unsecurable -- which is why I am currently seeking to secure= =20 > SNMPv3 at a lower protocol layer (i.e., the beginning of this email= thread). > > > > >The decision to use key localization was made because implementation= and > > >deployment experience with various flavours of SNMPv2 showed that using > > >totally independent keys scaled badly. The assertion that key=20 > localization > > >presents a point of attack is based on the assumption that=20 > compromising a localized > > >key would provide information that would be useful in deriving either= =20 > the initial > > >passphrase or some other localized key. As far as I know, no one has= =20 > been able > > >to justify such an assumption. > > > > Yes, it is obvious that something had to be done to reduce the overhead= =20 > burden of distributing two symmetric keys between each SNMP-agent and=20 > network-administrator pairing. SNMP adopted a creative solution to this=20 > problem. However, if the protocol were to be redesigned today, other=20 > solutions would be available, including the ones I mentioned in my email,= =20 > which would offer greater protections and lower the existing=20 > administrative burden. For example, if SNMP were secured in a parallel=20 > manner as even one other IETF protocol, then the administrative burden=20 > for administrators supporting both protocols would be materially eased. > > > > The fact that the algorithmic relationship between the keys can be=20 > leveraged to break additional keys, once an original key has been broken,= =20 > may or may not be evident to the readers of this email. Certainly, I am=20 > offering no proof, other than implying I have an idea for how to do so.=20 > However, this fact is far less important than fixing the primary weakness= =20 > of the system, which is the lack of a viable session key mechanism, which= =20 > exposes all the SNMPv3 keys to compromise, even if they hadn't had an=20 > underlying algorithmic relationship to leverage. > > > > >> These keys should be distributable > > >> via already existing key distribution systems (e.g., Kerberos, PKI),= =20 > perhaps by using "seed > > >> key values", or else composite keys. In addition, whatever you do at= =20 > the SNMPv3 application > > >> layer should be designed to work with security provisions at another= =20 > layer. > > > > >Sure, the architecture allows you to define other security models like= =20 > these, but > > >see the SNMPv3 WG archives for lots of reasons why one wouldn't want=20 > to mandate this. > > > > I am not telling your working group what algorithm or approach to use=20 > because these are weighty issues, far outside the scope of my posting.=20 > Rather, I am merely saying that the existing system is unsecurable unless= =20 > supplemented by the security provisions of additional protocol layers. > > > > As you may recall, my original intent was not to question or debate=20 > SNMPv3 security at all, but rather to query the IETF list to see whether= =20 > SSH port forwarding had been successfully used by others to partially=20 > secure SNMP. Has anybody on this list used SSH port forwarding for SNMP?= =20 > If so, do you believe the approach to be viable or not? Was any other=20 > approach more successful? (Please respond directly to me because I am not= =20 > yet a member of the snmpv3 list.) > > > > --Eric Bruno Dias Departamento de Inform=E1tica - Universidade do Minho Campus de Gualtar, 4710-057 Braga, PORTUGAL E-Mail Telef<+351 919 312 312> Fax<+351 253 604= 471> --=====================_12906027==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 21:58 07-08-2003, Bill Strahm wrote: Ok, I have to ask... What security protocol defines session key timeout values as a part of the standard. I certainly don't know of any including IPsec and SSL/TLS. All things associated with session key timeouts resides within administrative control as a policy on top of the protocol for example IKE negotiates session key timeouts in the IPsec protocol, IPsec has nothing to do with it, now where does IKE get the value to negotiate for well that is a system policy set by the adminstrator, there isn't ANYTHING in the IKE RFCs that determine what value to negotiate. That said there are a HOST of research done on the appropriate ammount of data to send under a key of given strength to give an appropriate amount of security. With AES 128 my understanding is that it provides about 10000 years of protection given the current ramp of hardware and a governmental sized budget... The numbers grow exponentially to AES 256. Now there is quite a bit of research showing that AES may only be about 1000th the stength that it might be (known hacks at 9-10 rounds given a rediculous amount of memory vs. the 16 rounds in the algorithm) so lets say AES 128 is good to protect your management traffic for 10 years (1 year if they have an obscene budget)... is your management traffic THAT valuable after 1 year ? I just like the way the we're talking about these security protocols... Statements like "about 10000 years of protection given the current ramp of hardware and a governmental sized budget..." is quite funny for a non expert like me and a complete joke for a "network computer security professional" (yes, there's a lot more about security on computer networks than cryptoanalisis!). I'd love to read the article where this was written... Eric was criticized by his apparent lack of cryptography background, but on a generic discussion about symmetric cripytography his toughts are a safer approach than we all normally tend to assume... The "amount of data to send under a key of given strength to give an appropriate amount of security", as I understand it, is not exactly the same as the time of "protection" a key can assure. In fact, these are two different types of security strengths. The first is about security strength to cryptoanalisis attacks and the second is about security strength to brute force attacks. While the later is "only" dependent on the key size vs computer power (you need to increase key size to figth the computer power evolution), the first one is much more hard to evaluate but it is believed that the larger the amount of data analised the better are the chances to compromise the key. Well, on a communication between two (or more) network entities the amount of data transmited, and prone to be cryptoanalised, increases as time passes, so is the chance of the key to be compromised. Also, in general, the amount of time need to crack a key by cryptoanalisis is much smaller than the brute force attack when the some weekenesses are discovered on the crypto algorithm or on the key itself. But the real intention beyond limited key time life spans has to do about compromised keys due to bad key management (week key values, management applications and operating systems security weekenesses, unsecure key storage, etc) than compromised keys from brute force or cryptoanalisis attacks. That's where a protocol imposing a limited key time life span (or key sessions) woud help to reduce the amount of this data. Not such a bad (or new) idea... even if not directly applicable on current SNMP standards, but the regular changing of passphrases by some sort of application could be usefull (as someone as already discovered *;o), although it brings some "third party trust" security problems that makes this key distribution a not so simple matter... Regards, -- Bruno Dias I have no idea why = you don't think a simple application can't be written that will update SNMP passphrases as often as you want to on your network. Yes it will take protocol overhead time, but then so does renegotiating IPsec session keys in IPsec. For that matter you can make it a simple policy on either end of the control that automatically initiates a keychange when a certain crypto quantia happens (up to after every other message, once for the key exchange, once to get data). This is simple software that has nothing to do with the underlying protocol - other than the underlying protocol allows keys to be negotiated over it. Now I want to know who you are talking to that says proprietary algorithms are trusted more than publicly available ones. I know of no serious crypto researcher that believes this. That said, you might be using other supplied crypto for your custommers, if so, just plug the algorythm into your SNMPv3 implementations and you are off to the races (I plugged in the AES candidates many years ago for fun, guess what it worked w/out an RFC, and the eventual AES RFC looks just like my implementation of AES did, of course I had to throw out the other candidates) Time to end my discussion for now... Bill Strahm On Thu, Aug 07, 2003 at 01:22:39PM -0700, Fleischman, Eric wrote: > From: Randy Presuhn [<3d.htm>mailto:randy_presuhn@mindspring.com] > >??? Key lifetime is under control of the user / security administrator. If you want to update > >your keys every ten minutes, you can, though it doesn't address the more fundamental > >question of the strength of the crypto algorithm > > >From my knothole, the most important information I have conveyed is that one must have Session Keys with very short lifetimes in order to reduce the amount of available ciphertext that can be used for cryptanalysis. Because SNMPv3 keys have indefinitely long lifetimes, a great deal of relevant ciphertext accumulates. For SNMPv3, the cracker knows that any communication between the same source and destination IP addresses has a high degree of probability of using the same DES encryption key -- especially if the attacker has operational information about the types of systems (e.g., single user or multi-user) residing at each IP address, which is not difficult to obtain. Thus, the cracker has plenty of ciphertexts from which to apply cryptanalysis in order to break the DES encryption keys. Once the session key has been broken, then the attacker can concentrate on cracking the authentication keys, which are "the keys to the kingdom", especially because of the weak authentica! ! ti! on approach used by SNMPv3 (e.g., no capability for two factor authentication thus anybody knowing the authentication key can freely pretend to be that administrator). > > It is therefore essential that the Session Key have a short lifetime in order to reduce the amount of available ciphertext encrypted by the same key and to introduce doubts whether any two ciphertexts were encrypted by the same or different keys. This is the most fundamental defense available to us as SNMPv3 end users. > > Your statement above is disingenuous -- as I trust you knew when you wrote it. No user or security administrator can bear the overhead of redistributing tens of thousands of SNMPv3 passwords. They certainly can't regularly do this within an adequately short key lifetime quantum in order to make the current SNMPv3 approach begin to be viable. Egads!!! > > >> All you are doing by transitioning from using DES to AES is perhaps delaying the bad guys a few > >> hours before these keys are broken. That's almost nothing -- a false sense of security that > >>accomplishes little. > > >You must know something about AES that I don't. Any references to back up this claim > >of relative lack of strength vis-a-vis DES? > > Randy, I am confident that you already know that TRIPLE-DES is usually stronger than DES and that AES with long keys is stronger than TRIPLE-DES. However, you seem to think that any of these algorithms is adequately strong to defeat cryptanalysis done by a security professional, even in environments with long key life and an abundance of ciphertext. I am not at liberty to discuss this type of issue with you. I realize that this may seem unfriendly or non-professional to you and I apologize for this perception. Rather, let's just recall together that communities exist who are not tremendously impressed with the strength of non-classified algorithms, particularly in environments with substantial amount of ciphertext available to the well-financed cracker. > > >> The interrelationship of the keys means that breaking one key greatly eases the breaking of them all, > >> even if we are talking about dozens-of-remote-admins * thousands-of-SNMP-agents worth of keys, > >> as we are in our system. The whole thing can be rolled up fairly quickly by security professionals > >> because encryption in SNMPv3 is being applied in a barefoot manner. > > >It sounds like you're assuming that the key localization algorithm is insufficiently one-way. > >I know there's been some speculation that MD5 might be inadequate for this purpose, > >but has anyone actually demonstrated it? In any case, I think Uri's AES i-d addresses > >this (at least earlier versions did). > > The current approach presumes that SHA-1 or MD5 hashes provide enough key randomization to thwart the underlying algorithmic relationship between these keys. I can understand why you may think this. However, if you spent some time figuring out how to break these keys, then a possibility exists that you perhaps may agree with me that this underlying relationship provides a helpful mechanism to exploit for breaking these keys, particularly with a great abundance of ciphertext to work with. > > >> The only way this can be remedied is not by doing minor tweaks of encryption algorithms > >> but rather by redesigning the security system to place it upon a solid footing. Session > >> Keys should have very short, finite lifetimes. > > >Nice in theory, but brings other costs and other risks, like > >the possibility that session establishment will fail in highly > >stressed networks. > > Yes, you are correct. I simplified a difficult problem. However, until SNMPv3 can have session keys with short lifetimes, the protocol is essentially unsecurable -- which is why I am currently seeking to secure SNMPv3 at a lower protocol layer (i.e., the beginning of this email thread). > > >The decision to use key localization was made because implementation and > >deployment experience with various flavours of SNMPv2 showed that using > >totally independent keys scaled badly. The assertion that key localization > >presents a point of attack is based on the assumption that compromising a localized > >key would provide information that would be useful in deriving either the initial > >passphrase or some other localized key. As far as I know, no one has been able > >to justify such an assumption. > > Yes, it is obvious that something had to be done to reduce the overhead burden of distributing two symmetric keys between each SNMP-agent and network-administrator pairing. SNMP adopted a creative solution to this problem. However, if the protocol were to be redesigned today, other solutions would be available, including the ones I mentioned in my email, which would offer greater protections and lower the existing administrative burden. For example, if SNMP were secured in a parallel manner as even one other IETF protocol, then the administrative burden for administrators supporting both protocols would be materially eased. > > The fact that the algorithmic relationship between the keys can be leveraged to break additional keys, once an original key has been broken, may or may not be evident to the readers of this email. Certainly, I am offering no proof, other than implying I have an idea for how to do so. However, this fact is far less important than fixing the primary weakness of the system, which is the lack of a viable session key mechanism, which exposes all the SNMPv3 keys to compromise, even if they hadn't had an underlying algorithmic relationship to leverage. > > >> These keys should be distributable > >> via already existing key distribution systems (e.g., Kerberos, PKI), perhaps by using "seed > >> key values", or else composite keys. In addition, whatever you do at the SNMPv3 application > >> layer should be designed to work with security provisions at another layer. > > >Sure, the architecture allows you to define other security models like these, but > >see the SNMPv3 WG archives for lots of reasons why one wouldn't want to mandate this. > > I am not telling your working group what algorithm or approach to use because these are weighty issues, far outside the scope of my posting. Rather, I am merely saying that the existing system is unsecurable unless supplemented by the security provisions of additional protocol layers. > > As you may recall, my original intent was not to question or debate SNMPv3 security at all, but rather to query the IETF list to see whether SSH port forwarding had been successfully used by others to partially secure SNMP. Has anybody on this list used SSH port forwarding for SNMP? If so, do you believe the approach to be viable or not? Was any other approach more successful? (Please respond directly to me because I am not yet a member of the snmpv3 list.) > > --Eric Bruno Dias Departamento de Inform=E1tica - Universidade do Minho Campus de Gualtar, 4710-057 Braga, PORTUGAL E-Mail Telef<+351 919 312 312> Fax<+351 253 604 471> --=====================_12906027==.ALT-- --=====================_101745742==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Approved: Dob.snmpv3 >From majordomo-owner Fri Aug 8 13:02:24 2003 Received: from smtp.netcabo.pt (smtp.netcabo.pt [212.113.174.9]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id NAA16217 Fri, 8 Aug 2003 13:02:22 -0400 (EDT) Received: from BRUNO-TOSH6100PRO.di.uminho.pt ([81.84.92.142]) by smtp.netcabo.pt with Microsoft SMTPSVC(5.0.2195.6713); Fri, 8 Aug 2003 18:09:04 +0100 Message-Id: <5.2.1.1.0.20030808160243.00b581e0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 08 Aug 2003 18:09:15 +0100 To: Bill Strahm , "Fleischman, Eric" From: Bruno Dias Subject: Re: SNMPv3 security Cc: Randy Presuhn , Uri Blumenthal , "Wijnen, Bert (Bert)" , Eliot Lear , "EXT-Weller, Michael K" , snmpv3@lists.tislabs.com In-Reply-To: <20030807165806.A6519@strahm.net> References: <5B58696DB20B9140AD20E0685C573A6402992DCA@xch-nw-09.nw.nos.boeing.com>= <5B58696DB20B9140AD20E0685C573A6402992DCA@xch-nw-09.nw.nos.boeing.c= om> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=3D&q= uot;=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D_12906027= =3D=3D.ALT" X-OriginalArrivalTime: 08 Aug 2003 17:09:04.0340 (UTC) FILETIME=3D[C5211940:01C35DCF] --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D_12906027= =3D=3D.ALT Content-Type: text/plain; charset=3D"iso-8859-1"; format=3Dflowed Content-Transfer-Encoding: quoted-printable At 21:58 07-08-2003, Bill Strahm wrote: >Ok, I have to ask... > >What security protocol defines session key timeout values as a part of the >standard. I certainly don't know of any including IPsec and SSL/TLS. All >things associated with session key timeouts resides within administrative >control as a policy on top of the protocol for example IKE negotiates >session key timeouts in the IPsec protocol, IPsec has nothing to do with=3D it, >now where does IKE get the value to negotiate for well that is a system=3D policy >set by the adminstrator, there isn't ANYTHING in the IKE RFCs that=3D determine >what value to negotiate. That said there are a HOST of research done on >the appropriate ammount of data to send under a key of given strength to >give an appropriate amount of security. With AES 128 my understanding is=3D that >it provides about 10000 years of protection given the current ramp of=3D hardware >and a governmental sized budget... The numbers grow exponentially to AES=3D 256. >Now there is quite a bit of research showing that AES may only be about=3D 1000th >the stength that it might be (known hacks at 9-10 rounds given a rediculous >amount of memory vs. the 16 rounds in the algorithm) so lets say AES 128 is >good to protect your management traffic for 10 years (1 year if they have=3D an >obscene budget)... is your management traffic THAT valuable after 1 year ? I just like the way the we're talking about these security protocols... Statements like "about 10000 years of protection given the current ramp of=3D =3D20 hardware and a governmental sized budget..." is quite funny for a non expert like me=3D =3D20 and a complete joke for a "network computer security professional" (yes, there's a lot more=3D20 about security on computer networks than cryptoanalisis!). I'd love to read the article where this was=3D =3D20 written... Eric was criticized by his apparent lack of cryptography background, but on=3D =3D20 a generic discussion about symmetric cripytography his toughts are a safer approach=3D20 than we all normally tend to assume... The "amount of data to send under a key of given strength to give an appropriate amount of security", as I understand it, is not exactly=3D =3D20 the same as the time of "protection" a key can assure. In fact, these are two=3D different types of security strengths. The first is about security strength to=3D20 cryptoanalisis attacks and the second is about security strength to brute force attacks. While the later is=3D20 "only" dependent on the key size vs computer power (you need to increase key size to figth the computer power=3D20 evolution), the first one is much more hard to evaluate but it is believed that the larger the amount=3D =3D20 of data analised the better are the chances to compromise the key. Well, on a communication=3D20 between two (or more) network entities the amount of data transmited, and prone to be=3D20 cryptoanalised, increases as time passes, so is the chance of the key to be compromised. Also, in general,=3D20 the amount of time need to crack a key by cryptoanalisis is much smaller than the brute=3D20 force attack when the some weekenesses are discovered on the crypto algorithm or on the key=3D itself. But the real intention beyond limited key time life spans has to do about=3D20 compromised keys due to bad key management (week key values, management applications and=3D20 operating systems security weekenesses, unsecure key storage, etc) than compromised keys from=3D =3D20 brute force or cryptoanalisis attacks. That's where a protocol imposing a limited key time life span (or key=3D20 sessions) woud help to reduce the amount of this data. Not such a bad (or new) idea... even if not directly applicable on current=3D =3D20 SNMP standards, but the regular changing of passphrases by some sort of application could be=3D20 usefull (as someone as already discovered *;o), although it brings some "third=3D20 party trust" security problems that makes this key distribution a not so simple matter... Regards, -- Bruno Dias >I have no idea why you don't think a simple application can't be written=3D that >will update SNMP passphrases as often as you want to on your network. Yes=3D it >will take protocol overhead time, but then so does renegotiating IPsec >session keys in IPsec. For that matter you can make it a simple policy on >either end of the control that automatically initiates a keychange when a >certain crypto quantia happens (up to after every other message, once for=3D the >key exchange, once to get data). This is simple software that has nothing=3D to >do with the underlying protocol - other than the underlying protocol allows >keys to be negotiated over it. > >Now I want to know who you are talking to that says proprietary algorithms >are trusted more than publicly available ones. I know of no serious crypto >researcher that believes this. That said, you might be using other=3D supplied >crypto for your custommers, if so, just plug the algorythm into your SNMPv3 >implementations and you are off to the races (I plugged in the AES=3D candidates >many years ago for fun, guess what it worked w/out an RFC, and the eventual >AES RFC looks just like my implementation of AES did, of course I had to >throw out the other candidates) > >Time to end my discussion for now... > >Bill Strahm > >On Thu, Aug 07, 2003 at 01:22:39PM -0700, Fleischman, Eric wrote: > > From: Randy Presuhn [<3d.htm>mailto:randy_presuhn@mindspring.com] > > >??? Key lifetime is under control of the user / security=3D20 > administrator. If you want to update > > >your keys every ten minutes, you can, though it doesn't address the=3D20 > more fundamental > > >question of the strength of the crypto algorithm > > > > >From my knothole, the most important information I have conveyed is=3D20 > that one must have Session Keys with very short lifetimes in order to=3D20 > reduce the amount of available ciphertext that can be used for=3D20 > cryptanalysis. Because SNMPv3 keys have indefinitely long lifetimes, a=3D20 > great deal of relevant ciphertext accumulates. For SNMPv3, the cracker=3D20 > knows that any communication between the same source and destination IP=3D20 > addresses has a high degree of probability of using the same DES=3D20 > encryption key -- especially if the attacker has operational information=3D =3D20 > about the types of systems (e.g., single user or multi-user) residing at=3D =3D20 > each IP address, which is not difficult to obtain. Thus, the cracker has=3D =3D20 > plenty of ciphertexts from which to apply cryptanalysis in order to break=3D =3D20 > the DES encryption keys. Once the session key has been broken, then the=3D20 > attacker can concentrate on cracking the authentication keys, which are=3D20 > "the keys to the kingdom", especially because of the weak authentica! > ti! >on approach used by SNMPv3 (e.g., no capability for two factor=3D20 >authentication thus anybody knowing the authentication key can freely=3D20 >pretend to be that administrator). > > > > It is therefore essential that the Session Key have a short lifetime in=3D =3D20 > order to reduce the amount of available ciphertext encrypted by the same=3D =3D20 > key and to introduce doubts whether any two ciphertexts were encrypted by=3D =3D20 > the same or different keys. This is the most fundamental defense=3D20 > available to us as SNMPv3 end users. > > > > Your statement above is disingenuous -- as I trust you knew when you=3D20 > wrote it. No user or security administrator can bear the overhead of=3D20 > redistributing tens of thousands of SNMPv3 passwords. They certainly=3D20 > can't regularly do this within an adequately short key lifetime quantum=3D20 > in order to make the current SNMPv3 approach begin to be viable. Egads!!! > > > > >> All you are doing by transitioning from using DES to AES is perhaps=3D =3D20 > delaying the bad guys a few > > >> hours before these keys are broken. That's almost nothing -- a false=3D =3D20 > sense of security that > > >>accomplishes little. > > > > >You must know something about AES that I don't. Any references to=3D20 > back up this claim > > >of relative lack of strength vis-a-vis DES? > > > > Randy, I am confident that you already know that TRIPLE-DES is usually=3D =3D20 > stronger than DES and that AES with long keys is stronger than=3D20 > TRIPLE-DES. However, you seem to think that any of these algorithms is=3D20 > adequately strong to defeat cryptanalysis done by a=20 security=3D20 > professional, even in environments with long key life and an abundance of=3D =3D20 > ciphertext. I am not at liberty to discuss this type of issue with you. I=3D =3D20 > realize that this may seem unfriendly or non-professional to you and I=3D20 > apologize for this perception. Rather, let's just recall together that=3D20 > communities exist who are not tremendously impressed with the strength of=3D =3D20 > non-classified algorithms, particularly in environments with substantial=3D =3D20 > amount of ciphertext available to the well-financed cracker. > > > > >> The interrelationship of the keys means that breaking one key=3D20 > greatly eases the breaking of them all, > > >> even if we are talking about dozens-of-remote-admins *=3D20 > thousands-of-SNMP-agents worth of keys, > > >> as we are in our system. The whole thing can be rolled up fairly=3D20 > quickly by security professionals > > >> because encryption in SNMPv3 is being applied in a barefoot manner. > > > > >It sounds like you're assuming that the key localization algorithm is=3D =3D20 > insufficiently one-way. > > >I know there's been some speculation that MD5 might be inadequate for=3D =3D20 > this purpose, > > >but has anyone actually demonstrated it? In any case, I think Uri's=3D20 > AES i-d addresses > > >this (at least earlier versions did). > > > > The current approach presumes that SHA-1 or MD5 hashes provide enough=3D20 > key randomization to thwart the underlying algorithmic relationship=3D20 > between these keys. I can understand why you may think this. However, if=3D =3D20 > you spent some time figuring out how to break these keys, then a=3D20 > possibility exists that you perhaps may agree with me that this=3D20 > underlying relationship provides a helpful mechanism to exploit for=3D20 > breaking these keys, particularly with a great abundance of ciphertext to=3D =3D20 > work with. > > > > >> The only way this can be remedied is not by doing minor tweaks of=3D20 > encryption algorithms > > >> but rather by redesigning the security system to place it upon a=3D20 > solid footing. Session > > >> Keys should have very short, finite lifetimes. > > > > >Nice in theory, but brings other costs and other risks, like > > >the possibility that session establishment will fail in highly > > >stressed networks. > > > > Yes, you are correct. I simplified a difficult problem. However, until=3D =3D20 > SNMPv3 can have session keys with short lifetimes, the protocol is=3D20 > essentially unsecurable -- which is why I am currently seeking to secure=3D =3D20 > SNMPv3 at a lower protocol layer (i.e., the beginning of this email=3D thread). > > > > >The decision to use key localization was made because implementation=3D and > > >deployment experience with various flavours of SNMPv2 showed that using > > >totally independent keys scaled badly. The assertion that key=3D20 > localization > > >presents a point of attack is based on the assumption that=3D20 > compromising a localized > > >key would provide information that would be useful in deriving either=3D =3D20 > the initial > > >passphrase or some other localized key. As far as I know, no one has=3D =3D20 > been able > > >to justify such an assumption. > > > > Yes, it is obvious that something had to be done to reduce the overhead=3D =3D20 > burden of distributing two symmetric keys between each SNMP-agent and=3D20 > network-administrator pairing. SNMP adopted a creative solution to this=3D20 > problem. However, if the protocol were to be redesigned today, other=3D20 > solutions would be available, including the ones I mentioned in my email,=3D =3D20 > which would offer greater protections and lower the=20 existing=3D20 > administrative burden. For example, if SNMP were secured in a parallel=3D20 > manner as even one other IETF protocol, then the administrative burden=3D20 > for administrators supporting both protocols would be materially eased. > > > > The fact that the algorithmic relationship between the keys can be=3D20 > leveraged to break additional keys, once an original key has been broken,=3D =3D20 > may or may not be evident to the readers of this email. Certainly, I am=3D20 > offering no proof, other than implying I have an idea for how to do so.=3D20 > However, this fact is far less important than fixing the primary weakness=3D =3D20 > of the system, which is the lack of a viable session key mechanism, which=3D =3D20 > exposes all the SNMPv3 keys to compromise, even if they hadn't had an=3D20 > underlying algorithmic relationship to leverage. > > > > >> These keys should be distributable > > >> via already existing key distribution systems (e.g., Kerberos, PKI),=3D =3D20 > perhaps by using "seed > > >> key values", or else composite keys. In addition, whatever you do at=3D =3D20 > the SNMPv3 application > > >> layer should be designed to work with security provisions at another=3D =3D20 > layer. > > > > >Sure, the architecture allows you to define other security models like=3D =3D20 > these, but > > >see the SNMPv3 WG archives for lots of reasons why one wouldn't want=3D20 > to mandate this. > > > > I am not telling your working group what algorithm or approach to use=3D20 > because these are weighty issues, far outside the scope of my posting.=3D20 > Rather, I am merely saying that the existing system is unsecurable unless=3D =3D20 > supplemented by the security provisions of additional protocol layers. > > > > As you may recall, my original intent was not to question or debate=3D20 > SNMPv3 security at all, but rather to query the IETF list to see whether=3D =3D20 > SSH port forwarding had been successfully used by others to partially=3D20 > secure SNMP. Has anybody on this list used SSH port forwarding for SNMP?=3D =3D20 > If so, do you believe the approach to be viable or not? Was any other=3D20 > approach more successful? (Please respond directly to me because I am not=3D =3D20 > yet a member of the snmpv3 list.) > > > > --Eric Bruno Dias Departamento de Inform=3DE1tica - Universidade do Minho Campus de Gualtar, 4710-057 Braga, PORTUGAL E-Mail Telef<+351 919 312 312> Fax<+351 253 604=3D 471> --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D_12906027= =3D=3D.ALT Content-Type: text/html; charset=3D"iso-8859-1" Content-Transfer-Encoding: quoted-printable At 21:58 07-08-2003, Bill Strahm wrote: Ok, I have to ask... What security protocol defines session key timeout values as a part of the standard. I certainly don't know of any including IPsec and SSL/TLS. All=20 things associated with session key timeouts resides within administrative=20 control as a policy on top of the protocol for example IKE negotiates=20 session key timeouts in the IPsec protocol, IPsec has nothing to do with it, now where does IKE get the value to negotiate for well that is a system policy set by the adminstrator, there isn't ANYTHING in the IKE RFCs that determine what value to negotiate. That said there are a HOST of research done on=20 the appropriate ammount of data to send under a key of given strength to=20 give an appropriate amount of security. With AES 128 my understanding is that it provides about 10000 years of protection given the current ramp of hardware and a governmental sized budget... The numbers grow exponentially to AES 256. Now there is quite a bit of research showing that AES may only be about 1000th the stength that it might be (known hacks at 9-10 rounds given a rediculous amount of memory vs. the 16 rounds in the algorithm) so lets say AES 128 is good to protect your management traffic for 10 years (1 year if they have an obscene budget)... is your management traffic THAT valuable after 1 year ? I just like the way the we're talking about these security protocols... Statements like "about 10000 years of protection given the current ramp of hardware and a governmental sized budget..." is quite funny for a non expert like me and a complete joke for a "network computer security professional" (yes, there's a lot more about security on computer networks than cryptoanalisis!). I'd love to read the article where this was written... Eric was criticized by his apparent lack of cryptography background, but on a generic discussion about symmetric cripytography his toughts are a safer approach than we all normally tend to assume... The "amount of data to send under a key of given strength to give an appropriate amount of security", as I understand it, is not exactly the same as the time of "protection" a key can assure. In fact, these are two different types of security strengths. The first is about security strength to cryptoanalisis attacks and the second is about security strength to brute force attacks. While the later is "only" dependent on the key size vs computer power (you need to increase key size to figth the computer power evolution), the first one is much more hard to evaluate but it is believed that the larger the amount of data analised the better are the chances to compromise the key. Well, on a communication between two (or more) network entities the amount of data transmited, and prone to be cryptoanalised, increases as time passes, so is the chance of the key to be compromised. Also, in general, the amount of time need to crack a key by cryptoanalisis is much smaller than the brute force attack when the some weekenesses are discovered on the crypto algorithm or on the key itself. But the real intention beyond limited key time life spans has to do about compromised keys due to bad key management (week key values, management applications and operating systems security weekenesses, unsecure key storage, etc) than compromised keys from brute force or cryptoanalisis attacks. That's where a protocol imposing a limited key time life span (or key sessions) woud help to reduce the amount of this data. Not such a bad (or new) idea... even if not directly applicable on current SNMP standards, but the regular changing of passphrases by some sort of application could be usefull (as someone as already discovered *;o), although it brings some "third party trust" security problems that makes this key distribution a not so simple matter... Regards, -- Bruno Dias I have no idea why =3D you don't think a simple application can't be written that will update SNMP passphrases as often as you want to on your network. Yes it will take protocol overhead time, but then so does renegotiating IPsec=20 session keys in IPsec. For that matter you can make it a simple policy on=20 either end of the control that automatically initiates a keychange when a=20 certain crypto quantia happens (up to after every other message, once for the key exchange, once to get data). This is simple software that has nothing to do with the underlying protocol - other than the underlying protocol allows keys to be negotiated over it. Now I want to know who you are talking to that says proprietary algorithms are trusted more than publicly available ones. I know of no serious crypto researcher that believes this. That said, you might be using other supplied crypto for your custommers, if so, just plug the algorythm into your SNMPv3 implementations and you are off to the races (I plugged in the AES candidates many years ago for fun, guess what it worked w/out an RFC, and the eventual AES RFC looks just like my implementation of AES did, of course I had to=20 throw out the other candidates) Time to end my discussion for now... Bill Strahm On Thu, Aug 07, 2003 at 01:22:39PM -0700, Fleischman, Eric wrote: > From: Randy Presuhn [<3d.htm>mailto:randy_presuhn@mindspring.com] > >??? Key lifetime is under control of the user / security administrator. If you want to update > >your keys every ten minutes, you can, though it doesn't address the more fundamental > >question of the strength of the crypto algorithm >=20 > >From my knothole, the most important information I have conveyed is that one must have Session Keys with very short lifetimes in order to reduce the amount of available ciphertext that can be used for cryptanalysis. Because SNMPv3 keys have indefinitely long lifetimes, a great deal of relevant ciphertext accumulates. For SNMPv3, the cracker knows that any communication between the same source and destination IP addresses has a high degree of probability of using the same DES encryption key -- especially if the attacker has operational information about the types of systems (e.g., single user or multi-user) residing at each IP address, which is not difficult to obtain. Thus, the cracker has plenty of ciphertexts from which to apply cryptanalysis in order to break the DES encryption keys. Once the session key has been broken, then the attacker can concentrate on cracking the authentication keys, which are "the keys to the kingdom", especially because of the weak authentica! ! ti! on approach used by SNMPv3 (e.g., no capability for two factor authentication thus anybody knowing the authentication key can freely pretend to be that administrator). >=20 > It is therefore essential that the Session Key have a short lifetime in order to reduce the amount of available ciphertext encrypted by the same key and to introduce doubts whether any two ciphertexts were encrypted by the same or different keys. This is the most fundamental defense available to us as SNMPv3 end users.=20 >=20 > Your statement above is disingenuous -- as I trust you knew when you wrote it. No user or security administrator can bear the overhead of redistributing tens of thousands of SNMPv3 passwords. They certainly can't regularly do this within an adequately short key lifetime quantum in order to make the current SNMPv3 approach begin to be viable. Egads!!!=20 >=20 > >> All you are doing by transitioning from using DES to AES is perhaps delaying the bad guys a few > >> hours before these keys are broken. That's almost nothing -- a false sense of security that=20 > >>accomplishes little. >=20 > >You must know something about AES that I don't. Any references to back up this claim > >of relative lack of strength vis-a-vis DES? >=20 > Randy, I am confident that you already know that TRIPLE-DES is usually stronger than DES and that AES with long keys is stronger than TRIPLE-DES. However, you seem to think that any of these algorithms is adequately strong to defeat cryptanalysis done by a security professional, even in environments with long key life and an abundance of ciphertext. I am not at liberty to discuss this type of issue with you. I realize that this may seem unfriendly or non-professional to you and I apologize for this perception. Rather, let's just recall together that communities exist who are not tremendously impressed with the strength of non-classified algorithms, particularly in environments with substantial amount of ciphertext available to the well-financed cracker. >=20 > >> The interrelationship of the keys means that breaking one key greatly eases the breaking of them all, > >> even if we are talking about dozens-of-remote-admins * thousands-of-SNMP-agents worth of keys, > >> as we are in our system. The whole thing can be rolled up fairly quickly by security professionals > >> because encryption in SNMPv3 is being applied in a barefoot manner. >=20 > >It sounds like you're assuming that the key localization algorithm is insufficiently one-way. > >I know there's been some speculation that MD5 might be inadequate for this purpose, > >but has anyone actually demonstrated it? In any case, I think Uri's AES i-d addresses > >this (at least earlier versions did). >=20 > The current approach presumes that SHA-1 or MD5 hashes provide enough key randomization to thwart the underlying algorithmic relationship between these keys. I can understand why you may think this. However, if you spent some time figuring out how to break these keys, then a possibility exists that you perhaps may agree with me that this underlying relationship provides a helpful mechanism to exploit for breaking these keys, particularly with a great abundance of ciphertext to work with. >=20 > >> The only way this can be remedied is not by doing minor tweaks of encryption algorithms > >> but rather by redesigning the security system to place it upon a solid footing. Session > >> Keys should have very short, finite lifetimes. >=20 > >Nice in theory, but brings other costs and other risks, like > >the possibility that session establishment will fail in highly > >stressed networks. >=20 > Yes, you are correct. I simplified a difficult problem. However, until SNMPv3 can have session keys with short lifetimes, the protocol is essentially unsecurable -- which is why I am currently seeking to secure SNMPv3 at a lower protocol layer (i.e., the beginning of this email thread). >=20 > >The decision to use key localization was made because implementation and > >deployment experience with various flavours of SNMPv2 showed that using > >totally independent keys scaled badly. The assertion that key localization > >presents a point of attack is based on the assumption that compromising a localized > >key would provide information that would be useful in deriving either the initial > >passphrase or some other localized key. As far as I know, no one has been able > >to justify such an assumption. >=20 > Yes, it is obvious that something had to be done to reduce the overhead burden of distributing two symmetric keys between each SNMP-agent and network-administrator pairing. SNMP adopted a creative solution to this problem. However, if the protocol were to be redesigned today, other solutions would be available, including the ones I mentioned in my email, which would offer greater protections and lower the existing administrative burden. For example, if SNMP were secured in a parallel manner as even one other IETF protocol, then the administrative burden for administrators supporting both protocols would be materially eased.=20 >=20 > The fact that the algorithmic relationship between the keys can be leveraged to break additional keys, once an original key has been broken, may or may not be evident to the readers of this email. Certainly, I am offering no proof, other than implying I have an idea for how to do so. However, this fact is far less important than fixing the primary weakness of the system, which is the lack of a viable session key mechanism, which exposes all the SNMPv3 keys to compromise, even if they hadn't had an underlying algorithmic relationship to leverage. >=20 > >> These keys should be distributable > >> via already existing key distribution systems (e.g., Kerberos, PKI), perhaps by using "seed > >> key values", or else composite keys. In addition, whatever you do at the SNMPv3 application > >> layer should be designed to work with security provisions at another layer. >=20 > >Sure, the architecture allows you to define other security models like these, but > >see the SNMPv3 WG archives for lots of reasons why one wouldn't want to mandate this. >=20 > I am not telling your working group what algorithm or approach to use because these are weighty issues, far outside the scope of my posting. Rather, I am merely saying that the existing system is unsecurable unless supplemented by the security provisions of additional protocol layers.=20 >=20 > As you may recall, my original intent was not to question or debate SNMPv3 security at all, but rather to query the IETF list to see whether SSH port forwarding had been successfully used by others to partially secure SNMP. Has anybody on this list used SSH port forwarding for SNMP? If so, do you believe the approach to be viable or not? Was any other approach more successful? (Please respond directly to me because I am not yet a member of the snmpv3 list.) >=20 > --Eric Bruno Dias Departamento de Inform=3DE1tica - Universidade do Minho Campus de Gualtar, 4710-057 Braga, PORTUGAL E-Mail Telef<+351 919 312 312> Fax<+351 253 604 471> --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D_129060= 27=3D=3D.ALT-- --=====================_101745742==_.ALT-- From owner-snmpv3@lists.tislabs.com Fri Aug 8 14:31:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20179 for ; Fri, 8 Aug 2003 14:31:53 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16544 Fri, 8 Aug 2003 13:39:28 -0400 (EDT) To: Bruno Dias , Bill Strahm , "Fleischman, Eric" Cc: Randy Presuhn , Uri Blumenthal , "Wijnen, Bert (Bert)" , Eliot Lear , "EXT-Weller, Michael K" , snmpv3@lists.tislabs.com Content-Type: text/plain; charset="windows-1251" From: Uri Blumenthal Original-To: Bruno Dias , Bill Strahm , "Fleischman, Eric" Subject: Re: SNMPv3 security Date: Fri, 8 Aug 2003 13:54:36 -0400 User-Agent: KMail/1.4.1 Original-Cc: Randy Presuhn , Uri Blumenthal , "Wijnen, Bert (Bert)" , Eliot Lear , "EXT-Weller, Michael K" , snmpv3@lists.tislabs.com References: <5B58696DB20B9140AD20E0685C573A6402992DCA@xch-nw-09.nw.nos.boeing.com> <5.2.1.1.0.20030808160243.00b581e0@localhost> In-Reply-To: <5.2.1.1.0.20030808160243.00b581e0@localhost> MIME-Version: 1.0 Message-Id: <200308081354.36700.uri@elliptic> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA16540 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit On Friday 08 August 2003 01:09 pm, Bruno Dias wrote: > I just like the way the we're talking about these security protocols... > Statements like "about 10000 years of protection given the current ramp of > hardware and a governmental sized budget..." is quite funny for a non > expert like me and a complete joke > for a "network computer security professional" No, not a complete joke. > (yes, there's a lot more about security on computer > networks than cryptoanalisis!). Yes. Still, cryptography is the heart of network security. > I'd love to read the article where this was written... Consider "Report on the Development of the AES" by NIST. Not quite the same language, but similar idea. > Eric was criticized by his apparent lack of cryptography background, No, by the apparent lack of (a) cryptographic, (b) security, and (c) SNMP background. > but on a generic discussion about symmetric cripytography his > toughts are a safer approach than we all normally tend to assume... Safety can be overblown - it is then called paranoia (no personal offence made or implied to anybody here). > The "amount of data to send under a key of given strength to > give an appropriate amount of security", as I understand it, > is not exactly the same as the time of "protection" a key > can assure. Of course it is. What you should have said is "key strength is not the same as key length". > ....... is believed that the larger the amount > of data analised the better are the chances to compromise the key. Of course (a great discovery, though not exactly new). Ultimately, when one collects an entire codebook - no key is necessary any more. > Also, in general, > the amount of time need to crack a key by cryptoanalisis is much smaller > than the brute force attack when the some weekenesses are discovered on > the crypto algorithm or on the key itself. This really depends on the algorithm in question. For DES it is: you need about 2^40 known plaintext pairs and must perform about 2^45 operations - smaller than 2^55 operations for exhaustive key search (though in the last case you need only one known plaintext pair,, not 2^40). For AES there is no such known weakness/attack - so one can keep collecting traffic. > But the real intention beyond limited key time life spans has to do > about compromised keys due to bad key management (week key values, > management applications and operating systems security weekenesses, > unsecure key storage, etc)...... This is very true. And to defend adequately from this kind of threat, keys have to possess PFS property. In short, this is where you involve Diffie-Hellman algorithm. > Not such a bad (or new) idea... even if not directly applicable > on current SNMP standards, It requires (a) adding one to four MIB objects to usmUserTable (or augmenting the last one), (b) new algorithm (or Textual Convention), and that's about it. Oh, and an implementation... > but > the regular changing of passphrases by some sort of application could be > usefull > (as someone as already discovered *;o), although it brings some "third > party trust" security problems > that makes this key distribution a not so simple matter... Not quite - SNMP is inherently asymmetric, so most of the intelligence lives in the NMS. I doubt this paradigm is ready to be discarded. From owner-snmpv3@lists.tislabs.com Fri Aug 8 14:32:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20241 for ; Fri, 8 Aug 2003 14:32:50 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16512 Fri, 8 Aug 2003 13:38:11 -0400 (EDT) To: Uri Blumenthal Cc: "Randy Presuhn" , "Fleischman, Eric" , "Uri Blumenthal" , "Wijnen, Bert (Bert)" , , "Eliot Lear" , "EXT-Weller, Michael K" , Subject: Re: SNMPv3 security References: <5B58696DB20B9140AD20E0685C573A6402992DC9@xch-nw-09.nw.nos.boeing.com> <00c001c35d10$50a730a0$7f1afea9@oemcomputer> <200308081332.17029.uri@elliptic> From: Wes Hardaker Organization: Sparta Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXotKX87e8eDA4GAQbQgmlzNycHAwizYkruzul2AAACaUlEQVR4nFXUTW/jIBAGYFI56jWutuq1S9b2dddW6dWtQFxbq4jzwq73Glmg+fv7DiT9QJGS+GEGhiER67TWEQ5CtOeh21ZcIIbmOPq5QvMZYlyV6u+/gsJLTSrGIL/CxEPxQuPAcP0JYlQsq3x5B3UJmUaEyB6yZ+CQ+pwXCzKsbXtbIhg4KtZypPz+AVGtlxH69c87qAqRY6Rc5QUmZMGeAj+TfVjjUwE1lflKys5JGXpM+V0hltqCJ0qL7Plkft4wRM6lxi5p3Wyy7O7fB8TgtdZivxy5rvAB6wSYhbA9vn+GOCaOEGJRPO2mHgk+q1Chyf0Up3AG0NjhOXI19ogEFziq6M+ZtN3kUZ13NW4qUCprC3CW668C06M5jihON1Vsjq8F1CPJB8LINNeQfscwxUEvAwM5Xghvsq2pBr3hnKhbDIrMS3cBRDx70uS9JW2dy667gM0AbZFFmyvn3GOBGB8wG9kppaSNz357LaCmUdtSny5LU9qeCrglvJmyH20TwkjnXQE0usscIWayCWZJ7OpZ4QbUVGRnhuTub3cMYRk99oSplDIfibzfn0FyXyk7z8XThuvC0P/dGCwee7O8aZJBmh0vPixy0NrYhDaR02aR3W0BbyT6h23OB5Hzybj+DOm5w6XCOZG13p5Oh/bursJVh9S+bBiFnPCDuntpcTH080AO+7GlW1i3bRphBM04dZ2dI6yMLjmGFqnIok/cB1YU8sJAACTeuHOd5+lumQHfDM6KyLqEm4aWkkcc1m4PqBewZxBZOg44lT+aJiexDteewboiVhxAjSHxQwhiYJEdCR6tMN1/uckirDRNbsgAAAAASUVORK5CYII= Date: Fri, 08 Aug 2003 10:45:30 -0700 In-Reply-To: <200308081332.17029.uri@elliptic> (Uri Blumenthal's message of "Fri, 8 Aug 2003 13:32:17 -0400") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk >>>>> On Fri, 8 Aug 2003 13:32:17 -0400, Uri Blumenthal said: Uri> And if the key update is not controlled by the manager and the box Uri> got disconnected or DoS'ed - how will the box and the manager run Uri> their key renegtiation? They can't. I didn't say this should be mandatory to use (which you seem to think I was saying). The option should be there, however (which you later agreed with, so your statement above is a bit odd). Point being, is that if I want a key lifetime of 1 week, for example, I'd likely renegotiate daily (for example) and if I failed that for an entire week, I probably don't want the box to respond to anyone as there is likely a severe problem with it and I'll want to scrub it. >> that can sever the network connection (a simple DoS attack would >> suffice for this) between the manager and the agent can then spend >> all the time the needs to figure out the keys and access the >> contents of the box. Uri> How? By sending messages to the box and watching how the box Uri> responds? Many ways. We both agree that attacking the current algorithms is not an efficient way to go about it. However, attacking via human passwd->key conversions works (and hence shouldn't be used but as you yourself stated, people do it). Attacking the humans themselves work as well (wait till they get off work and threaten them outside their secured work environment to get the key that the replacement operators changed on all the boxes "they could get to"). ... >> This is a big difference between other protocols (kerberos, IKE, etc) >> that hold a key to a given lifetime at the box itself. Uri> I agree that it may be a good idea to add a MIB object "keyLifeTime" Uri> measured in bytes, 64-bit counter. Agreed almost. A configurable integer might wiser, however (again, it doesn't mean you can't turn of write-access to it if you don't want it remotely manageable). >> IE, after a period of time the box itself refuses to reuse the key >> in question. Uri> OK, from security point of view it's fine. In practical language it Uri> may mean that somebody has to go to the device and change the Uri> key. Only in the extreme cases where you fail to update the key remotely. -- Wes Hardaker Sparta From owner-snmpv3@lists.tislabs.com Fri Aug 8 14:37:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20379 for ; Fri, 8 Aug 2003 14:37:11 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16600 Fri, 8 Aug 2003 13:46:22 -0400 (EDT) To: Uri Blumenthal Cc: "Randy Presuhn" , "Fleischman, Eric" , "Uri Blumenthal" , "Wijnen, Bert (Bert)" , , "Eliot Lear" , "EXT-Weller, Michael K" , Subject: Re: SNMPv3 security References: <5B58696DB20B9140AD20E0685C573A6402992DC9@xch-nw-09.nw.nos.boeing.com> <00c001c35d10$50a730a0$7f1afea9@oemcomputer> <200308081332.17029.uri@elliptic> From: Wes Hardaker Organization: Sparta Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXotKX87e8eDA4GAQbQgmlzNycHAwizYkruzul2AAACaUlEQVR4nFXUTW/jIBAGYFI56jWutuq1S9b2dddW6dWtQFxbq4jzwq73Glmg+fv7DiT9QJGS+GEGhiER67TWEQ5CtOeh21ZcIIbmOPq5QvMZYlyV6u+/gsJLTSrGIL/CxEPxQuPAcP0JYlQsq3x5B3UJmUaEyB6yZ+CQ+pwXCzKsbXtbIhg4KtZypPz+AVGtlxH69c87qAqRY6Rc5QUmZMGeAj+TfVjjUwE1lflKys5JGXpM+V0hltqCJ0qL7Plkft4wRM6lxi5p3Wyy7O7fB8TgtdZivxy5rvAB6wSYhbA9vn+GOCaOEGJRPO2mHgk+q1Chyf0Up3AG0NjhOXI19ogEFziq6M+ZtN3kUZ13NW4qUCprC3CW668C06M5jihON1Vsjq8F1CPJB8LINNeQfscwxUEvAwM5Xghvsq2pBr3hnKhbDIrMS3cBRDx70uS9JW2dy667gM0AbZFFmyvn3GOBGB8wG9kppaSNz357LaCmUdtSny5LU9qeCrglvJmyH20TwkjnXQE0usscIWayCWZJ7OpZ4QbUVGRnhuTub3cMYRk99oSplDIfibzfn0FyXyk7z8XThuvC0P/dGCwee7O8aZJBmh0vPixy0NrYhDaR02aR3W0BbyT6h23OB5Hzybj+DOm5w6XCOZG13p5Oh/bursJVh9S+bBiFnPCDuntpcTH080AO+7GlW1i3bRphBM04dZ2dI6yMLjmGFqnIok/cB1YU8sJAACTeuHOd5+lumQHfDM6KyLqEm4aWkkcc1m4PqBewZxBZOg44lT+aJiexDteewboiVhxAjSHxQwhiYJEdCR6tMN1/uckirDRNbsgAAAAASUVORK5CYII= Date: Fri, 08 Aug 2003 10:53:36 -0700 In-Reply-To: <200308081332.17029.uri@elliptic> (Uri Blumenthal's message of "Fri, 8 Aug 2003 13:32:17 -0400") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk >>>>> On Fri, 8 Aug 2003 13:32:17 -0400, Uri Blumenthal said: Uri> And if the key update is not controlled by the manager and the box Uri> got disconnected or DoS'ed - how will the box and the manager run Uri> their key renegtiation? Oh, and I meant to add "using a public-key based renegotiation", IE a DH based re-init would also work. -- Wes Hardaker Sparta From owner-snmpv3@lists.tislabs.com Fri Aug 8 14:47:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20952 for ; Fri, 8 Aug 2003 14:47:53 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16680 Fri, 8 Aug 2003 13:57:58 -0400 (EDT) Message-Id: <5.2.1.1.0.20030808184932.00b87770@wheresmymailserver.com> X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 08 Aug 2003 18:55:14 +0100 To: Bill Strahm , "Fleischman, Eric" From: Bruno Dias Subject: Re: SNMPv3 security Cc: Randy Presuhn , Uri Blumenthal , "Wijnen, Bert (Bert)" , Eliot Lear , "EXT-Weller, Michael K" , snmpv3@lists.tislabs.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_15668600==.ALT" X-OriginalArrivalTime: 08 Aug 2003 17:55:06.0910 (UTC) FILETIME=[33BFD3E0:01C35DD6] Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk --=====================_15668600==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable [The first time the message seemed trashed, at least on my mail reader...] [I'll email it again... Sorry for the duplicate.] At 21:58 07-08-2003, Bill Strahm wrote: >Ok, I have to ask... > >What security protocol defines session key timeout values as a part of the >standard. I certainly don't know of any including IPsec and SSL/TLS. All >things associated with session key timeouts resides within administrative >control as a policy on top of the protocol for example IKE negotiates >session key timeouts in the IPsec protocol, IPsec has nothing to do with= it, >now where does IKE get the value to negotiate for well that is a system= policy >set by the adminstrator, there isn't ANYTHING in the IKE RFCs that= determine >what value to negotiate. That said there are a HOST of research done on >the appropriate ammount of data to send under a key of given strength to >give an appropriate amount of security. With AES 128 my understanding is= that >it provides about 10000 years of protection given the current ramp of= hardware >and a governmental sized budget... The numbers grow exponentially to AES= 256. >Now there is quite a bit of research showing that AES may only be about= 1000th >the stength that it might be (known hacks at 9-10 rounds given a rediculous >amount of memory vs. the 16 rounds in the algorithm) so lets say AES 128 is >good to protect your management traffic for 10 years (1 year if they have= an >obscene budget)... is your management traffic THAT valuable after 1 year ? I just like the way the we're talking about these security protocols... Statements like "about 10000 years of protection given the current ramp of= =20 hardware and a governmental sized budget..." is quite funny for a non expert like me= =20 and a complete joke for a "network computer security professional" (yes, there's a lot more=20 about security on computer networks than cryptoanalisis!). I'd love to read the article where this was= =20 written... Eric was criticized by his apparent lack of cryptography background, but on= =20 a generic discussion about symmetric cripytography his toughts are a safer approach=20 than we all normally tend to assume... The "amount of data to send under a key of given strength to give an appropriate amount of security", as I understand it, is not exactly= =20 the same as the time of "protection" a key can assure. In fact, these are two= different types of security strengths. The first is about security strength to=20 cryptoanalisis attacks and the second is about security strength to brute force attacks. While the later is=20 "only" dependent on the key size vs computer power (you need to increase key size to figth the computer power=20 evolution), the first one is much more hard to evaluate but it is believed that the larger the amount= =20 of data analised the better are the chances to compromise the key. Well, on a communication=20 between two (or more) network entities the amount of data transmited, and prone to be=20 cryptoanalised, increases as time passes, so is the chance of the key to be compromised. Also, in general,=20 the amount of time need to crack a key by cryptoanalisis is much smaller than the brute=20 force attack when the some weekenesses are discovered on the crypto algorithm or on the key= itself. But the real intention beyond limited key time life spans has to do about=20 compromised keys due to bad key management (week key values, management applications and=20 operating systems security weekenesses, unsecure key storage, etc) than compromised keys from= =20 brute force or cryptoanalisis attacks. That's where a protocol imposing a limited key time life span (or key=20 sessions) woud help to reduce the amount of this data. Not such a bad (or new) idea... even if not directly applicable on current= =20 SNMP standards, but the regular changing of passphrases by some sort of application could be=20 usefull (as someone as already discovered *;o), although it brings some "third=20 party trust" security problems that makes this key distribution a not so simple matter... Regards, -- Bruno Dias >I have no idea why you don't think a simple application can't be written= that >will update SNMP passphrases as often as you want to on your network. Yes= it >will take protocol overhead time, but then so does renegotiating IPsec >session keys in IPsec. For that matter you can make it a simple policy on >either end of the control that automatically initiates a keychange when a >certain crypto quantia happens (up to after every other message, once for= the >key exchange, once to get data). This is simple software that has nothing= to >do with the underlying protocol - other than the underlying protocol allows >keys to be negotiated over it. > >Now I want to know who you are talking to that says proprietary algorithms >are trusted more than publicly available ones. I know of no serious crypto >researcher that believes this. That said, you might be using other= supplied >crypto for your custommers, if so, just plug the algorythm into your SNMPv3 >implementations and you are off to the races (I plugged in the AES= candidates >many years ago for fun, guess what it worked w/out an RFC, and the eventual >AES RFC looks just like my implementation of AES did, of course I had to >throw out the other candidates) > >Time to end my discussion for now... > >Bill Strahm Bruno Dias Departamento de Inform=E1tica - Universidade do Minho Campus de Gualtar, 4710-057 Braga, PORTUGAL E-Mail Telef<+351 919 312 312> Fax<+351 253 604= 471> --=====================_15668600==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [The first time the message seemed trashed, at least on my mail reader...] [I'll email it again... Sorry for the duplicate.] At 21:58 07-08-2003, Bill Strahm wrote: Ok, I have to ask... What security protocol defines session key timeout values as a part of the standard. I certainly don't know of any including IPsec and SSL/TLS. All things associated with session key timeouts resides within administrative control as a policy on top of the protocol for example IKE negotiates session key timeouts in the IPsec protocol, IPsec has nothing to do with it, now where does IKE get the value to negotiate for well that is a system policy set by the adminstrator, there isn't ANYTHING in the IKE RFCs that determine what value to negotiate. That said there are a HOST of research done on the appropriate ammount of data to send under a key of given strength to give an appropriate amount of security. With AES 128 my understanding is that it provides about 10000 years of protection given the current ramp of hardware and a governmental sized budget... The numbers grow exponentially to AES 256. Now there is quite a bit of research showing that AES may only be about 1000th the stength that it might be (known hacks at 9-10 rounds given a rediculous amount of memory vs. the 16 rounds in the algorithm) so lets say AES 128 is good to protect your management traffic for 10 years (1 year if they have an obscene budget)... is your management traffic THAT valuable after 1 year ? I just like the way the we're talking about these security protocols... Statements like "about 10000 years of protection given the current ramp of hardware and a governmental sized budget..." is quite funny for a non expert like me and a complete joke for a "network computer security professional" (yes, there's a lot more about security on computer networks than cryptoanalisis!). I'd love to read the article where this was written... Eric was criticized by his apparent lack of cryptography background, but on a generic discussion about symmetric cripytography his toughts are a safer approach than we all normally tend to assume... The "amount of data to send under a key of given strength to give an appropriate amount of security", as I understand it, is not exactly the same as the time of "protection" a key can assure. In fact, these are two different types of security strengths. The first is about security strength to cryptoanalisis attacks and the second is about security strength to brute force attacks. While the later is "only" dependent on the key size vs computer power (you need to increase key size to figth the computer power evolution), the first one is much more hard to evaluate but it is believed that the larger the amount of data analised the better are the chances to compromise the key. Well, on a communication between two (or more) network entities the amount of data transmited, and prone to be cryptoanalised, increases as time passes, so is the chance of the key to be compromised. Also, in general, the amount of time need to crack a key by cryptoanalisis is much smaller than the brute force attack when the some weekenesses are discovered on the crypto algorithm or on the key itself. But the real intention beyond limited key time life spans has to do about compromised keys due to bad key management (week key values, management applications and operating systems security weekenesses, unsecure key storage, etc) than compromised keys from brute force or cryptoanalisis attacks. That's where a protocol imposing a limited key time life span (or key sessions) woud help to reduce the amount of this data. Not such a bad (or new) idea... even if not directly applicable on current SNMP standards, but the regular changing of passphrases by some sort of application could be usefull (as someone as already discovered *;o), although it brings some "third party trust" security problems that makes this key distribution a not so simple matter... Regards, -- Bruno Dias I have no idea why you don't think a simple application can't be written that will update SNMP passphrases as often as you want to on your network. Yes it will take protocol overhead time, but then so does renegotiating IPsec session keys in IPsec. For that matter you can make it a simple policy on either end of the control that automatically initiates a keychange when a certain crypto quantia happens (up to after every other message, once for the key exchange, once to get data). This is simple software that has nothing to do with the underlying protocol - other than the underlying protocol allows keys to be negotiated over it. Now I want to know who you are talking to that says proprietary algorithms are trusted more than publicly available ones. I know of no serious crypto researcher that believes this. That said, you might be using other supplied crypto for your custommers, if so, just plug the algorythm into your SNMPv3 implementations and you are off to the races (I plugged in the AES candidates many years ago for fun, guess what it worked w/out an RFC, and the eventual AES RFC looks just like my implementation of AES did, of course I had to throw out the other candidates) Time to end my discussion for now... Bill Strahm Bruno Dias Departamento de Inform=E1tica - Universidade do Minho Campus de Gualtar, 4710-057 Braga, PORTUGAL E-Mail Telef<+351 919 312 312> Fax<+351 253 604 471> --=====================_15668600==.ALT-- From owner-snmpv3@lists.tislabs.com Mon Aug 11 15:28:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00343 for ; Mon, 11 Aug 2003 15:28:20 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28524 Mon, 11 Aug 2003 14:15:17 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36027.73BD3AD7" Subject: RE: SNMPv3 security Date: Mon, 11 Aug 2003 09:41:45 -0700 Message-ID: <5B58696DB20B9140AD20E0685C573A6402992DD3@xch-nw-09.nw.nos.boeing.com> Thread-Topic: SNMPv3 security Thread-Index: AcNdz98pzj3yxTXcTcmiOzWGmbbxJgCTMChg From: "Fleischman, Eric" To: "Bruno Dias" , "Bill Strahm" Cc: "Randy Presuhn" , "Uri Blumenthal" , "Wijnen, Bert (Bert)" , "Eliot Lear" , "EXT-Weller, Michael K" , X-OriginalArrivalTime: 11 Aug 2003 16:41:46.0497 (UTC) FILETIME=[74235710:01C36027] Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C36027.73BD3AD7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you, Bruno, for stating elements of what I have been trying to say = in a different way. I hope that your explanation will be more valued by = this community than my version was. I hope so because you are a member = of SNMPv3 WG while I am not. =20 The primary difference from where I sit and where others in your = community apparently sit is that I am apparently substantially more = impressed by the talents, resources, accomplishments, and motivation of = those who will try to compromise our system than the SNMPv3 community = appears to be. That several writers explicitly assumed that they would = be comparable to university researchers indicates a significant = difference between our basic assumptions, invariably leading to vastly = different risk analysis and conclusions concerning the dangers involved = and the safeguards needed. Without a common perception of these dangers, = one can not discuss risk management, including the effectiveness of = proposed security provisions. This is why I have tried to discourage my = becoming involved in any technical discussion debating the effectiveness = of SNMPv3 security. Nevertheless, I remain interested in suggestions for = how SNMPv3 can be protected within a larger Defense in Depth approach = that could cumulatively address my security concerns. =20 =20 Concerning the ad hominem statements about my "apparent lack of = cryptography background", well, I've been called worse. However, = whenever two people sit in very different places, the views from their = knotholes differ. The presumption that only one view is of value is = hubris. I mention this because I want to remind this community that = SNMPv3 is being used in many different environments, some of which are = extremely hostile. -----Original Message----- From: Bruno Dias [mailto:bruno.dias@di.uminho.pt] Sent: Friday, August 08, 2003 10:09 AM To: Bill Strahm; Fleischman, Eric Cc: Randy Presuhn; Uri Blumenthal; Wijnen, Bert (Bert); Eliot Lear; = EXT-Weller, Michael K; snmpv3@lists.tislabs.com Subject: Re: SNMPv3 security At 21:58 07-08-2003, Bill Strahm wrote: Ok, I have to ask... What security protocol defines session key timeout values as a part of = the standard. I certainly don't know of any including IPsec and SSL/TLS. = All=20 things associated with session key timeouts resides within = administrative=20 control as a policy on top of the protocol for example IKE negotiates=20 session key timeouts in the IPsec protocol, IPsec has nothing to do with = it, now where does IKE get the value to negotiate for well that is a system = policy set by the adminstrator, there isn't ANYTHING in the IKE RFCs that = determine what value to negotiate. That said there are a HOST of research done on = the appropriate ammount of data to send under a key of given strength to = give an appropriate amount of security. With AES 128 my understanding = is that it provides about 10000 years of protection given the current ramp of = hardware and a governmental sized budget... The numbers grow exponentially to AES = 256. Now there is quite a bit of research showing that AES may only be about = 1000th the stength that it might be (known hacks at 9-10 rounds given a = rediculous amount of memory vs. the 16 rounds in the algorithm) so lets say AES 128 = is good to protect your management traffic for 10 years (1 year if they = have an obscene budget)... is your management traffic THAT valuable after 1 year = ? I just like the way the we're talking about these security protocols... Statements like "about 10000 years of protection given the current ramp = of hardware and a governmental sized budget..." is quite funny for a non expert like = me and a complete joke for a "network computer security professional" (yes, there's a lot more = about security on computer networks than cryptoanalisis!). I'd love to read the article where this = was written... Eric was criticized by his apparent lack of cryptography background, but = on a generic discussion about symmetric cripytography his toughts are a safer = approach than we all normally tend to assume... The "amount of data to send under a key of given strength to=20 give an appropriate amount of security", as I understand it, is not = exactly the same as the time of "protection" a key can assure. In fact, these are two = different types of security strengths. The first is about security strength to = cryptoanalisis attacks and the second is about security strength to brute force attacks. While the later is = "only" dependent on the key size vs computer power (you need to increase key size to figth the computer = power evolution), the first one is much more hard to evaluate but it is believed that the larger the = amount of data analised the better are the chances to compromise the key. Well, on a communication = between two (or more) network entities the amount of data transmited, and prone to be = cryptoanalised, increases as time passes, so is the chance of the key to be compromised. Also, in general, = the amount of time need to crack a key by cryptoanalisis is much smaller than the = brute force attack when the some weekenesses are discovered on the crypto algorithm or on the key = itself. But the real intention beyond limited key time life spans has to do = about compromised keys due to bad key management (week key values, management applications and = operating systems security weekenesses, unsecure key storage, etc) than compromised keys = from brute force or cryptoanalisis attacks. That's where a protocol imposing a limited key time life span (or key = sessions) woud help to reduce the amount of this data. Not such a bad (or new) idea... even if not directly applicable on = current SNMP standards, but the regular changing of passphrases by some sort of application could be = usefull (as someone as already discovered *;o), although it brings some "third = party trust" security problems that makes this key distribution a not so simple matter... Regards, -- Bruno Dias ------_=_NextPart_001_01C36027.73BD3AD7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank=20 you, Bruno, for stating elements of what I have been trying to say in a=20 different way. I hope that your explanation will be more valued by this=20 community than my version was. I hope so because you are a member of = SNMPv3 WG=20 while I am not. The=20 primary difference from where I sit and where others in your community=20 apparently sit is that I am apparently substantially more impressed by = the=20 talents, resources, accomplishments, and motivation of those who will = try to=20 compromise our system than the SNMPv3 community appears to be. That = several=20 writers explicitly assumed that they would be comparable to = university=20 researchers indicates a significant difference between our basic = assumptions,=20 invariably leading to vastly different risk analysis and conclusions = concerning=20 the dangers involved and the safeguards needed. Without a common = perception of=20 these dangers, one can not discuss risk management, including the = effectiveness=20 of proposed security provisions. This is why I have tried to discourage = my=20 becoming involved in any technical discussion debating the effectiveness = of=20 SNMPv3 security. Nevertheless, I remain interested in suggestions for = how SNMPv3=20 can be ! protected within a larger Defense in Depth approach that could=20 cumulatively address my security concerns. Concerning the ad hominem = statements about my=20 "apparent lack of cryptography background", well, I've been called = worse.=20 However, whenever two people sit in very different places, the views = from their=20 knotholes differ. The presumption that only one view is of value is = hubris. I=20 mention this because I want to remind this community that SNMPv3 is = being used=20 in many different environments, some of which are extremely=20 hostile. -----Original Message----- From: Bruno Dias=20 [mailto:bruno.dias@di.uminho.pt] Sent: Friday, August 08, = 2003 10:09=20 AM To: Bill Strahm; Fleischman, Eric Cc: Randy = Presuhn;=20 Uri Blumenthal; Wijnen, Bert (Bert); Eliot Lear; EXT-Weller, Michael = K;=20 snmpv3@lists.tislabs.com Subject: Re: SNMPv3=20 security At 21:58 07-08-2003, Bill = Strahm=20 wrote: Ok, I have to = ask... What=20 security protocol defines session key timeout values as a part of=20 the standard. I certainly don't know of any including IPsec = and=20 SSL/TLS. All things associated with session key timeouts = resides=20 within administrative control as a policy on top of the protocol = for=20 example IKE negotiates session key timeouts in the IPsec = protocol, IPsec=20 has nothing to do with it, now where does IKE get the value to = negotiate=20 for well that is a system policy set by the adminstrator, there = isn't=20 ANYTHING in the IKE RFCs that determine what value to = negotiate. =20 That said there are a HOST of research done on the appropriate = ammount=20 of data to send under a key of given strength to give an = appropriate=20 amount of security. With AES 128 my understanding is = that it=20 provides about 10000 years of protection given the current ramp of=20 hardware and a governmental sized budget... The numbers grow=20 exponentially to AES 256. Now there is quite a bit of research = showing=20 that AES may only be about 1000th the stength that it might be = (known=20 hacks at 9-10 rounds given a rediculous amount of memory vs. the = 16=20 rounds in the algorithm) so lets say AES 128 is good to protect = your=20 management traffic for 10 years (1 year if they have an obscene=20 budget)... is your management traffic THAT valuable after 1 year=20 ? I just like the way the we're talking about = these=20 security protocols... Statements like "about 10000 = years of=20 protection given the current ramp of hardware and a governmental = sized=20 budget..." is quite funny for a non expert like me and a = complete=20 joke for a "network computer security professional" (yes, there's a = lot=20 more about security on computer networks than cryptoanalisis!). I'd = love to=20 read the article where this was written... Eric was criticized = by his=20 apparent lack of cryptography background, but on a = generic discussion about=20 symmetric cripytography his toughts are a safer approach than = we all=20 normally tend to assume... The "amount of data to send=20 under a key of given strength to give an appropriate amount of=20 security", as I understand it, is not exactly the same as = the time=20 of "protection" a key can assure. In fact, these are two = different types of=20 security strengths. The first is about security strength to = cryptoanalisis=20 attacks and the second is about security strength to brute force = attacks.=20 While the later is "only" dependent on the key size vs computer = power (you=20 need to increase key size to figth the computer power evolution), the = first=20 one is much more hard to evaluate but it is believed that the = larger the=20 amount of data analised the better are the chances to compromise = the key.=20 Well, on a communication between two (or more) network entities the = amount=20 of data transmited, and prone to be cryptoanalised, increases as=20 time passes, so is the chance of the key to be compromised. Also, = in=20 general, the amount of time need to crack a key by cryptoanalisis = is much=20 smaller than the brute force attack when the some weekenesses are=20 discovered on the crypto algorithm or on the key itself. But the = real=20 intention beyond limited key time life spans has to do about = compromised=20 keys due to bad key management (week key values, management = applications=20 and operating systems security weekenesses, unsecure key storage, = etc) than=20 compromised keys from brute force or = cryptoanalisis attacks. That's=20 where a protocol imposing a limited key time life span (or key = sessions) woud=20 help to reduce the amount of this data. Not such a bad (or new) = idea...=20 even if not directly applicable on current SNMP standards, but the = regular=20 changing of passphrases by some sort of application = could=20 be usefull (as someone as already discovered *;o), although it = brings some=20 "third party trust" security problems that makes this key = distribution a=20 not so simple matter... Regards, -- Bruno=20 Dias ------_=_NextPart_001_01C36027.73BD3AD7-- From owner-snmpv3@lists.tislabs.com Tue Aug 12 13:36:24 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22317 for ; Tue, 12 Aug 2003 13:36:24 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03318 Tue, 12 Aug 2003 12:28:57 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: FW: Securing SNMPv3 via SSH tunnels X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Tue, 12 Aug 2003 12:37:11 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BAEA9147@NHROCMBX1.ets.enterasys.com> Thread-Topic: Securing SNMPv3 via SSH tunnels Thread-Index: AcNcUkRTcp9VDqtMQ+eshJMjH8s0tADSt6bQ From: "Harrington, David" To: Cc: "Wijnen, Bert (Bert)" , "Fleischman, Eric" , "Uri Blumenthal" , "Bill Strahm" X-OriginalArrivalTime: 12 Aug 2003 16:37:12.0253 (UTC) FILETIME=[FB16C6D0:01C360EF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA03315 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit I am copying this message to the snmpv3 list for discussion. Please do not copy subsequent discussion to the IETF general list. Dbh David Harrington dbh@enterasys.com co-chair, IETF SNMPv3 WG -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Wednesday, August 06, 2003 3:36 PM To: Fleischman, Eric; Uri Blumenthal; Bill Strahm Cc: ietf@ietf.org; Harrington, David; Russ Mundy (E-mail) Subject: RE: Securing SNMPv3 via SSH tunnels Eric, it would be good if you could describe the "spoofing" and possible other vulnerabilities that you see. Not sure that the generic IETF mailing list is the proper mailing list for that. I propose we move the discussion to the SNMPv3 mailing list. I copied the WG chairs to see if they would permit us to have that discussion over there. If so, they can send the ptr to the list. Thanks, Bert > -----Original Message----- > From: Fleischman, Eric [mailto:eric.w.fleischman@boeing.com] > Sent: woensdag 6 augustus 2003 20:08 > To: Uri Blumenthal; Bill Strahm > Cc: ietf@ietf.org > Subject: RE: Securing SNMPv3 via SSH tunnels > > > Uri, > > I don't think that this list would be well served by a debate > on whether SNMPv3's security provisions are adequately secure > or not, though I personally would greatly value having a > private discussion with interested individuals on that topic. > > Suffice it to say here that I am familiar with RFC 3414 and > RFC 3415 and I am skeptical that existing SNMPv3 security > provisions provide adequate protections for the application I > am building. I am therefore seeking to supplement SNMPv3's > security provisions via mechanisms which are less subject to > abuse, which is why I made my original posting to this list. > > I have no ax to grind in this matter -- I am only seeking > after the welfare of our product. It is, of course, possible > that I have overlooked something important which would > justify your skepticism of my current conclusions. If so, I > would value privately benefiting from the wisdom of your > insights. I similarly would value learning the insights of > any other reader with experience securing SNMPv3 for > mission-critical devices which do not sit behind firewalls. > > --Eric > > -----Original Message----- > From: Uri Blumenthal [mailto:uri@lucent.com] > Sent: Wednesday, August 06, 2003 10:32 AM > To: Bill Strahm > Cc: Fleischman, Eric; ietf@ietf.org > Subject: Re: Securing SNMPv3 via SSH tunnels > > > Bill, what is this about? Eric obviously wasn't aware > that the problems he listed applied to the older versions > of SNMP protocol, namely SNMPv1 and SNMPv2c. The current > standard SNMPv3 (which obsoletes those) is designed > specifically to address the listed vulnerabilities. > > So this whole notion of securing SNMPv3 with SSH is > ridiculous. > > > On 8/6/2003 12:34 PM, Bill Strahm wrote: > > The problem that you have with TCP (and made worse by SSH > tunneling on top of > > it) is that the number of round trips needed to > successfully get a data packet > > through is unreasonably high in a situation where you are > attempting to > > diagnose a network fault. > > > > The other choice is to leave a LOT of state open (ie. TCP > connections) > > requiring a lot of extra memory, etc. on the device. That > said there is no > > reason why you can not create a tunnel to a secure > environment and run your > > SNMP traffic from there. > > > > Bill > > > > On Wed, Aug 06, 2003 at 08:42:49AM -0700, Fleischman, Eric wrote: > > > >>I am seeking to secure SNMPv3 communications (e.g., RFC > 3414), trying to protect against its well-known > vulnerabilities such as spoofing. Had SNMPv3 run over TCP, > instead of UDP as it does, then I perhaps may attempt to > protect it via SSH port forwarding (i.e., SSH tunneling). > Coincidentally, I've just read a description in Bob Toxen's > book "Real World Linux Security" (page 141) about an approach > he has apparently used of wrapping UDP in TCP and SSH in > order to accomplish SSH port forwarding for UDP-based > protocols as well. This makes me wonder whether SNMPv3 may be > a viable candidate for SSH tunneling after all. I am > wondering whether anybody in the list has any insights as to > the viability and weaknesses of this suggested approach. I am > especially interested in learning how people on this list > secure SNMPv3. Thank you. > > > > > > > > > _______________________________________________ > This message was passed through > ietf_censored@carmen.ipv6.cselt.it, which is a sublist of > ietf@ietf.org. Not all messages are passed. Decisions on what > to pass are made solely by Raffaele D'Albenzio. > From owner-snmpv3@lists.tislabs.com Thu Aug 21 17:45:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02329 for ; Thu, 21 Aug 2003 17:45:00 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29484 Thu, 21 Aug 2003 14:00:47 -0400 (EDT) Date: Thu, 21 Aug 2003 13:59:23 -0400 (EDT) From: TIS Majordomo Message-Id: <200308211759.NAA29470@lists.tislabs.com> To: snmpv3@lists.tislabs.com Subject: delays and outages at lists.tislabs.com Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Due to the SoBig worm and other issues, there may be delays and outages with the lists.tislabs.com server. -John Kelley (tislabs.com majordomo admin) From owner-snmpv3@lists.tislabs.com Mon Aug 25 14:30:52 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08040 for ; Mon, 25 Aug 2003 14:30:51 -0400 (EDT) From: owner-snmpv3@lists.tislabs.com Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27877 Mon, 25 Aug 2003 13:05:03 -0400 (EDT) Date: Mon, 25 Aug 2003 13:05:03 -0400 (EDT) Message-Id: <200308251705.NAA27877@lists.tislabs.com> (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id MAA26315 Mon, 25 Aug 2003 12:47:10 -0400 (EDT) via csmap (V6.0) id srcAAAh2aitr; Mon, 25 Aug 03 12:53:54 -0400 Message-Id: <200308251654.h7PGswN25158@gamma.isi.edu> To: IETF-Announce: ; Subject: BCP 74, RFC 3584 on Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework Cc: rfc-editor@rfc-editor.org, snmpv3@lists.tislabs.com From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 25 Aug 2003 09:54:57 -0700 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. BCP 74 RFC 3584 Title: Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework Author(s): R. Frye, D. Levi, S. Routhier, B. Wijnen Status: Best Current Practice Date: August 2003 Mailbox: rfrye@vibrant-1.com, dlevi@nortelnetworks.com, sar@epilogue.com, bwijnen@lucent.com Pages: 51 Characters: 115222 Obsoletes: 2576 I-D Tag: draft-ietf-snmpv3-coex-v2-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3584.txt The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format. This document obsoletes RFC 2576. This document is a product of the SNMP Version 3 Working Group of the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030825095305.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3584 --OtherAccess Content-Type: Message/External-body; name="rfc3584.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030825095305.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-snmpv3@lists.tislabs.com Mon Aug 25 18:09:09 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19127 for ; Mon, 25 Aug 2003 18:09:03 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA12650 Mon, 25 Aug 2003 15:47:13 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Mon, 25 Aug 2003 12:49:49 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: snmpv3@lists.tislabs.com Subject: Re: BCP 74, RFC 3584 on Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework In-Reply-To: <200308251654.h7PGswN25158@gamma.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk On Mon, 25 Aug 2003 rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > BCP 74 > RFC 3584 > > Title: Coexistence between Version 1, Version 2, and > Version 3 of the Internet-standard Network > Management Framework There is one very minor bug (the first 114 lines of the MIB module, from the beginning to the MODULE-IDENTITY value assignment) are indented differently than the rest, but it's no big thing. I guess this means we can now declare victory and close down the working group. //cmh From owner-snmpv3@lists.tislabs.com Thu Aug 28 11:37:10 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24749 for ; Thu, 28 Aug 2003 11:37:09 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10063 Thu, 28 Aug 2003 10:14:22 -0400 (EDT) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550245C44E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Snmpv3-wg (E-mail)" Subject: FW: securityName Date: Thu, 28 Aug 2003 16:21:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk So veryone can read and/or chime in Thanks, Bert -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: donderdag 28 augustus 2003 15:47 To: 'Wijnen, Bert (Bert)' Subject: RE: securityName Please feel free to post this, I was not subscribed to the mailing list at the time I sent this email. Thanks again, Will Murwin -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Thursday, August 28, 2003 7:55 AM To: Murwin William-LWM008; bwijnen@lucent.com Subject: RE: securityName The snmpUsmMIB is for the USM (User-based Security Model). The snmpCommunityMIB is for the SNMPv1 or SNMPv2c CSM (Community-based Security Model, see sect 5 of RFC3584). So they are clearly different and so you would (in my view) never have a usmUserTable entry for Community String. Now, what both USM and CSM do, is they map their specific security model name into a generic securityName, as per the figure in sect 3.2, page 25 in RFC3411. The model dependent security ID for USM is the userName as transported in the msgUserName in the USMSecurityParamters in an SNMPv3 message (RFC3414, sect 2.4. on page 16). the model dependent security ID for CSM is the communityName as transported in the community in the SNMPv1 or SNMPv2c message (as per the definitions in sect 4 of RFC1157, page 16, or sect 3 of RFC1901, page 5). Each of those model dependent security IDs needs to be mapped in a common ID, namely the securityName. The mapping from USM userName to securityName is a 1-1 mapping, so user Bert in USM also results in securityName Bert and so it results in an entry Bert in the usmUserTable. The mapping from a community (communityName) into a securityName is not a 1-1 mapping; instead it is mapped via the snmpCommunityTable into a securityName as defined by snmpCommuntySecurityName. So theoretiucally, if there was a communityName Bert, then you can also map that into securityName Bert. and so one could allow Bert access via SNMPv1/v2c and SNMPv3. If such is wise and well organised is a matter of taste and policy. This securityName is then used in the VACM (RFC3415) to grant or deny access to various parts of the MIB. In addition to the securityName, also the securityModel and the securityLevel are part of the decision to allow or disallow access to MIB information. That is: You will notice that in the VACM (figure in sect 3.1 of RFC3415 helps a lot here) the mapping into a groupName takes both securityName and securityModel into account. And so you can choose to make [Bert, USM] and [Bert, CSM] to be in the same group or in different groups. Even if you DO put them in the same group, the viewName(s) to which the group(s) to which Bert belongs take again the securityModel and the securityLevel into account when deciding to which ones Bert has access. Hope this helps/explains. Thanks, Bert p.s. Do you mind if I post this answer to the SNMPv3 WG mailing list, so others can see it and/or chime in if needed? > -----Original Message----- > From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] > Sent: donderdag 28 augustus 2003 1:32 > To: 'bwijnen@lucent.com' > Subject: securityName > > > Bert, > > I have a quick question for you about a gray area > between RFC 3584 "Coexistence between Version 1, Version 2, > and Version 3 of the Internet-standard Network Management > Framework" and RFC 3414 "User-base Security Model (USM) for > version 3 of the Simple Network Management Protocol (SNMPv3)". > > Does an agent that has an entry in the "snmpCommunityTable", > need to have an entry in the "usmUserTable" where > the "usmUserSecurityName" equals the > "snmpCommunitySecurityName", for a manager to have SNMPv1/2c > coexistence access to that agent if there is their is an > instance of "vacmSecutiryToGroupTable" where the instance of > vacmSecurityName equals the "snmpCommunityTable". > > I don't see it explicitly call for a > "snmpCommunitySecurityName" to be equal "usmUserTable" for > coexistence to work. > I RFC 3584 explicitly says that "snmpCommunitySecurityName" > is a "securityName" and the > RFC 3414 say that "usmUserSecurityName" is a "securityName". > > Any light you can shine on the subject is greatly > appreciated. I thought about this an both having and not > having an entry in the > "usmUserTable", and can think of reason for doing this either way. > > Thanks, > Will > > P.S. > > ______________________________ > William Murwin > Broadband Communications Sector > Motorola Inc. > Email: W.Murwin@motorola.com > Tel: (508) 851-8385 > From owner-snmpv3@lists.tislabs.com Fri Aug 29 10:48:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29963 for ; Fri, 29 Aug 2003 10:48:12 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA21443 Fri, 29 Aug 2003 09:21:17 -0400 (EDT) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550245C681@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: srinivasan R , snmpv3@lists.tislabs.com, uri@bell-labs.com Subject: RE: Help needed Date: Fri, 29 Aug 2003 15:28:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Inline > -----Original Message----- > From: srinivasan R [mailto:srinids@hotmail.com] > Sent: vrijdag 29 augustus 2003 12:26 > To: snmpv3@lists.tislabs.com; uri@bell-labs.com; bwijnen@lucent.com > Subject: Help needed > > > Hi All, > > This is regarding the scenario wherein the SnmpEngineBoots > value reached its maximum value, 2147483647. > > The possible solution suggested by RFC 3414 is given below > > " In order to reset an SNMP engine whose snmpEngineBoots value has > reached the value 2147483647, manual intervention is required. The > engine must be physically visited and re-configured, either with a > new snmpEngineID value, or with new secret values for the > authentication and privacy protocols of all users known to that SNMP > engine. Note that even if an SNMP engine re-boots once a second that > it would still take approximately 68 years before the max value of > 2147483647 would be reached." > > Here my understanding is that changing the secret values of the > authentication and privacy protocols of all users known to that > SNMP Engine enables the manager to further communicate with the > authoritative agent(with same snmpEngineID) > > I have a couple of doubts. They are, > > (i) Changing the secret values resets the snmpEngineBoots of > that SNMP Engine to zero by default. > I don't think that we specified that. So I would assume such is implementation dependent. Besides, if you have a reasonable set of users, I do not see that it is easy to change the secrets all at once via a single SNMP SET. I don't think we intended that you would be able to reset all secrets via one (or multiple) SNMP SET requests and that such would reset snmpEngineBoots value. > (ii) In what way changing the secret values affects the > snmpEngineBoots value ?/ what is the relation between > snmpEngineBoots and secret values. > The idea is (I am not the best security expert here, so maybe Uri or Russ or so can jump in) that the snmpEngineBoots is part of the "authentication-timeliness" check and it only makes sense if the messages are at least authenticated, so if they have at least secuirtLevel of authNoPriv. So my thinking is that if you reset all secreats, that starting anew with an snmpEngineBoots at zero is OK, because any old (captured) messages that anyone would want to replay can then never be valid, because they would not match the MAC based on the new secrets. Security specialists, pls chime in here. > (iii) If I reconfigure a new snmpEngineID, then the users > already configured in the device are accessible through the > new snmpEngineID. Am I right here ? > Well, normally (as RECOMMENDED), the managed device keeps all secrets in a localized form. So one would need to re-generate the localized secrets at the managed (authoritative) engine as well. But other than that, I think that you can indeed re-use (or continue to use) the existing users. Hope this explains/helps. Bert > > Thanks in advance, > > R. srinivasan > > _________________________________________________________________ > ICICI's NRI services. They make life easy. > http://server1.msn.co.in/msnspecials/nriservices/index.asp > Find out more. >