Subject: Re: [Cfrg] Request For Opinions

From: Alex Alten <[email-masked]>
Date: Wed, 07 May 2003 22:44:21 -0700

Hey JS Joberg,

I have been dealing with a very similar problem for the past couple of
years where we are limited to a software driver plugging into a stack.
I'm a bit pressed for time but here is a quick rundown of what I've found.

1. You cannot use any PKI, too slow for 100 Mbps networks, especially
     if you are datagram or transaction oriented with communications
     occurring among N nodes unpredictably.

2. Best to hash per packet, but current hashes are too big, at least
     for Ethernet MTU's.  I don't recommend maintaining a hash state
     across a series of packets, especially if packets can be lost, mixed
     up, or duplicated/retransmitted (true for most protocols).  And unless
     you enjoy debugging complex state machinery.

3. You must specify how manage authentication and encryption keys
     as part of your spec, otherwise it will be a failure.  Not just key
     exchange, the whole thing.  By failure I mean a lack of interoperability
     between vendors that drives costs up, this is the opposite of what
     a standard should achieve.  By whole thing I mean who has the
     authority to hand out authentication keys, how are keys refreshed,
     how do you handle bad or damaged keys, etc.

4. Think through how you will archive hashes.  What happens if a link
     goes down or your archive crashes.  What operations can proceed
     and those that cannot. How can you recover it? All this can be non-
     trivial.

5. Think simple.  Use memory where possible to reduce design/code
     complexity.

6. Last but definitely not least.  How do you manage your nodes
     address or name ID space.  How are authentication keys bound to
     IDs?  Are keys transient or not? I tend to like a number system
     similar to IP addresses (but don't use them directly!), it's simple
     and easy to distribute the address space management.

I'm sure there are dozen more items I've left off the list, and I'm equally
sure that someone, somewhere will object to each one of these items
above.  Ask them to present their own list to you and to us in CFRG.
It will make for interesting reading if nothing else.

Again, be aware that you need to specify the entire system, not just
a set of protocols.  This is because you must manage keys and IDs
besides the secure packets or the authentication handshakes.

Good luck,

- Alex

At 11:52 AM 5/5/2003 -0400, [email-masked] 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
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/cfrg

--

Alex Alten
[email-masked]

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: [email-masked]
Date: Thu, 8 May 2003 01:59:22 -0700 (PDT)

it has its warts, but some folks are thinking of trying to leverage
DNSSEC and Oportunistic Encryption as tools.  Still stuck w/ the key mgmt
problems.

--bill