RE: SNMPv3 security

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 protected]]
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 protected]
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 
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