Re: SNMPv2 security

["Sath. Nelakonda" <[e-mail]>]

	> In order for the cryptanalysis to have the data to crack the keys, he must
	> already selectively capture traffic going to/from that agent.  The XOR scheme
	> does not make his job significantly harder.  It gives him unlimited time
	> in which to crack the code.
	> 
	> Also note that, as someone else in this discussion group has already pointed out,
	> the XORed key change message is vulnerable to replay attack.  If an attacker replays
	> a key change message within the window of oppportunity provided by the message lifetime,
	> then the replayed message will change the keys back to the old key.  That is,
	> the manager sends to the agent (Kold XOR Knew) . The agent calculates 
	> Kold XOR (Kold XOR Knew) to produce Knew and changes its key to Knew.  If the
	> agent receives a replay of this key change message, it will calculate 
	> Knew XOR (Kold XOR Knew) to produce Kold and change the key back to Kold.  The 
	> agent will send a confirmation of this change back to the manager, so the manager
	> will be aware that an attacker has tampered with the system.  However, how is 

Not necessarily. It may very well be a duplicate response.
But then that doesn't make the life of the manager any simpler.
Everytime it receives a duplicate response, it has to "worry".

It is always a good idea to set _another_ object (similar to
snmpSetSerialNo) in the same PDU as partyAuthPrivate so that 
if the response is lost or a duplicate one is received, it
can check this other object's value (with a get) and it can
also prevent a replay described above.

	> the manager going to reset the key?  If it tries to send another XOR key change
	> message, the attacker can simply repeat this procedure.
	> 
	> Note that this replay attack is relatively simply to perform, it only requires
	> good timing.
	> 
	> 				Julie
	> 


Sathyender.
[e-mail]