|Subject:||CIPE protocol crypto questions|
|From:||errzyy3i,AT,umail,DOT,furryterror,DOT,org (Zygo Blaxell)|
|Date:||Sun, 11 Feb 2001 21:54:38 +0100|
I've been reviewing the CIPE protocol recently, both before using CIPE and now after the recent WEP protocol breakage by Golberg, Borisov, and (insert name here, I forget just now ;-). Here are three questions about behavior observed and documented with CIPE 1.4.5 on Linux 2.2.17/18: 1. The carrier UDP packets seem to have the same IP TOS and DF bits as the encrypted IP packets they carry. I can't figure out if this is a bug, a feature, or just an accident. Here is the case for each: a. It's a bug, because it allows traffic analysis on the packets. I have one VPN that carries only SSH, web browsers, ICMP echo/reply, DNS and NTP traffic, and it's possible to identify which CIPE carrier packets belong to each protocol by looking only at the IP flags. Also: How would TCP path MTU discovery work? PMTUD requires receiving an ICMP fragmentation-required message with the correct MTU, but if the DF bit is set on CIPE's UDP carrier packet, and a router on the Internet sends an ICMP fragmentation-required message, then this ICMP message will be sent to the CIPE peer, and _not_ to the TCP peer that needs the path MTU information. Judging from the mailing list traffic over the last year, this seems to be an often-encountered but little-understood problem. b. It's a feature, because if you care enough about IP TOS to set it for your application on the VPN, then you want routers on the Internet carrying the UDP carrier packets to have the same routing information. This justifies TOS bits, but not DF. Either way, it should be a configurable option due to the traffic analysis problems, and the documentation should be updated to point out that this information is actually available outside of the encrypted packets... c. It's an accident, because most of the code for CIPE was copied unaudited from the IPIP tunneling code... 2. The current protocol uses two kinds of packets, encrypted with different keys. These packets are distinguished by one bit of the IV of each packet. This creates two kinds of problems: a. It's easy to isolate the key exchange, ping, etc. packets from the IP-carrying data packets by checking this bit, and b. If the packets can be isolated, they can be filtered, to prevent new key exchanges from taking place. I've observed case B occurring by accident, when the route between two ends of a VPN became unusable in one direction. Traffic continued to be received for hours, despite the dynamic key renegotiation interval of 10 minutes and the inability of one peer to receive key exchange packets from the other. Other postings on the CIPE list indicate that key exchange takes place using the current dynamic key, instead of the shared static key, if there is a valid one known to both peers. If true, this would effectively turn this problem into a simple DOS (by preventing the dynamic key from ever being negotiated at all). The documentation doesn't seem to mention this, though. It would seem to me there are two effective remedies for this problem: a. Assume that 99%+ of the traffic is encrypted using the most recently negotiated dynamic key, and always try the most recently negotiated dynamic key, then the second most recently negotiated dynamic key, then the static key, relying on the CRC of each packet to identify when the decryption was successful. This would allow the 64th bit of the IV to be random again. b. Encrypt the IV using the static key and cipher in ECB mode. This would prevent trivial identification of which packets are for key exchange and which for data, unless the receiver knows the static key. 3. The CRC function for validating each packet is linear. If some properties are known about the data and cipher used, it is easier to modify a packet and maintain a correct CRC than certain other hash functions. This attack can theoretically be used against SSH, which uses CRC's for integrity checking as well. WEP is completely vulnerable to this kind of attack, because it uses RC4 as a cipher. Using a CRC of an MD5 or SHA-1 hash comes to mind as a possible solution--the message integrity check data is the same length, but the function is no longer linear wrt the encrypted data. If we are willing to accept a larger protocol overhead, an entire MD5 or SHA-1 hash can be used as well.
Description: "PGP signature"