[Swan-dev] simplifying default IKEv1 IKE algorithms

Andrew Cagney andrew.cagney at gmail.com
Mon Feb 6 16:41:25 UTC 2017

On 3 February 2017 at 11:27, Paul Wouters <paul at nohats.ca> wrote:
> On Fri, 3 Feb 2017, Andrew Cagney wrote:
>> 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
> Yes, but!
> I think for IKEv1 as initiator, we should prob do modp1536 and not use
> sha2, because we are dealing with lots of old devices that dont support
> or have configured modp2048 and sha2. And a lot of old ikev1 code (eg
> openswan) does not properly do INVALID_KE and re-send with the
> downgraded modp group.

All the calls I'm looking at are on the the initiator, so this should be ok.

On the downside, there are two tables but at least they are simple and
in one place.

> But as responder, there is no reason why not to accept the better
> values.

Here, things get a little weird, but mostly do what you want.  If
there is an ike= line then the code checks that list.  If there isn't

- PRF (i.e., hash) is ok provided ikev1_get_ike_prf_desc() succeeds
(i.e., FIPS didn't clobber the algorithm)
- ENCRYPT is ok provided ikev1_get_ike_encrypt_desc() succeeds (i.e.,
...); well almost, there's a strange else clause attached to a
ike_alg_enc_ok() class that I suspect can be deleted

More information about the Swan-dev mailing list