19 Jan 2014
Some time ago, in 2005, Tuomas Aura of Microsoft Research proposed a way to embed a "cryptographic proof" in the IPv6 addresses. The idea was to tie the address to a public key, by encoding in the IID part of the address the hash of a public key. This would allow IPv6 nodes to prove ownership of the address by signing a message with their private key, and then showing how the IID address is derived from the public key. Tuomas envisaged a set of applications, e.g. encryption of data using IPSEC, or secure roaming with IP mobility, but the IETF only picked the idea in the context of "secure network discovery," defined in RFC 3791. The address format defined by Tuomas came to me known as "Cryptographically Generated Addresses (CGA)", defined in RFC 3792. SEND and CGA looked like good ideas at the time, but 9 years have passed and we don't see a lot of adoption.
More recently, another researcher, Hosnieh Rafiee, revisited that design and proposed an alternative way to tie public key and IPv6 addresses, which she calls "A Simple Secure Addressing Scheme for IPv6 AutoConfiguration" (SSAS). She also wrote a draft presenting her view of the issues with SEND, titled "Recommendations for Local Security Deployments." I am happy to see researchers working on IPv6 and revisiting the issues that we studied years ago, but I have a problem with that specific proposal. The SSAS algorithm is insecure, as is strength is limited to exactly 64 bits, way too short to prevent spoofing. The local security arguments against CGA and RA-guard are specious, and in at least one case just wrong. For me, it would be much more pleasant to just help a young researcher, but it is one of those cases where I have to write a review that "rejects the paper."
Draft-rafiee-6man-local-security-00.txt appears a motivating draft, designed to encourage adoption of SSAS. Hosnieh has to make two points, first that the current solutions for local network security are inadequate because SEND is not deployed, and second that the reason why SEND is not deployed is because of issues with the CGA specification, which would be fixed by her SSAS proposal. The current solution for local security is to rely on link level security procedures like 802.1x or Wi-Fi Protected Access (WPA), complemented with filtering of router advertisement by the local switches, defined in RFC 6105, IPv6 Router Advertisement Guard (RA-Guard). Of course, applications should also use end-to-end security protocols like IPSEC or TLS.
Section 3 of the draft-rafiee-6man-local-security-00.txt purports to demonstrate the insufficiencies of the RA-guard solutions. I found it somewhat confusing. Someone else may want to review it, but I believe that some of the statements made there are just wrong. For example, saying that "this feature is supported only in the ingress direction" is bizarre – the whole point is for switches to filter spurious RA from misconfigured local hosts, or from local hosts infected by a virus. Similarly, saying that this does not protected tunnels is also a bit bizarre, since point-to-point tunnels are protected by their own configuration methods.
Section 4.1.1.1 of the draft-rafiee-6man-local-security-00.txt assesses that the IPR restrictions on CGA have prevented the deployment of SEND. This is a bit specious, since the IPR owner, Ericsson and Microsoft, have both granted royalty free licenses. It is true that some open source developers are put off by any licensing condition, even royalty free, but there are plenty examples of protocols with similar restrictions that have been widely adopted. In any case, the IPR situation cannot explain why SEND was not deployed by Microsoft, who owns one of the CGA patents.
Section 4.1.1.3 of the draft-rafiee-6man-local-security-00.txt purports to demonstrate an attack against CGA. The discussion on the mailing list showed that this attack relies on a downgrade of the CGA SEC value. But since the SEC value is actually part of the address, the attack cannot actually be used against CGA+SEND. Several people pointed that, but Hosnieh kept reasserting her same arguments, and the discussion was really not productive.
The valid argument against CGA is that it is only secure if we use non zero values of the SEC parameters, but that doing so requires expensive computation. This consume too much power, and may deplete a mobile device's battery. Nobody doubts that, but it is pretty much a consequence of the short size of the host identifier field. When it comes to cryptography, 64 bits is not a large number. 80 bits might be acceptable now, but we should really only use 128 bits in the future. CGA anticipated that problem with the SEC field, which complements the limited size host identifier with a requirement that the hash starts with a specified number of zeroes. This is expensive but proven. Bitcoin for example uses a similar algorithm for its "proof of work."
The purported advantage of SSAS is that the IID is much easier to compute than CGA hashes with non-zero SEC numbers. That is true, but the corollary is that SSAS is subject to an obvious attack. According to <draft-rafiee-6man-ssas-08.txt> the "secure" IP address would be derived by concatenating the local prefix and a host ID derived from a public key. The public key is normally an EEC key longer than 196 bit. The host ID is derived as follow:
2. Divide the public key array of bytes into two half byte array (see figure 1). Obtain the first 4 bytes from the first half byte array and call it the partial IID1. Obtain the first 4 bytes of the second half byte array and call this the partial IID2. (Dividing the public key is only for randomization)
3. Concatenate partial IID1 with partial IID2 and call this the IID.
The problem with that approach is obvious. An attacker can simply generate a large number of public keys, and build a catalog of 64 bit identifiers. In at most 2^64 attempts, the attacker will have obtained an IID that matches any target address. Since there is no hashing or proof of work involved, there is no way to improve the security in the future.
This is a fundamental flaw, and I wonder why Hosnieh continues to push this flawed approach. The only significant change between the initial SSAS algorithm and draft 08 is to replace the use of RSA public keys by ECC keys, probably based on the belief that ECC keys cannot be generated so easily. But picking a new ECC key is actually rather simple. RFC 6090 describes it in section "5.3.1. Keypair Generation:"
The private key z is an integer between 1 and q-1, inclusive, generated uniformly at random. (See Appendix B regarding random integers.) The public key is the group element Y = alpha^z. Each public key is associated with a particular parameter set as per Section 3.3.
Given that, the attack by generation of 2^64 keys appears well within the means of today's attackers. Wait a few turns of Moore's law, or implementations on GPU or FPGA, and SSAS will be trivially broken by random hackers.