[Swan-dev] IKEv2 default policy

[Paul Wouters]

On Wed, 21 Jan 2015, Andrew Cagney wrote:

> I'm just brute-forcing a split of IKEv1 and IKEv2 policies (what
> algorithms get offered / accepted by default) so that I can add:
>
> AES_GCM_16_256 + SHA2_256
> AES_GCM_16_128 + SHA2_256
> AES_GCM_16_256 + SHA1
> AES_GCM_16_128 + SHA1
>
> to the IKEv2 side.  Others?

Let's be a little more specific here. In IKEv1, a proposal is a complete
set, take all or nothing. So for example this  ike= line:

 	ike=aes-md5,3des-sha1

means you can do either aes-md5 or 3des-sha1, but not aes-sha1 or 3des-md5

In IKEv2, you send the transforms not as sets but as elements. If you
don't want some elements to be combinable, you send them in seperate
proposals. That is mostly relevent for GCM and non-GCM, because you
cannot combine those in one proposal because it either requires integ
or forbids integ.

So I think that for ikev2, we want our default proposalS to be:
(formatted as:
ENCR1, ENCR2, ... [keysize]
INTEG
PRF
MODP

proposal #0:
AES_GCM[256]
NULL
SHA1,SHA2_256
MODP2048, MODP4096, MODP8192

proposal #1:
AES_GCM[128]
NULL
SHA1,SHA2_256
MODP2048, MODP4096, MODP8192

proposal #2:
AES_CBC[128]
SHA1, SHA2_256, AES_XCBC
MODP1536, MODP2048

proposal #3:
AES_CBC[256]
SHA1, SHA2_256, AES_XCBC
MODP1536, MODP2048

The reason for #0 and #1 is that as far as I understand, it is
technically illegal to have two KEY_LENGTH attributes (even though I
believe strongswan uses that)

The reason for #2 is to allow people to just go to ikev2=yes to
accept only the strongest of the IKEv1 default proposals (and 128
was the default key size and only mandatory to implement one). Then
in about a year (or two?) we would drop #2 and hope people go to
higher modp groups and aes_gcm. #3 because we should promote higher
key sizes, though also perhaps in a year or two remote SHA1 and
MODP1536 from that set.

>  CAMELLIA_CBC+...?

I would not add camellia in the default proposal list because it has
not seen as much public research as aes. For the same reason, serpent
and twofish are not included even though they are probably as good or
better as aes. Cast is not included because it's really old - and it
wasn't even supported in linux until very recently - no one is using it.

> AES_CBC+SHA2?

Yes, see my proposal #2 and #3.

> Looking through the existing proposals, some seem flimsy.  For instance, should:
>
> static struct db_trans oakley_trans_pskrsasig_xauthc[] = {
>        { AD_TR(KEY_IKE, otrsasig1536des3md5_xauthc) },
>        { AD_TR(KEY_IKE, otpsk1536des3md5_xauthc) },
>
> which seems weaker than my tea, be removed from IKEv2.

There should be no md5 or 3des in any IKEv2 proposal. And no modp1536
in our "favourite" proposals, only the "fallback" ones. And no modp1024
at all in IKEv2.

That's my thought anyway. I'm happy to be convinced of other proposals.

Paul