Hi. I’ll reply to Daniel’s and Paul’s comments. Note that this draft is a starting point to feed into discussion. Just like this kind of discussion.
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. AES-GCM: “8 octet ICV” vs “16 octet ICV” - that was a mistake. Of course I meant 16, and I will fix it in -01. As for 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) AES-CCM: Why a MUST? I don’t have any interest in implementing 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. 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? "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? Group 18 (8192 bits) - IMO this is so slow that I don’t like making it a SHOULD. "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. 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. "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? "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. Yoav
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
