Re: SNMPv3 security

Uri Blumenthal <[email protected]> Fri, 8 Aug 2003 13:32:17 -0400
Newsgroups gmane.ietf.snmpv3
Message-ID <200308081332.17029.uri@elliptic>
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. :-]