Subject: RE: SNMPv3 security

From: "David T. Perkins" <[email-masked]>
Date: Thu, 07 Aug 2003 16:17:41 -0700

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: Bruno Dias <[email-masked]>
Date: Fri, 08 Aug 2003 18:55:14 +0100

[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á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: "Fleischman, Eric" <[email-masked]>
Date: Mon, 11 Aug 2003 09:41:45 -0700

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.
 
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.  
 
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:[email-masked]]
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; [email-masked]
Subject: Re: SNMPv3 security

Ok, I have to ask...

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