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]
