works for me ... my only suggestion, going back to my original post is to either drop or tone down:
As the authentication methods are not negotiated in IKEv2, the peer is only allowed to use this authentication method if the Notify payload of type SIGNATURE_HASH_ALGORITHMS has been sent and received by each peer. Requiring both ends to send SIGNATURE_HASH_ALGORITHMS is, from my pov, a negotiation - not sending SIGNATURE_HASH_ALGORITHMS is effectively a veto. I also suspect there's code in the field ignoring this - receiving SIGNATURE_HASH_ALGORITHMS is sufficient grounds for sending a new "Digital Signature". On Wed, 26 Aug 2026 at 16:29, Tero Kivinen <[email protected]> wrote: > > Andrew Cagney writes: > > I'm not seeing the difference. > > > > An end sends a SIGNATURE_HASH_ALGORITHMS notification announcing that > > it accepts new "Digital Signatures" (and here's a list of hashes the > > end is willing to accept). > > > > vs > > > > An end sends a SIGNATURE_HASH_ALGORITHMS notification announcing that > > it supports new "Digital Signatures" (and here's a list of hashes the > > end supports). > > > > The outcome is the same: > > Outcome might be same, but the generation of the list is not same. The > list of hashes it supports is same regardless of the peer it is > talking to. This means this is just static list that always same. > > The list of hashes it is willing to accept, could be change depending > on the policy it has for the remote peers, but as this notify is so > early in the exchange, that the implementation might not even know who > the peer is, it can't really generate such filtered list. > > > The peer then knows, during IKE_AUTH, it can prove its identity using > > the new "Digital Signature" and one of the hashes; provided it has the > > code and the configuration in play allows it. > > Yes, but when you generate list based on the supports there is no part > of "configuration in play allows it". Implementation has to allow any > hash it "supports" for all peers it is talking to. > > It would be very bad idea to configure peers to only support a subset > of supported algorithms, as that would make updating the configuration > harder. If you always list all algorithms you support the other end > can update the hash algorithm himself by just startting to use it. If > you only list "allowed" algorithms then both ends need configuration > change to start using new algorithm. > > > What I don't see is the need for both ends to send > > SIGNATURE_HASH_ALGORITHMS i.e., the negotiation. > > Both ends need to know which algorithms are supported by other end > when they are generating the IKE_AUTH to be able to pick suitable > algorithms. And it is not negotiation, it is announcement. Both ends > announce algorithms they support, and other end MUST pick one > algorithm that other end supports. > > > (An implementation with connection picking might unconditionally send > > a hardwired list of hashes in SIGNATURE_HASH_ALGORITHMS; or attempt > > something more complex. But that's implementation choice.) > > Implementation should ALWAYS send hardwire list of hashes in the > SIGNATURE_HASH_ALGORITHMS. It should not attempt to do anything more > complex. > -- > [email protected] _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
