Re: SNMPv2 security

Julie Tarr <tarr@itd.nrl.navy.mil> Mon, 31 January 1994 19:55 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12267; 31 Jan 94 14:55 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12263; 31 Jan 94 14:55 EST
Received: from relay.tis.com by CNRI.Reston.VA.US id aa12889; 31 Jan 94 14:55 EST
Received: by relay.tis.com; id AA02044; Mon, 31 Jan 94 13:32:58 EST
Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.0mjr) id smac02034; Mon Jan 31 13:32:30 1994
Received: from magellan.tis.com by magellan.TIS.COM id aa23182; 31 Jan 94 13:31 EST
Received: from sol.tis.com by magellan.TIS.COM id aa23176; 31 Jan 94 13:25 EST
Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04922; Mon, 31 Jan 94 13:25:22 EST
Received: by relay.tis.com; id AA01958; Mon, 31 Jan 94 13:25:55 EST
Received: from itd.nrl.navy.mil(128.60.2.2) by relay via smap (V1.0mjr) id sma001947; Mon Jan 31 13:25:01 1994
Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA12951; Mon, 31 Jan 94 13:23:31 EST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Julie Tarr <tarr@itd.nrl.navy.mil>
Message-Id: <9401311823.AA12951@itd.nrl.navy.mil>
Subject: Re: SNMPv2 security
To: kasten@ftp.com
Date: Mon, 31 Jan 1994 13:23:29 -0500
Cc: Richard Hale <hale@itd.nrl.navy.mil>, snmp@psi.com, snmpv2@magellan.tis.com
In-Reply-To: <9401311510.AA13053@tri-flow.ftp.com.ftp.com> from "Frank Kastenholz" at Jan 31, 94 10:10:39 am
X-Mailer: ELM [version 2.4 PL22]
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Length: 2294

Kastenholz says:

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

You are assuming that we know whether or not the keys have been compromised.
A key distribution system must be secure in either case, in fact, the main
reason for a key distribution system is for when the keys have been 
compromised.  Neither of these schemes work in the case of the old key
having been compromised.

There are two reasons to change keys in a cryptographic system - 1)  The old
key has been compromised, and 2) to protect them from a 
cryptanalysis threat.  In the first case, neither the XOR scheme or using DES
with the old key will work.  In the second case, the idea is to 
limit the amount of time the
cryptanalysist has to break the keys.  When you XOR the old key with the new
key, you are providing no protection from the cryptanalysist!  The attacker 
can continue to try to break the first key and once that is accomplished, he 
can simply calculate the current key using the original key and all of the 
key update XOR values.  And if you use DES with the old key to send the new 
key, the attacker can do the same - once he has the old key he can decrypt the
key update messages to determine the new key.  So... neither of these schemes 
works in the second case.

If you don't think you need to provide protection 
from a cryptanalysist - then why change keys?  

In the proposed SNMPv2 system, the only way to provide secure key distribution
is to create a desPriv/md5Auth party that is used only to send the keys of the
other parties.  The keys of this party, however, would have to be updated
manually.

Julie Tarr
Naval Research Lab
Secure Networks Group
(202)767-2274