Re: SNMPv2 security

[Keith McCloghrie <[e-mail]>]

> 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 SNMPv2, there is a third reason: to allow the clock to be reset without
allowing all previous messages to be replayed.

> 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 "linear" (as someone else called it) change of XOR-ing the keys can
have two impacts:

1. it doesn't make the cryptanalyst's job any easier, it could make no 
difference, or (my guess) it could make it at least a little harder,
although the amount by which it is harder may be negligible, I don't know.

2. without the XOR, the cryptanalyst can work from any subset of the
messages; with XORs, the cryptanalyst must capture all the packets
to/from that agent, inspect them all for a) SetRequests which modify
partyAuthPriv, and b) the matching Response messages to make sure that
the identified SetRequests were successful, etc., and then factor the
changes into the calculations.  Wouldn't you say that make the job a
bit harder ?

> If you don't think you need to provide protection 
> from a cryptanalysist - then why change keys?  
 
Primarily, for the third reason above.  Secondarily, to make the
crpytanalyst's job at least a little harder.

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

Certainly, for those who want protection from cryptanalytic attack.
For those who want protection from occasional snoopers, the use of XOR
may be sufficient.

Keith.