[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