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 <[email protected]> wrote: > > On Thu, 5 Mar 2020 at 12:50, Paul Wouters <[email protected]> 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 _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
