On 10/21/19 4:41 PM, Jeffrey Haas wrote:
I'm not someone qualified, but I'll regurgitate what I've distilled from past conversations with those who are.:-)
Presuming your key is strong enough, it may be infeasible to break it in a time that's of interest to the parties involved. The primary issue is the usual issue of trying to keep anything secret: eventually disclosure becomes an issue. And if you have no procedure for periodically updating your keys, it becomes a problem.
Going back to my thought of using IKE vs. a static SPI, we run into the same problem with rekeying the long-term secret. If it's symmetric, you have to get both parties involved. That will be true if it's IKE with a PSK, a static SPI, or TCP-MD5. I guess the meat of my question is, given modern cryptography (algorithms, best practices, actual system implementations, etc.), is the periodic re-keyed offered by IKE with PSK any better than simply establishing a static SPI (treating the SPI session secret as a slightly less human-friendly PSK)? If not, then you can do away with IKE entirely which drastically simplifies things. It's also the status quo for many implementations of OSPFv3-over-IPsec that I've seen. My impression is that any means by which a long-lived session using the same symmetric cipher secret can compromise the security of either that session or any other session keyed using the same "parent" keying material is now considered a weakness in the cipher or cryptosystem, as appropriate, and modern ciphers and systems as such do not exhibit such deficiencies. It's also no worse than TCP-MD5 which, as you pointed out, requires both ends to cooperate in a re-keying, too. I'm not even aware of any mechanisms to allow key overlap during a re-keying process in TCP-MD5 which might otherwise be one advantage of IKE using PSK. If your SPI secret gets disclosed, you re-key manually. If your TCP-MD5 secret gets disclosed, you rep-key manually. If your IKE PSK secret gets disclosed, you re-key manually. My only real goal, here, is to be as good or better than TCP-MD5 to address earlier concerns about people not liking TCP options while also not resorting to TLS. (As a note, I'm thinking out loud with all this, not trying to suggest policy proposal) -- Brandon Martin