Re: comments on draft-ietf-idpr-specv1-02.txt

Frank Kastenholz <kasten@ftp.com> Mon, 15 March 1993 22:38 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24971; 15 Mar 93 17:38 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24967; 15 Mar 93 17:38 EST
Received: from PIZZA.BBN.COM by CNRI.Reston.VA.US id aa02809; 15 Mar 93 17:38 EST
Received: from pizza by PIZZA.BBN.COM id aa01127; 15 Mar 93 17:30 EST
Received: from BBN.COM by PIZZA.BBN.COM id bb00790; 15 Mar 93 17:26 EST
Received: from ftp.com by BBN.COM id aa28619; 15 Mar 93 10:02 EST
Received: by ftp.com id AA07145; Mon, 15 Mar 93 10:02:46 -0500
Date: Mon, 15 Mar 1993 10:02:46 -0500
Message-Id: <9303151502.AA07145@ftp.com>
To: jnc@ginger.lcs.mit.edu
Subject: Re: comments on draft-ietf-idpr-specv1-02.txt
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Frank Kastenholz <kasten@ftp.com>
Reply-To: kasten@ftp.com
Cc: idpr-wg@bbn.com, mccurley@cs.sandia.gov

 >     They provide NO guarantee of source authenticity, and the only
 >     integrity that they show is that the data has not been changed since
 >     the time that the MD4/5 hash has was created. Unfortunately, since
 >     MD4/5 ARE NOT digital signature algorithms ... If you are looking for
 >     a full digital signature algorithm, then you need something like RSA
 >     or DSA. ... MD4/5 were never intended for the purpose you describe,
 >     and provide essentially no authentication.
 > 
 > If the input to the hash function (MD4/5) includes not only the data, but a
 > secret, known only to the source and destination, isn't the resulting hash
 > output a digital signature? (Agreed, the key management is not as nice as a
 > hash function combined with a private-key, since you need N^2 rather than 2N
 > keys for the same degree of unspoofability.)


Noel,

You are correct. This is exactly the algorithm used for SNMP
security, developed by the folks in long trenchcoats and sunglasses
:-) The only real difference is that SNMP includes some time stamps
in the packet header so that you can detect replay attacks and
message re-ordering.

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