On Fri, 9 Oct 2015, Yoav Nir wrote:
Re: ENCR_AES_CBC. If someone wanted to build an IKEv2 implementation with only one algorithm, the choice for maximum interoperability would be AES-CBC. This is the same as 3DES-CBC when RFC 4307 was published. I didn’t make it a MUST- because I don’t know what the next MUST is going to be.
Fair enough.
AES-GCM: “8 octet ICV” vs “16 octet ICV” - that was a mistake. Of course I meant 16
Good.
requirement level, as far as I know, AES-GCM got a lot of adoption for IPsec, but not so much for IKE. Why? Because it is only defined since RFC 5282, and also because it cannot be used in IKEv1, and also because its speed advantage doesn’t matter much in IKE. My implementation does not have it for IKE (just an example)
For us (libreswan) it was stalled because the codebase had a bunch of CBC assumptions in the code. It took more time to change those and so CTR and GCM stalled. I was actually surprised that when we were ready with ikev2, that ikev1 didn't even specify it. I guess I agree there is no real advantage that we know of, except the general statement about AEAD security versus ENCR+INTEG being better. If we can avoid timing based attacjs or oracles that would be a plus?
AES-CCM: Why a MUST? I don’t have any interest in implementing it.
That came in via the MUST for ESP in RFC7321. I don't particularly want it.
So with no clear direction on what the next “go to” algorithm is going to be, I don’t think it’s time yet to hint at AES-CBC’s deprecation.
Fair enough. But I think these discussions should be summarized similarly to RFC 7321 - which is why I also had written a "Rationale" section.
SHA-512: I assume you mean HMAC-SHA-512 as PRF and integrity algorithm. Do we need it? The future seems to be AEAD algorithms, so do we really need PRF_HMAC_SHA2_512 ? Perhaps something SHA-3 based is going to be the future?
For non-AEAD I'm a little nervous to only have HMAC-SHA-256. I think we might want to have HMAC-SHA-512 as a temporary stopgap in the future, although once we have SHA-3 we could again drop it for a SHA-3 version.
"Can we add a recommendation to use integ == prf for non-AEAD algorithms?” - I don’t thin we can in this document. That would be changing IKE, no?
Well, our algo/cipher changes also modifies IKE (7296) doesn't it? I don't think 7296 makes any recommendations. (also I did put in "updates 7296" in my text :) The reason I'm asking was that we ran into this because libreswan only supports specifing PRF for AEAD and otherwise picks the INTEG as PRF. This caused us to fail a TAHI test. I had to argue about that failure, and I'd rather have some RFC text to do the arguing for me.
Group 18 (8192 bits) - IMO this is so slow that I don’t like making it a SHOULD.
hmm, okay. I would like something non-ECC that's larger than 2048 though.
"Can we recommend that the initial exchanges and create child sa use the same MODP group? and that we recommend PFS for create_child_sa.” The former is a sensible recommendation, but it belongs in 7296, not here.
Same as above. I would be good to have it somewhere, because I've had this discussion a few times as well. Why not here, where we talk about IKE crypto recommendations specifically. It seems the right place to me.
As for recommending PFS, I’m not sure. This is not the same as TLS. PFS in TLS prevents exposing encryption keys with the future exposure of a long-term secret - the private key. In IKE the IPsec encryption key depends not on the long term secret, but on another ephemeral value - the SK_d. This is far less problematic, so I’m not sure such a recommendation is worth the cost.
Then we wasn't it dropped from CREATE_CHILD_SA? What we have now is that different implementations with different defaults cause interop issues on CREATE_CHILD_SA. (which is nasty when problems only show up at rekey time)
"Can we recommend that a default proposal set should have at least one MUST algorithm for each type?” I didn’t understand this. What is a default proposal set?
The defaults in the configuration. If the administrator sets no explicit proposals or proposal elements. So if the software starts negotiating the admin forcing the algorithms, there is guaranteed to be a proposal that will work because it only uses MUST's. Again, this is to enhance interoperability.
"Can we recommend not to apply these recommendations for IKEv1 because that will cause more interop problems (see my draft for text)” I think we should just ignore IKEv1 at this point. You definitely should not use AES-GCM with IKEv1.
Again, as implementor/vendor it really helps me to have RFC text somewhere that makes this clear so I don't have to argue with customers on why we don't support GCM for IKEv1. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
