Non-political, so probably off-topic for CP :_)

[measl at mfn.org]

In case anyone has *any* interest...

---------- Forwarded message ----------
Date: Mon, 17 Dec 2001 14:29:43 -0500
From: Franco Travostino <travos at nortelnetworks.com>
Reply-To: anon at wireless.eecs.harvard.edu
To: Anon Fwd <anon at wireless.eecs.harvard.edu>
Subject: Re: Anon Fwd: analysis of covert channels in 
    draft-kung-annfwd-framework


Geoff,
the security protocol that you're describing---i.e., generate a symmetric 
key and ship it encrypted with the recipient's public key---seems very 
expensive for a layer 3 forwarder (or, better, for what I think that that 
beast is, really). I understand that  a) you have limited a forwarder's 
scope to processing signalling data only, and b) PGP email, for one, use 
keys pretty much the way you said. Yet, I think one could do much better 
with a Diffie-Hellman cycle producing a batch of symmetric keys, which need 
not to be exchanged across the wire. This is what IKE (rfc2409) does. IKE 
has all sort of wrinkles to it in order to thwart DH vulnerabilities to 
men-on-the-middle attackers. A forwarder implementing such solution could 
attain a wide range of throughputs, possibly exceeding 1Gb/s with hardware 
crypto-assists (as commodity VPN boxes show today). Public key operations 
as you scoped will definitely lock you out of these ranges.

-franco

At 03:39 PM 12/15/2001, Geoffrey L Goodell wrote:
>In our last meeting, we discovered that we could discard the various metadata
>fields in our protocol, thus reducing the ability for attackers to discover
>clients or servers by sending an exorbitant number of packets to a forwarder
>and simultaneously monitoring the forwarder's output link.  So, with the
>stipulation that the various field types have a specified size, and each
>forwarder only provides exactly one of the three anonymity options (client,
>server, and bidirectional), the only means by which attackers can correlate
>their packets with packets found on the output link of the forwarder is to
>examine the data contained in the fields themselves.  In order for a 
>successful
>attack to be possible, it must be possible for an attacker to correlate the
>fields on the packet entering the forwarder with the packets leaving the
>forwarder; in other words, individual fields leaving the forwarder must be
>encrypted in such a manner to not be decryptable by the attacker into a form
>that the attacker can recognize.
>
>SUMMARY: We discover that the single-hop protocols are demonstrably free of
>covert channels, provided that the cipher upon which we ultimately decide is
>also demonstrably free of covert channels.  We find that if we expect to get
>away with packet sizes that do not grow linearly with the number of forwarders
>on the path between the client and the server, multi-hop forwarding depends on
>some sort of public-key infrastructure.
>
>THE "GOOD" NEWS: We need a public key infrastructure for our network of
>forwarders.
>
>THE ACTUALLY-GOOD NEWS: Clients and servers need not be a part of this 
>network,
>though forwarders must be able to verify the authenticity of their public 
>keys.
>
>DETAILS:
>
>----------
>
>I have examined the three single-hop protocols closely, and discovered the
>following:
>
>1. Client Anonymity
>
>C's certificate and the request are passed along by the forwarder on the 
>way to
>the server, so an attacker posing as a client can find the location of a 
>server
>by monitoring the forwarder's output link.  This is acceptable, though, since
>the protocol explicitly does not call for server anonymity.
>
>On the way back to the client, the message is encrypted in a symmetric key
>chosen by the forwarder, and the symmetric key is encrypted with the client's
>public key.  One apparent attack on this system would be to send a certificate
>for an arbitrary public key for which the attacker holds the corresponding
>private key; given enough computing power, the attacker could feasibly use 
>this
>private key to decrypt the symmetric key on packets leaving the forwarder and
>verify which ones contained the reply datum the attacker sent.  We can
>successfully defend against this attack by requiring that the forwarder verify
>the authenticity of the client's public key.
>
>So, to my knowledge, this protocol does not have any threatening covert
>channels.
>
>2. Server anonymity
>
>En route from the client to the server, the forwarder encrypts a packet with
>a symmetric key and sends that key encrypted with the server's public key.  To
>avoid an attack similar to the one suggested above with the client anonymity
>protocol, we require that the forwarder verify the authenticity of the 
>server's
>public key.
>
>On the way back, the messages can easily be correlated by an attacker.  But,
>symmetrically to above, the protocol explicitly does not call for client
>anonymity, and thus allowing an attacker to find client locations is
>acceptable.
>
>So, to my knowledge, this protocol does not have any threatening covert
>channels.
>
>3. Bidirectional anonymity
>
>En route from the client to the server, the forwarder encrypts the fields with
>a randomly generated symmetric key of its choosing, and sends the 
>symmetric key
>encrypted with the public key of the server.  Thus, we need the forwarder to
>verify the authenticity of the server's public key.
>
>On the way back, the forwarder encrypts the fields with a randomly generated
>symmetric key of its choosing, and sends the symmetric key encrypted with the
>public key of the client.  Thus, we need the forwarder to verify the
>authenticity of the client's public key.
>
>So, to my knowledge, this protocol does not have any threatening covert
>channels.
>
>----------
>
>The multi-hop protocols as described in the Internet Draft are like the
>single-hop protocols, with the important exception that specific fields
>are passed directly between the forwarders.  Here, we have two problems:
>
>A. Since one of the encrypted fields contains more and more information as it
>gets constructed, and never gets decrypted in the construction process, it
>necessarily grows in size.  This in turn means that information about the
>position of a particular forwarder in the path will necessarily be leaked.
>
>B. Since fields are passed directly between the forwarders without alteration,
>they can be correlated by an attacker to find the path through the forwarding
>network.  One possible solution to this is for the forwarders to choose
>randomly-generated symmetric keys at each hop, and then encrypt the relevant
>field with this key, and then send that key along, encrypted with the client's
>or server's public key.  The trouble with this is that the size of the packet
>becomes increasingly large, just as in (A).
>
>To eliminate the problem with linearly growing packets along the pathe need a
>PKI for the network of forwarders so that forwarders can encrypt and 
>decrypt at
>each hop.  This reduces the packets to a constant size (whatever we agree
>upon), and prevents the problems associated by the covert channels 
>described in
>(A) and (B) above.
>
>Geoff
>
>
>
>
>To post: mail to anon at wireless.eecs.harvard.edu
>To unsubscribe: mail anon at wireless.eecs.harvard.edu
>   with "unsubscribe" (no quotes) in the subject line
>To subscribe: mail anon at wireless.eecs.harvard.edu
>   with "subscribe" (no quotes) in the subject line
>To visit archive: go to http://wireless.eecs.harvard.edu/anon
>Comments, suggestions? Send them to
>   postmaster at wireless.eecs.harvard.edu


Franco Travostino, Director Content Internetworking Lab
Advanced Technology Investments
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: travos at nortelnetworks.com