Re: question on key localizaton

>>>>> On Sat, 16 Nov 2002 11:15:31 +0900, "???" <[email protected]> said:

hina> But, keeping unique secNames per agents is an administrative
hina> nightmare.

I offered this example originally as one alternative to the problem
which most people probably wouldn't pick.  Sorry if it confused you,
but otherwise your description fit the strange not-normal example that
I gave.

hina> So it is 99 % probable that secName1 = secName2 = secName3 = ... secName-n and K1 = K2 = K3 = ... Kn.

Only for INFORMs, mind you, would this be the case.  If you broke into
an agent, you would be able *only* to steal useful keys for sending
INFORMs to a receiver.  It would not enable you to use K1 to access
information from machine 2.  In other words, K1 in your scenario would
*only* be used for sending that inform.

hina> If right, we had better forbid INFORM from agents to the manager
hina> or take over the administrative nightmare.

Well, I've led you to the other extreme by accident.  You missed one
of my sentences that said something like "if you run automated
responses" based on the information in an INFORM.  In other words,
you have to decide if the information being sent in the informs on
your network is being used in a way which is either not double checked
or is used in an automated way which could do something drastic.  As
an example, if you receive an INFORM linkDown trap and a human double
checks that the link is actually down, then it's not an issue.  If you
receive a linkDown trap and automatically reroute your network traffic
through a 1/10th size backup link, you're probably in trouble.
-- 
Wes Hardaker
Network Associates Laboratories