Ordering of shared Phase 1/ISAKMP VPN policies

Question

The various Phase 1 settings of a VPN tunnel policy are fairly well-established (encryption, hashing, DH group, lifetime), but in what order are they considered applicable to a more-secure tunnel?

I am fairly certain I know which values of each tuple are more secure (please correct me if I am wrong):

• encryption: aes-256, aes-192, aes-128, 3des, des
• hashing: sha1, md5
• group: 5, 2, 1
• lifetime: 3600, 28800, 86400

But which tuples should I prioritise in combinations?

Is the encryption more 'important' than the hash? Is the hash more important than the group? Would an aes-256/md5/group5/3600 policy be deemed more secure than an aes-256/sha1/group2/3600 policy?

---

Background

I am running a Cisco ASA firewall, with a number of site-to-site VPNs (i.e. to client sites). In the past, we have always put these in an additive/incremental fashion and pretty much just added whatever Phase 1/ISAKMP policy the client wanted to the end of the policy list.

Recently, a client has come back and asked that we change their Phase 1 settings from 3DES to AES256. As such, we added the new phase 1 settings to the list, but it still establishes with the 3DES settings, which I did not take out in case another client VPN also used it (the ASA shares the Phase 1 policies, prioritises numerically and does not make it particularly easy to determine which policy is used by which tunnel).

It looks like, in an ASA-to-ASA tunnel, the recipient device chooses the policy from a list sent by the initiator, based on its own policy order not that of the initiator. So it looks like I will have to reorder the policies.

Now, instead of just prioritising by loudest client, I would rather do so such that a policy considered more secure is prioritised over a weaker/legacy one, which should mean that an ASA-to-ASA tunnel will automatically pick the most secure route, while any policy-per-tunnel device should just use the one it is configured to use.

---

Possible solution

I have read that the purpose of the hash function is for the recipient to verify the decrypted packet, which might lend itself to the Encryption tuple being more 'important' than the Hash tuple.

I have also read that the DH Group is used initially to provide a calculable challenge against the pre-shared key, so it might stand that this is more 'important' than the Hash, too.

Lifetime obviously denotes how often to re-establish the tunnel, but plays no real part in the tunnel itself.

All of which leads me to think that order of importance might be:

• Encryption
• Group
• Hash
• Lifetime

Does this seem reasonable?

Answer 1

There are secure options, and less-secure options. How you order the secure options is less important than that you avoid the poor choices.

For example, DES is pretty handily broken because the key length is insufficient. It should simply not be allowed. 3DES is slow but theoretically not broken (though some say that certain governments have optimized hardware for DES/3DES cracking). It's best to avoid if possible, but depending on what clients you allow, you may have no choice but to allow it.

MD5 is probably not a great solution either for crypto use because it is directly susceptible to attack, but again, depending on whom you're allowing to connect, you may not be able to avoid it. Chances are pretty good that if someone doesn't have access to AES and has to use 3DES, they won't have an implementation of SHA1 either, so perhaps MD5 and 3DES should be grouped together. It's also quite likely that such a person is actually calling from 1997 and perhaps you can make them some money by sending them some contemporary sports statistics. And perhaps you just want to drop 3DES and MD5 altogether, because really.

Decisions like 128, 192, or 256 are probably not particularly important; AES 128 is already 100% unbreakable accordingly to current understanding. AES-128 is faster, while AES-256 (theoretically) offers a wider safety margin. Bruce Schneier thinks that AES-128 has a better key schedule, so the security is likely a wash. So if you have a preference, prioritize accordingly.

And perhaps options such as lifetime may be important to your organization, or perhaps they are not. So In those cases you simply include all the options you will allow in whatever order you think is best-to-worst. The other party will do the same, excluding the options that their own policy does not allow. Together you'll agree on a combination incorporates the best allowable elements from each.

Answer 2

There won't be a crypto breach. You have to use thoroughly bad cryptographic algorithms to actually get in trouble that way. For instance, in your listed encryption algorithm, only DES is breakable in practice, and even then it is still a rather daunting task (2⁵⁶ encryptions, that's not a week-end's computations on a gaming PC).

The biggest impact of cryptographic algorithms on security comes from performance: if the algorithms imply poor performance, users will begin to look for alternate solutions, which your VPN will not protect. E.g. transmitting data through Gmail.

Thus, you should concentrate on efficient algorithms. Then take care of public relations: MD5 is fine for integrity checks (e.g. when used in HMAC) but you will want to avoid it because of its sulfurous reputation: MD5 is "broken". That it is broken with regards to collisions but not at all for use as part of HMAC is a detail that most people dismiss as boring -- any idea which cannot be expressed in less than 17 syllables (the length of a well-formed haiku) will never show up on the paranoia radar. Similarly, use AES, not 3DES. Use AES-256 if you need to make a show of muscle (AES-256 is 40% slower than AES-128, but that's rarely critical in practice).

If you really need some classification, even somewhat meaningless, do it in the following four layers:

• Weak, to be avoided: DES, 768-bit Diffie-Hellman
• Medium, won't be broken but has bad Public Relations: 3DES, MD5, 1024-bit Diffie-Hellman.
• Strong, good to use: AES-128, SHA-1 or SHA-256, 2048-bit Diffie-Hellman.
• Strong, overkill, needed to subjugate paranoid auditors: AES-256, SHA-512, 3072-bit Diffie-Hellman.

As for key lifetime, it is a stupid remnant from the times when cryptography was done with a pencil and could be assumed to be broken on a regular basis by the proto-geeks employed by the other countries.