[Swan-dev] IKE algorithm list

[Paul Wouters]

On Mon, 27 Feb 2017, Andrew Cagney wrote:

>
> First I should note that I'm as guilty as any for adding to the
> problems here, more recently I've been dumping details into pluto.log
> so hopefully I'm reformed :-)

We are all guilty :)

> The output from:
>
>   $ ipsec auto --status
>
> includes:

[algo list]

> I find the DH list especially bad and the main one I'd like to fix,
> but I figure I should list all the issues I see:
>
> - 'group' and 'oakley' shouldn't appear

Agreed.

> - for DH19..DH21 should it use "dh19" rather than the poorly defined
> ECP_256 (seemingly SECP256R1 is the actual name?  I should check NIST)

Yes. And actually I think it would be good to have DHxx in general too.
Ideally, I would like dh2, dh5, etc to be aliases for modpXXXX but a
quick peek at the code seemed it was not a quick simple change to add.

> - is the ID (and duplicates) helpful to users?  Instead include that
> in pluto.log

Really, the only useful thing is for them to see which IKE and which
IPsec algorithms are supported. Probably just the name would be enough.

> - are the duplicate names (v1name/v2name/name) helpful?   Instead just
> list a single somewhat official name like AES_CBC

It might be useful to know which are available in v1 and v2 ? I would
dislike another "translation" of names, unless you have it already
somewhere in the common name.

> - should the allowed key lengths be listed explicitly (on separate
> lines, say), i.e., AES_CBC_128

I don't think that is very useful. All of the ones we support for
only (but all) key sizes 128, 192, 256. There were a few ancient ones
that had variable key sizes (CAST?) but that is supported
at 128 I believe. And there will never be more variable key length
ones I think.

> - how should IKEv1 vs IKEv2 only algorithms be identified (the GCM
> algorithms are _not_ IKEv1)

It would be nice if we should show which algos are available for IKEv1,
IKEv2 and ESP so that people can check if their version supports
CHACHA20 or AES_CMAC, etc.

> - hash is an IKEv1 term, PRF is the IKEv2 term and the more correct
> name is HMAC_MD5

administrators dont know "hmac", or "integ" or "prf". They really only
know Encryption and Authentication. I'm not sure what the best strings
would be.

> - is hashlen helpful? Modern algorithms include the 'hashlen' in the name.

No, there is no variable length hashing algorithm.

> - upper or lower case? (I suspect upper case would actually be better)

Doesn't matter much to me. I think I might have a small preference for
using the strings we would use on an ike=/phase= line. Which is why I
also prefer md5 over hmac_md5.

Paul