Hi Dharmanandana, I don't think that the attack, described in the section 2.4 of RFC 7296 is related to NULL authentication. This attack implies that attackers send IKE_SA_INIT response containing garbage in the KE Payload and that they never compute SKEYSEED and the other keys, so that they cannot construct proper (cryptographically valid) IKE_AUTH response.
However, if attackers do go further in the protocol and calculate the keys and respond with valid IKE_AUTH response with NULL authentication, and if the NULL authentication is acceptible to the Initiator, then the Initiator does connect to the wrong host. However, it is an intrinsic property of NULL authentication - you cannot authenticate the peer. The Security Considerations Section of the draft (In particular, Section 3.1) warns that the host must not made any assumptions that it connects to the peer it was intendind to connect to. Regards, Valery Smyslov. ----- Original Message ----- From: Dharmanandana Reddy Pothula To: s...@elvis.ru ; pwout...@redhat.com Cc: ipsec@ietf.org Sent: Tuesday, August 11, 2015 5:44 PM Subject: [IPSec] The NULL Authentication Method in IKEv2 Protocol - draft-ietf-ipsecme-ikev2-null-auth-07 Hi, As per statement under section 2.4 in RFC 7296, To prevent DoS attack on the initiator, "the initiator MAY be willing to accept multiple responses to its first message, treat each response as potentially legitimate, respond to each one, and then discard all the invalid half-open connections when it receives a valid cryptographically protected response to any one of its requests. Once a cryptographically valid response is received, all subsequent responses should be ignored whether or not they are cryptographically valid." if we apply above scenario when initiator expects authentication null from responder, there is possibility that initiator will receive more than one cryptographically valid response, as per above statement, the first one should be considered and subsequent responses should be ignored, but if first one is attacker and subsequent one is genuine peer, the connection establishes with the attacker. We feel this is security risk. can you please provide more insight on this? Regards, Dharmanandana Reddy.P Perumal. V
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
