RFC 4307 just barely mentions key lengths, by implying that ENCR_AES_CBC
really means AES-128-CBC. I think the new document should be clear about
recommended key lengths for the relevant algorithms. This may be opening
a can of worms, but you don't have interoperability without it.
Thanks,
Yaron
On 10/09/2015 06:04 PM, Yoav Nir wrote:
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
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
