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

Re: notes from developer's portion of IETF meeting

> As I recall, integrity is required for security _only_ when there are
> mutually hostile users ...

One terminology nit: I say "mutually suspicious" rather than "mutually
hostile", as actual hostility is not required, merely suspicion that
the other guys are, or may become, hostile..

> ... on multi-user systems at both ends of the
> connection/path.  These multi-user systems "know" that they require
> integrity, and can negotiate it appropriately.

This is true only if you consider an encrypting router fronting for
multiple mutually suspicious end users to be a multi-user system.

> OTOH, a dialup user encrypting to a firewall (or even their target
> multi-user host) from a laptop would _not_ require added integrity.  Big
> interactive RTT savings on a low speed link.

This is simply not true if the firewall is fronting for mutually
suspicious users.  This may seem improbable, but I know of sites where
(for historical reasons) two different organizations sharing a
building also share a large chunk of the network infrastructure..

Here's a very specific, concrete example, of a case where lack of
integrity leads to lack of confidentiality.

			  A
			/
	C =====M==== GW  
                        \ 
                          B


assume a pair of ESP SA's between C and GW (one in each direction) so
there's a single key in use in each direction between C and GW; assume
also that the encryption in question is a block cipher in CBC mode.

assume that B can't tap the A-GW link because it's physically secure,
but wants to spy on A->C traffic; it also has a wiretap/traffic
injection point at M, where it can inject arbitrary messages into the
network.

assume C runs an ICMP echo service.

B sends a large ICMP echo request packet to C, and captures the
encrypted form of the packet at M.

so, what it has is:

	IV  
	ciphertext of B->C ICMP header
	ciphertext of B->C ICMP data
	ciphertext of pad			(at least one full block's worth)
	ciphertext of B->C ESP trailer

B also captures traffic it wants decrypted.  it then constructs a
packet of the form:

	IV 
	ciphertext of B->C ICMP header
	IV of the A->C message			<---+-- same length as
	ciphertext from A->C message		<---+   ICMP data above
	ciphertext of pad
	ciphertext of B->C ESP trailer

Because of the properties of CBC-mode ciphers, C will receive an ICMP
packet with a valid header, a garbled data block corresponding to the
A->C IV, the plaintext of a sequence of blocks from A->C message,
another garbled block (conveniently located in the middle of the
padding) and then a valid ESP trailer.

C will then promply return the decrypted plaintext to B in an ICMP
echo reply.

One might think that the icmp checksum might get in the way, but
there's at least one way around this which only adds a work factor of
2**16-1: B can construct echo packets with all 2**16-1 possible
checksums, and try all of them; C returns the one for which the
checksum matches.

Tapping the C->A traffic is even easier: pull the encrypted packets at
M, substitute the ciphertext into the middle of the encrypted ICMP
reply from C to B, and send them (again) to GW; B simply "forgets" to
check the ICMP checksum on reciept.

					- Bill
Follow-Ups: References: