[Swan-dev] simplifying default IKEv1 IKE algorithms

[Andrew Cagney]

To make my question more concrete, here's the table used to generate
proposals when ike=... appears in an IKEv1 config file:

static const struct ike_alg *default_ikev1_groups[] = {
        &oakley_group_modp2048.common,
        &oakley_group_modp1536.common,
        NULL,
};
static const struct ike_alg *default_ike_ealgs[] = { // technically never used
        &ike_alg_encrypt_aes_cbc.common, // 256-bit then 128-bit
        &ike_alg_encrypt_3des_cbc.common,
        NULL,
};
static const struct ike_alg *default_ike_aalgs[] = {
        &ike_alg_prf_sha2_256.common,
        &ike_alg_prf_sha2_512.common,
        &ike_alg_prf_sha1.common,
        &ike_alg_prf_md5.common,
        NULL,
};

(16 combinations)

and here's an equivalent table for when the ike=... line is omitted
from the config file (i.e., the out-of-the-box IKEv1 defaults):

        static const struct ike_alg *default_ikev1_groups[] = {
                &oakley_group_modp2048.common,
                &oakley_group_modp1536.common,
                &oakley_group_modp1024.common,
                NULL,
        };
        static const struct ike_alg *default_ikev1_ealgs[] = {
                &ike_alg_encrypt_aes_cbc.common, // 256-bit then 128-bit
                &ike_alg_encrypt_3des_cbc.common,
                NULL,
        };
        static const struct ike_alg *default_ikev1_aalgs[] = {
                &ike_alg_prf_sha1.common,
                &ike_alg_prf_md5.common,
                NULL,
        };

(12 combinations)

Should the second table be dropped and just the first used, that is:

   - the only way to get modp1024 is to specify it explicitly
   - sha2 appears in all defaults and is preferred to sha1 and md5

(of course FIPS prunes this list further)


On 19 January 2017 at 14:33, Andrew Cagney <andrew.cagney at gmail.com> wrote:
> (not IKEv2, not ESP)
>
> Currently, for IKEv1 IKE (phase1 I guess) has two different "defaults"
>
> - the ike= line is missing from the config
>
>   hard wired magic in spdb.c constructs an exhaustive proposal list
> and dumps it onto the wire
>   the proposals are not sanity checked, and stuff that isn't supported
> keeps being sent out
>
>   The combinations are something like
>      {aes256,aes128,des3}-{sha1,md5}-{modp2048,modp1536,modp1024} = 3*2*3 = 18
>   but the exact details depend on the authentication being used
>
> - the ike= line is present but some algorithms are missing; for
> instance ike=aes is missing prf/integ and dh
>
>   completely unrelated logic in plutoalg.c, fills in missing
> algorithms by enumerating over completely unrelated default values
>   for DH, there is a sanity check to filter out invalid defaults (I
> need to apply that to the other cases)
>
>   The current default is:
> *-{sha256,sha512,sha1,md5}-{modp2048,modp1536} (since an encryption
> algorithm is required for this case)
>
> Rather than trying to modify the first code path so that it filters
> out invalid defaults, I'd like to drop that code path entirely.
> Instead use the second code path to fill in the defaults when IKEv1
> and no ike= was specified
>
> Thoughts,
> Andrew
>
> Not IKEv2 IKE?  it currently produces a very compact and very
> different proposal list, but that isn't to rule it out.
> Not ESP? That code path is very different.