Re: SNMPv2 security

Frank Kastenholz <kasten@tri-flow.ftp.com> Fri, 28 January 1994 19:09 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08936; 28 Jan 94 14:09 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08932; 28 Jan 94 14:09 EST
Received: from relay.tis.com by CNRI.Reston.VA.US id aa12907; 28 Jan 94 14:09 EST
Received: by relay.tis.com; id AA28906; Fri, 28 Jan 94 13:42:23 EST
Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.0mjr) id sma028903; Fri Jan 28 13:41:41 1994
Received: from magellan.tis.com by magellan.TIS.COM id aa15689; 28 Jan 94 13:37 EST
Received: from sol.tis.com by magellan.TIS.COM id aa15668; 28 Jan 94 13:29 EST
Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22354; Fri, 28 Jan 94 13:28:53 EST
Received: by relay.tis.com; id AA28792; Fri, 28 Jan 94 13:29:22 EST
Received: from babyoil.ftp.com(128.127.2.105) by relay via smap (V1.0mjr) id sma028789; Fri Jan 28 13:28:59 1994
Received: from tri-flow.ftp.com by babyoil.ftp.com with SMTP id AA08125; Fri, 28 Jan 94 13:28:43 -0500
Received: by tri-flow.ftp.com.ftp.com (5.0/SMI-SVR4) id AA02665; Fri, 28 Jan 94 13:28:39 EST
Date: Fri, 28 Jan 1994 13:28:39 -0500
Message-Id: <9401281828.AA02665@tri-flow.ftp.com.ftp.com>
To: romanov@nacto.lkg.dec.com
Subject: Re: SNMPv2 security
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Frank Kastenholz <kasten@tri-flow.ftp.com>
Reply-To: kasten@ftp.com
Cc: snmp@psi.com, snmpv2@magellan.tis.com
Content-Length: 2420

 > > The whole point of this exercise is to remove the mandated need for
 > > DES -- that is, to remove the Priv. The intent of this scheme is to
 > > provide a way to distribute and update Auth keys without requiring an
 > > encryption algorithm (like DES) which would run afoul of various
 > > export laws. In this context, your statement is a nonsense.
 > 
 > I understand this, but there is a feeling I have all the time that
 > for exmaple if we have seed keys say in parties 3 and 4, without
 > DES all other keys a chained to these keys through the XOR updates,
 > which in turn makes key breaking work easier and more dangerous:
 > one cannot prevent intruder from information base building and
 > key updates chains and once one key is broken potentially many keys
 > are broken.

I am not sure what you mean here. I can read it as either:
1) A manager has to change N keys in an agent, each one of these
   keys belonging to a separate party,
2) A manager changes the key for 1 party N times -- say every day
   at 1200 the manager changes the key in an agent -- just to be
   safe.

In the first example, each transaction uses a different Knew and
Kold.  Each party in an agent should, for safety, have a different
key. The transactions are safe since they do not share any values:
when the manager updates the key to party 1, it sends Knew1 xor
Kold1, when it updates the key for party 2 it sends Knew2 xor Kold2,
and so on. Knew1 != Kold1 != Knew2 != Kold2...




In the second example, over the course of time a manager changes a
key for a particular party, say N times. Assuming that the party's
initial key is K0, over time, the transactions look like:  
        K1 xor K0
        K2 xor K1
        K3 xor K2
        K4 xor K3

If you manage to intercept all transactions, you will have only 2
transactions which contain any given key-value. In effect, you have
two numbers, each of which is the exclusive or of a constant (the
key) and a different, unknown random number.

Just to show the point, assume that keys are 8-bits long. Let us say
that you have intercepted the first ten key changes from a manager to
a specific agent (e.g. the (K1 xor K0) ... (K10 xor K9) exchanges,
above). The data that you have received are: 0xbf, 0x99, 0x25, 0xc1,
0x2e, 0xc7, 0x9d, 0xc4, 0x51, and 0x45. What are the keys?


--
Frank Kastenholz
FTP Software
2 High Street
North Andover, Mass. USA 01845
(508)685-4000