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