Subject: RE: SNMPv3 security

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 7 Aug 2003 13:22:39 -0700

From: Randy Presuhn [mailto:[email-masked]]
>???  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: David Spakes <[email-masked]>
Date: Thu, 7 Aug 2003 17:21:56 -0400 (EDT)

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:   [email-masked]  
 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: Michael Kirkham <[email-masked]>
Date: Thu, 7 Aug 2003 14:40:14 -0700 (PDT)

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: Bill Strahm <[email-masked]>
Date: Thu, 7 Aug 2003 16:58:06 -0400

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 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).

---

From: Bruno Dias <[email-masked]>
Date: Fri, 08 Aug 2003 18:09:15 +0100

>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

> > >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).
> >
> key and to introduce doubts whether any two ciphertexts were encrypted by 
> the same or different keys. This is the most fundamental defense 
> > Your statement above is disingenuous -- as I trust you knew when you 
> wrote it. No user or security administrator can bear the overhead of 
> 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!!!
> >
> > 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 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.
> >
> > 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).
> >
> > 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.
> >
> > 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ática - Universidade do Minho
Campus de Gualtar, 4710-057 Braga, PORTUGAL
E-Mail<[email-masked]> Telef<+351 919 312 312> Fax<+351 253 604 471>

---

From: Uri Blumenthal <[email-masked]>
Date: Fri, 8 Aug 2003 13:54:36 -0400

On Friday 08 August 2003 01:09 pm, Bruno Dias wrote:
> 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).

> 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

Not quite - SNMP is inherently asymmetric, so most of the intelligence
lives in the NMS. I doubt this paradigm is ready to be discarded.