Re: [Cfrg] Request For Opinions

[Alfonso De Gregorio <adg@com-and.com>]

Dear Jon,

the mechanism the working group have come up reminds me the method employed
in syslog-sign [1] to add "origin authentication, message integrity,
replay-resistance, message sequencing, and detection of missing messages"
to the BSD syslog protocol [2].

As far as I can tell, in a generic application context (i.e., not in the
message logging one), this mechanism is less than optimal since the 
recipient cannot rely neither upon the integrity, nor upon the 
authenticity of exchanged PDUs until authentication-PDU get received.

Hope it helps.

Cheers,
Alfonso

[1] C. Lonvick, "The BSD syslog Protocol", rfc 3164,
    <http://www.ietf.org/rfc/rfc3164.txt>

[2] J. Kelsey, J. Callas, "Syslog-Sign Protocol",
    draft-ietf-syslog-sign-10.txt,
    <http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-10.txt>


On Mon, May 05, 2003 at 11:52:34AM -0400, jsjoberg@toplayer.com wrote:
> Hey all,
> 
> I'm in an ETSI working group and we are trying to find a way to provide
> integrity checks along with non-repudiation on a theoretically infinite
> amount of data delivered over a network at 10's to 100's Mbps.
> Crypto-hardware is not a reasonable expectation and the solution is
> extremely cost sensitive.  
> 
> The data link will be sending PDU's an an as need basis, with each PDU being
> tagged with a sequence number.  At some point later in time
> (days/weeks/years) we need to be able to prove the integrity of the PDU's as
> well as the authenticity.
> 
> The following is what we have come up with and I'm wondering if anyone has
> anything to add, remove, or change that would make a better solution.  The
> idea is to get some of the authentication strength of DSS/DSA without the
> full strength or the full cost (in processing time).
> 
> Thanks in advance for any input,
> Jon
> 
> Periodically, hashes over the data PDUs will be inserted into the data
> stream. A hash will only be created if at least one PDU packet was sent
> since the last hash was sent or since startup.
> 
> Every <n1> PDU packets or when <t1> seconds have passed a MD5 hash is
> generated over all PDU
> packets sent since the last MD5 hash was sent or since startup. The MD5 hash
> is sent in a HashPDU, where the HashSequenceNr increments for every hash
> sent for this intercept. The array PDUSequenceNrsIncluded contains the
> sequence number of every data PDU that was included in the hash.
> 
> NOTE: The values for n1 and t1 are configurable. 
> 
> Periodically, a hash over the hashes specified above and a signature of that
> hash, will be inserted into the  the data stream. The signed hashes allows
> authentication of the sender and to verfify the integrity of the recevied
> MD5 hashes.
> 
> Every <n2> hashes or when <t2> seconds have passed, a MD5 hash is generated
> over all hashes sent since the last signed hash was sent or since startup
> and that MD5 hash is signed
> using DSS/DSA. The MD5 hash and corresponding DSS/DSA signature are sent
> over in a SignedHashPDU, where the SignedHashSequenceNr increments for every
> signed hash sent. The array HashSequenceNrsIncluded contains the sequence
> number of every HashPDU that
> was included in the signed hash.
> 
> NOTE: The values for n2 and t2 are configurable.
> 
> NOTE: The distribution of the DSS/DSA public key is outside the scope of
> this specification.
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@ietf.org
> https://www1.ietf.org/mailman/listinfo/cfrg
_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg