[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