Re: SNMPv3 security

Wes Hardaker <[email protected]> Fri, 08 Aug 2003 10:45:30 -0700
Newsgroups gmane.ietf.snmpv3
Organization Sparta
Message-ID <[email protected]>
>>>>> On Fri, 8 Aug 2003 13:32:17 -0400, Uri Blumenthal <[email protected]> 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