Re: question on key localizaton
Uri Blumenthal <[email protected]>
| Newsgroups | gmane.ietf.snmpv3 |
|---|---|
| Message-ID | <[email protected]> |
At 10:05 11/15/2002 -0800, Wes Hardaker wrote: > >>>>> On Fri, 15 Nov 2002 09:45:55 -0500, Uri Blumenthal <[email protected]> > said: >Uri> The assumption behind all this is that there are ust a few >Uri> "manager boxes" and they usually sit in well-protected and >Uri> reasonably secure locations. While the agents are plentiful and >Uri> deployed in the field across the wild lands, so pretty much >Uri> anybody can get to an agent or two and tease 'em apart... > >Note that this whole analogy breaks down with SNMPv3 INFORMs are >used. Specifically, the USM user that the INFORM is sent on behalf of >must be the authoritative user of the trap receiver. I don't see the problem. So several agents use INFORM sending messages to a couple of NMS boxes under the same User - necessarily using different localized keys. So...? > Thus if the same >USM secName user is used for every deployed notification generator, then >the same (localized) key must be used at every notification >generator and only one USM secName user is created and configured at >the notification receiver. "The same key" is NOT the same as "the same LOCALIZED key". So yes, all those keys would be DERIVED from the user key owned by secName, and all those keys will be different and cryptographically "unrelated" due to localization process. Am I missing something here? > If you are triggering important actions or >sending important information via INFORMs, then all of your boxes on >the network are at risk of holding important information which could >be used to subvert your management infrastructure by submitting >malicious, but authenticated, INFORMs. No. Any box has a set of localized keys for different users. The "originating" keys may be the same for all the boxes - but the keys that the boxes store are different. And of course any agent may subvert the infrastructure by sending bogus/wrong/ malicious data under its signature. The only thing it can NOT do is sending such a malicious packet under ANOTHER agent's signature (or under user's signature for a different box). One of us is missing something. The question is - who and what? (:-)