[Swan-dev] IKEv2: notes on parsing ike=aes_ctr-aes-3des-sha1-sha2-dh21-dh24, ...

[Andrew Cagney]

To clarify one thing, there are three separators involved:

  '-' separates algorithms within a proposal
  ';' within a proposal, separates DH from the rest (kind of legacy)
  ',' separates proposals

On Sun, 19 Aug 2018 at 14:57, Paul Wouters <paul at nohats.ca> wrote:
>
> On Sun, 19 Aug 2018, Andrew Cagney wrote:
>
> >     ike=aes_ctr-aes-3des-sha1-sha2-dh21-dh24, ...
>
> not sure I like this, because it doesn't handle mixed use of
> AEAD/non-AEAD? Although we hope that non-AEAD is going extinct soon.

The RFC says you can't mix AEAD and non-AEAD crypto.  So two proposals
would be needed; separated by a comma (like we do now):

  ike=aes_ctr-aes-3des-sha1-sha2-dh21-dh24,aes_gcm,chacha20_poly1305-sha1-dh21

so the two proposals contain:

  encrypt=aes_ctr,aes_cbc,3des_cbc
  integ=hmac_sha1_96,hmac_sha2_256_126
  prf=hmac_sha1,hmac_sha2_256
  dh=dh24

  encrypt=aes_gcm,chacha20poly1305
  [integ=none]
  prf=hmac_sha1,hmac_sha2_256
  dh=dh24

> > Currently it isn't possible to descripe a single proposal with
> > multiple algorithms.  This both limits what we can send across the
> > wire (and annoying to me, means we can't feed the default proposals
> > into the parser).  One possible syntax is:
> >
> >    ike=aes_ctr-aes-3des-sha1-sha2-dh21-dh24,...
>
> or:
>
>         ike-encr=aes,aes_gcm
>         ike-integ=sha2,sha1
>         ike-dh=dh22,dh23
>         esp-encr=aes_gcm,aes
>         esp-integ=sha2
>
> The issue is again AEAD/non-AEAD, where we turn integ into prf

Part of the magic INTEG rule is to not convert the PRF into INTEG when AEAD.

> also, we should be able to ignore dhXX when pfs=no. We already had our
> first issue where someone adding pfs=no got their ike= line rejected.
> I think I would prefer a silent ignore. I would really like to see the
> future to mandate PFS. Since you cannot really know if your IPsec SA
> will be established from the Initial Exchanges or the Create_Child_sa,
> there is no sane configuration where this would/should have different
> values.

Do you mean IKE or ESP?  PFS=NO does cause an ESP line containing
explicit DH to be rejected:

algparse -ikev2 'esp=aes_gcm;modp2048'
    ERROR: ESP DH algorithm MODP2048 is invalid as PFS policy is disabled

it was somewhat silent and contradictory (between IKEv1 and IKEv2) but
we deliberately stopped that.

I agree that having DH23  esp=aes-sha1-dh23 ignored during AUTH and
then used later is confusing.

> Another way would be to allow people to specify actual proposals on the
> wire:
>
>         ike=aes_gcm-sha2,chacha20poly1305,dh21;aes256,3des,sha2,sha1,dh21

I'm not sure what this is trying to describe.  For instance,
everything in a single proposal, or lots of proposals with defaults
filled in.

> Which would get simpler when non-AEAD usage dies of.


> > The got-ya is with 'none'.  For instance, in both:
> >
> >     esp=aes-none
> >     ike=aes_gcm-none
> >
> > while 'none' could mean either DH or INTEG (yes, the latest RFC added
> > 'none' for DH), the above strategy interprets it as integrity.  The
> > likely workaround is to specify:
> >
> >    ike=aes_gcm;none
> >
> > to force none as DH.
>
> everything "none" should be autodetected by us and never need
> specification by the enduser. It is simply too confusing to tell
> them use "none" for integrity.

Except when we need to describe an ESP/AH proposal suite containing:

1. AES_GCM-DH23
2. AES_GCM-DH=NONE

which would be:

    AES_GCM-DH23,AES_GCM;NONE