So if A just passthrough Y's certificate payload to X in the IKE_AUTH response A sent to X, how could A signs the AUTH payload without having Y's private key that corresponds to Y's certificate?
From: Valery Smyslov <smyslov.i...@gmail.com> Sent: Wednesday, July 30, 2025 12:28 AM To: Jun Hu (Nokia) <jun...@nokia.com>; 'Christopher Patton' <cpat...@cloudflare.com>; 'Scott Fluhrer (sfluhrer)' <sfluh...@cisco.com> Cc: 'ipsec' <ipsec@ietf.org> Subject: RE: [IPsec] Re: draft-smyslov-ipsecme-ikev2-downgrade-prevention CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Jun, the attacker cannot (and does not) change authentication information sent by R. Thus, the initiator X would think that it established an SA with Y (and that would match its policy), but the responder Y would think that it established SA with A (assuming the Y's policy allows both X and A to connect to it). Regards, Valery. First, there is a stronger variant not described in -00 that doesn't require compromising either of the victim peers. This attack is described in the original thread [1] and we have also added a description of the draft [2]. To mount the attack, rather than compromise the victim initiator, the attacker can be any initiator that the victim responder is configured to speak to. The key observation is that the downgrade happens before the initiator identifies itself to the peer. This means the attacker can simply authenticate itself with its own signing key. We refer to this as an "identity misbinding" attack in the draft. [HJ] so there are 3 parties: X (initiator), Y (responder) and A (attacker), R is configured to speak both X and A, but I would expect X is configured to speak only to Y, for example X typically would check received certificate's SAN or subject to see if it matches the Y's FQDN, so if A can't forge Y's certificate, wouldn't X just fail the setup after checking received certificate?
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
