[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Cfrg] Request For Opinions

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

--

Alex Alten
Alten@ATTBI.com



_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg