On Tue, 25 Aug 2026 at 22:20, Paul Wouters <[email protected]> wrote: > > On Tue, 25 Aug 2026, Andrew Cagney wrote: > > > 3. Authentication Payload > > > > This document specifies a new "Digital Signature" authentication > > method. This method can be used with any type of signature. 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. > > > > i.e., digital signature can only be used when both ends have sent a > > signature_hash_algorithm notification. > > > > However, consider asymmetric authentication. > > You have to read it as a SUPPPORTED style notify. Not as in a "allowed > for this connection" notify.
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: 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. For instance, if the peer receives SIGNATURE_HASH_ALGORITHMS containing SHA* but not IDENTITY, then it knows it is SOL when it comes to EdDSA but ok for RSA and ECDSA using the new "Digital Signature" method. Or, if the peer doesn't receive SIGNATURE_HASH_ALGORITHMS then it knows it can't use any new "Digital Signature"; but old style RSA, ECDSA, PSK, ... are all fine. What I don't see is the need for both ends to send SIGNATURE_HASH_ALGORITHMS i.e., the negotiation. > The supported hash algorithms that can be used for the signature > algorithms are indicated with a Notify payload of type > SIGNATURE_HASH_ALGORITHMS sent inside the IKE_SA_INIT exchange. > > > Since PSK would like its peer, DIGSIG, to use the digital signature in > > the AUTH payload it sends a list of allowed hash algorithms. > > Not "allowed" but "supported". > > > However, I wonder if instead, DIGSIG should be allowed to skip sending > > a SIGNATURE_HASH_ALGORITHM notification to PSK. > > You can't because in IKE_SA_INIT you don't know yet which configuration > might be picked and you might have PSK and DigSig peers defined. Only when an implementation / enabled configurations support connection picking. (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.) _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
