Re: SNMPv2 security

Frank Kastenholz <kasten@tri-flow.ftp.com> Mon, 31 January 1994 15:50 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05735; 31 Jan 94 10:50 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05731; 31 Jan 94 10:50 EST
Received: from relay.tis.com by CNRI.Reston.VA.US id aa04929; 31 Jan 94 10:50 EST
Received: by relay.tis.com; id AA28700; Mon, 31 Jan 94 10:29:32 EST
Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.0mjr) id sma028685; Mon Jan 31 10:28:37 1994
Received: from magellan.tis.com by magellan.TIS.COM id aa21912; 31 Jan 94 10:20 EST
Received: from sol.tis.com by magellan.TIS.COM id aa21908; 31 Jan 94 10:11 EST
Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21141; Mon, 31 Jan 94 10:10:55 EST
Received: by relay.tis.com; id AA28565; Mon, 31 Jan 94 10:11:27 EST
Received: from babyoil.ftp.com(128.127.2.105) by relay via smap (V1.0mjr) id sma028557; Mon Jan 31 10:10:59 1994
Received: from tri-flow.ftp.com by babyoil.ftp.com with SMTP id AA18521; Mon, 31 Jan 94 10:10:50 -0500
Received: by tri-flow.ftp.com.ftp.com (5.0/SMI-SVR4) id AA13053; Mon, 31 Jan 94 10:10:39 EST
Date: Mon, 31 Jan 1994 10:10:39 -0500
Message-Id: <9401311510.AA13053@tri-flow.ftp.com.ftp.com>
To: uri@watson.ibm.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: romanov@nacto.lkg.dec.com, snmp@psi.com, snmpv2@magellan.tis.com
Content-Length: 2424

 > Frank Kastenholz says:
 > > The more traffic in the same key that you have, the easier it is to
 > > break the code. It is much much harder to break a key when you have
 > > one message than when you have many messages.
 > 
 > But in cryptography "new key" means new key - and normally
 > one doesn't tell his opponent exactly _how_ he changed the
 > key.  And that's just what you're doing sending the update
 > over in clear.

Yes, this is a weakness -- the only part of the key update message
that is protected is the key itself. But you can use a party-pair
that includes privacy if you wish. Remember, the XOR algorithm is the
minimum required, it is not the maximum that you may do.

 > >  > Thus - what do we save by "changing" the key in such a funny way?
 > > Ok, suppose you and I are using Kold to communicate. We wish to go
 > > to a new key, Knew.
 > > I send you Knew DES-encrypted with Kold. Now, for a third party to
 > > get Knew from that transaction, they would have to know Kold.  Right?
 > > OR
 > > I send you Knew xored with Kold. Again, for the third party to get
 > > Knew from the transaction they would have to know Kold. Right?
 > 
 > Of course not. Don't you see, that introducing relations
 > between the old and the new keys is what normal
 > cryptographers are avoiding at any cost?

You are not introducing a relation between the new key and the old
key.  The new key is chosen in some manner that (presumably)
decouples its value from the old key's value -- say a true random
number generator. 

   
 > Don't you see the difference between sending Knew encrypted
 > with something secure and not exposed and encrypting it
 > with old worn-out key?

Look, either Kold is compromised or it isn't. If it is compromised,
it does not matter whether you send Knew encrypted with DES/Kold, or
XORing Knew and Kold. Either way, the bad guy has Kold and can read
Knew. If Kold is not compromised, that is, it is still a secret, then
you can send Knew either XOR'd with Kold, or DES-Encrypted with Kold.
It won't matter.

Remember that using SNMPv2 to update keys is going to be secure if
and only if Kold is secure.

If you believe that Kold has been compromised then, in order to
maintain security, you should resort to some other mechanism to
distribute new keys (probably manual distribution). 



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