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
