Re: SNMPv2 security

"michael (m.) sam chee" <mschee@bnr.ca> Tue, 01 February 1994 18:30 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11777; 1 Feb 94 13:30 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11773; 1 Feb 94 13:30 EST
Received: from relay.tis.com by CNRI.Reston.VA.US id aa13355; 1 Feb 94 13:30 EST
Received: by relay.tis.com; id AA16016; Tue, 1 Feb 94 13:06:12 EST
Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.0mjr) id sma016006; Tue Feb 1 13:05:55 1994
Received: from magellan.tis.com by magellan.TIS.COM id aa00522; 1 Feb 94 13:01 EST
Received: from sol.tis.com by magellan.TIS.COM id aa00518; 1 Feb 94 12:56 EST
Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05502; Tue, 1 Feb 94 12:55:36 EST
Received: by relay.tis.com; id AA15883; Tue, 1 Feb 94 12:56:09 EST
Received: from x400gate.bnr.ca(192.58.194.73) by relay via smap (V1.0mjr) id sma015869; Tue Feb 1 12:55:55 1994
X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 1 Feb 1994 12:48:21 -0500
X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 1 Feb 1994 12:47:41 -0500
X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 1 Feb 1994 07:47:00 -0500
Date: Tue, 01 Feb 1994 12:47:00 +0000
X400-Originator: "/dd.id=1664568/g=michael/i=m/s=sam chee/"@bnr.ca
X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; bcars735.b.643:01.01.94.17.47.41]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Re: SNMPv2 se...
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "michael (m.) sam chee" <mschee@bnr.ca>
X-Orig-Sender: "michael (m.) sam chee" <mschee@bnr.ca>
Message-Id: <"18661 Tue Feb 1 12:47:52 1994"@bnr.ca>
To: tarr@itd.nrl.navy.mil
Cc: kzm@hls.com, snmp@psi.com, snmpv2@magellan.tis.com
Subject: Re: SNMPv2 security

In message "SNMPv2 security", tarr@itd.nrl.navy.mil writes:

> 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 
> 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.
> 

One can use a TestAndIncr object to solve this problem.

---
Michael Sam Chee, TCP/IP Software Development   mschee@bnr.ca
Bell-Northern Research, Ltd.                    Voice (613)763-9650
P.O. Box 3511, Station C                        FAX   (613)763-8312
Ottawa, Ontario, Canada K1Y 4H7    #include <standard_disclaimer.h>