RE: question on key localizaton

HI,

Take the following...
Users - U1 and U2
Managers, with engineIDs - M1 and M2
Managed systems with engineIDs - A1 and A2

For each manager and managed system, show for table usmUserTable the
values for columns usmUserEngineID and usmUserSecurityName, and the
associated authKey.
For example:
at M1
EngID SecNa AuthKey
A1    U1    K-U1(p1)-A1
M1    U1    K-U1(p1)-M1
...


Specify for each of the following, the value for field msgAuthoritativeEngineID and which authKey is used in generating
the hash for a message with security auth/noPriv:

SET U1 at M1 to A1
SET U2 at M1 to A1
SET U1 at M1 to A2
SET U2 at M1 to A2
v2Trap U1 at A1 to M1
v2Trap U2 at A1 to M1
v2Trap U1 at A1 to M2
v2Trap U2 at A1 to M2
INFORM U1 at A1 to M1
INFORM U2 at A1 to M1
INFORM U1 at A1 to M2
INFORM U2 at A1 to M2

Once you correctly fill out the above, the answers to your questions
will become visible.
If not, change the passphrase for user U1, update the tables with
the new localized keys.

At 12:50 PM 11/16/2002 +0900, ??? wrote:
>Oooops, really ?
>
>Would you please point out the stage at which my quess starts deviation from the truth? 
>
>One of  my basic understandings about SNMPv3 security mechanim is the following.
>"A non-authoritative engine Ea should know at least one of the security Name and its corresponding keys on the authoritative engine Eb
> if Ea wants to send get, getnext, getbulk, set and inform requests ( so called, Confirmed Class ) securely to Eb."
>Am I wrong even at this point?
>
>
>-----Original Message-----
>From: David T. Perkins [mailto:[email protected]]
>Sent: Saturday, November 16, 2002 12:10 PM
>To: ???
>Cc: [email protected]
>Subject: RE: question on key localizaton
>
>
>HI,
>
>Your guess below at how things work and how keys are managed is incorrect.
>At 11:15 AM 11/16/2002 +0900, ??? wrote:
>>Let me rephrase what you mean.
>>
>>Suppose that there are a single manager engine M and N agents engines A1, A2, A3, ... An.
>>If there is no INFORM from an agent to the manager, then
>>all the agent's diffent keys are known to the manager but any agent couldn't figure out 
>>another agent's key and hence no agent can corrupt other agnets.
>>However, If INFORM from any agent to the manager is allowed, then 
>>A1 should know a secName1 on the manager and corresponding key K1. ( athentication key or privacy key, whatever )
>>because the manager is the authoritative side in this case.
>>A2 should know a secName2 on the manager and corresponding key K2.
>>A3 should know a secName3 on the manager and corresponding key K3.
>>...
>>An should know a secName-n on the manager and corresponding key Kn.
>>
>>But, keeping unique secNames per agents is an administrative nightmare.
>>So it is 99 % probable that secName1 = secName2 = secName3 = ... secName-n and K1 = K2 = K3 = ... Kn.
>>At last, we have one common user and one common key all around the management domain.
>>This user and key can be used maliciously.
>>
>>Is this what you mean?
>>
>>If right, we had better forbid INFORM from agents to the manager or 
>>take over the administrative nightmare.
>>
>>
>>-----Original Message-----
>>From: Wes Hardaker [mailto:[email protected]]
>>Sent: Saturday, November 16, 2002 4:03 AM
>>To: Uri Blumenthal
>>Cc: 3aCoAI; [email protected]
>>Subject: Re: question on key localizaton
>>
>>
>>>>>>> On Fri, 15 Nov 2002 13:57:04 -0500, Uri Blumenthal <[email protected]> said:
>>
>>Uri> "The same key" is NOT the same as "the same LOCALIZED key". So
>>Uri> yes, all those keys would be DERIVED from the user key owned by
>>Uri> secName, and all those keys will be different and
>>Uri> cryptographically "unrelated" due to localization process.
>>
>>Uri> Am I missing something here?
>>
>>Yes you are.  The engineid for the localization process in a SNMPv3
>>inform is the notification receiver.  That means that the same key
>>(which is a localized key, but is always the same) is used across all
>>systems on a network (unless a unique secName is picked for each
>>system, which is certainly one way around the security problem, albeit
>>an administrative nightmare).
>>
>>Uri> One of us is missing something. The question is - who and what? (:-)
>>
>>It's you ;->
>>
>>-- 
>>Wes Hardaker
>>Network Associates Laboratories 
Regards,
/david t. perkins