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

Andrew Cagney andrew.cagney at gmail.com
Fri Mar 6 15:21:37 UTC 2020


The certs could be in either of the two aggressive initiator messages.
However, the code is throwing away away the verified cert list every
time it tries to parse a CERT payload (present or not).  As an aside,
this explains the log message:

-002 "westnet-eastnet-x509" #1: No Certificate Authority in NSS
Certificate DB! Certificate payloads discarded.
 002 "westnet-eastnet-x509" #1: No Certificate Authority in NSS
Certificate DB! Certificate payloads discarded.

this leads to the following combinations of a CERT payload in either
the first or second aggressive request:

no no - not a problem
no yes - verified cert chain set to CERTs from second message
yes no - certs from first message thrown away - verified cert chain is
NULL, OOPS
yes yes - certs from first message thrown away, verified cert chain
set to CERTs from second message
(technical nit, the "thrown away" certs still lurk in the state's cert
db, which is why they didn't leak)

so:

- decoding certs from the initial aggressive request is ... pointless
- in theory, certs could be decoded into the MD, so that they don't
lurk after the IKE SAs authenticated

Andrew

On Thu, 5 Mar 2020 at 13:57, Andrew Cagney <andrew.cagney at gmail.com> wrote:
>
> 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