[Swan-dev] simplifying default IKEv1 IKE algorithms

Andrew Cagney andrew.cagney at gmail.com
Mon Feb 6 19:40:12 UTC 2017


On 6 February 2017 at 14:18, Paul Wouters <paul at nohats.ca> wrote:
> On Mon, 6 Feb 2017, Andrew Cagney wrote:
>
>>> I'm confused, this is IKEv1 specific?
>>
>>
>> Yes, IKEv1 IKE specific.
>>
>>> If there is no ike line, then MD5 gets rejected right?
>>
>>
>> By the responder, in FIPS mode, yes, it would be rejected.  The call
>> to ikev1_get_ike_prf_desc() would fail.
>>
>>> And serpent
>>> or twofish or cast?
>>
>>
>> By the responder, in FIPS mode, yes, it would be rejected.  The call
>> to ikev1_get_ike_encrypt_desc() would fail.
>
>
> Those should still not be in the _default_ set for IKEv1 when not in
> FIPS mode! Same for dh23/dh24 and modp1024!

We need to be careful here, IKEv1 as totally different paths for the
initiator and responder.

For the initiator, when there is no ike= line, how does:

    static const struct ike_alg *default_ikev1_groups[] = {
        &oakley_group_modp2048.common,
        &oakley_group_modp1536.common,
        NULL,
    };
    static const struct ike_alg *default_ikev1_ealgs[] = {
        &ike_alg_encrypt_aes_cbc.common,
        &ike_alg_encrypt_3des_cbc.common,
        NULL,
    };
    static const struct ike_alg *default_ikev1_aalgs[] = {
        &ike_alg_prf_sha1.common,
        NULL,
    };

look for the defaults?  I left MODP2048 before MODP1532, because,
based on spdb.c:

- for PSK and/or RSA, it was proposing MODP2048, MODP1536, MODP1024
- for * XAUTH, it was proposing MODP1536, MODP1024

so we've been proposing 2048 first for some time; we could change this
of course.

For the responder, when no ike=, it defaults to accepting almost
anything.  That includes MD5, serpent, and twofish (but not cast,
which is ESP only).


More information about the Swan-dev mailing list