RE: question on key localizaton

Wow... BIG SURPRISE !!!.
Are you really sure?

Your comment implies that HMAC-MD5-96 algorithm generates the same digests with different authKeys for the same message 
and that we can decrypt to get the original scopedPDU with a privKey which is different to that used in encryption.
Of course, authKeys/privKeys are different but derived from the same password by key localization algorithm.

Is the Key Localization Algorithm designed so well that it may guarantee this improbable results ?

-----Original Message-----
From: Chris Elliott [mailto:[email protected]]
Sent: Saturday, November 16, 2002 2:03 PM
To: ???
Cc: David T. Perkins; [email protected]
Subject: RE: question on key localizaton


The key any engine needs is it's own localized key for that user. Not the
localized keys for that user for every engineID that it wants to
communicate with.

Chris.

On Sat, 16 Nov 2002, ??? 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
>

Chris Elliott  CCIE# 2013       |         |
Customer Diagnostic Engineer   |||       |||
RTP, NC, USA                  |||||     |||||
919-392-2146              .:|||||||||:|||||||||:.
[email protected]        c i s c o S y s t e m s