[Swan-dev] can an IKEv1 aggressive initial request contain a cert?

Andrew Cagney andrew.cagney at gmail.com
Thu Mar 5 18:57:36 UTC 2020


On Thu, 5 Mar 2020 at 12:50, Paul Wouters <paul at nohats.ca> wrote:
>
> On Thu, 5 Mar 2020, Andrew Cagney wrote:
>
> > Reading the RFC, I can see CERT in:
> >
> > - the aggressive initial response
> > - the second aggressive request
> >
> > but not for the initial request (but pluto still tries to unpack it).
> > However, the state machine comments:
> >
> >    /* STATE_AGGR_R0:
> >     * SMF_PSK_AUTH: HDR, SA, KE, Ni, IDii
> >     *           --> HDR, SA, KE, Nr, IDir, HASH_R
> >     * SMF_DS_AUTH:  HDR, SA, KE, Nr, IDii
> >     *           --> HDR, SA, KE, Nr, IDir, [CERT,] SIG_R
> >     */
> >
> > seem to imply that it is (the code seems to deliberately allow CERT anywhere).
>
> Note that IKEv1 (RFC 2409) does not have CERTREQ, but uses CERT for what
> in IKEv2 is called CERT and CERTREQ payloads. I find one mention of
> "certificate request" but no where does it explain where or in which
> payload to send it.
>
> In the above diagram though, that seems to be the real CERT (not
> certificate request) payload.

Right.  I don't see anything in the RFC matching the comment so my
guess is someone "summarised".

> But regardless, maybe best to leave this ancient code as-is ? :)

Except when it interacts with other changes and leaks certs :-(

Both ikev1_decode_peer_id() and oakley_id_and_auth() keep trying to
decode certs.  Presumably because they don't know if the packet they
are processing should have any.

I've added a hack however it seems overly complicated.

>
> Paul


More information about the Swan-dev mailing list