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>
- Re: SNMPv2 security Frank Kastenholz
- Re[2]: SNMPv2 security cyoung
- Re: SNMPv2 security Frank Kastenholz
- Re: SNMPv2 security Frank Kastenholz
- Re: SNMPv2 security uri
- Re: SNMPv2 security uri
- Re: SNMPv2 security Frank Kastenholz
- Re: SNMPv2 security Julie Tarr
- Re: SNMPv2 security Keith McCloghrie
- Re: SNMPv2 security Julie Tarr
- Re: SNMPv2 security Sath. Nelakonda
- Re: SNMPv2 security michael (m.) sam chee