Re: [IPsec] [IPSec] The NULL Authentication Method in IKEv2 Protocol - draft-ietf-ipsecme-ikev2-null-auth-07

"Valery Smyslov" <svanru@gmail.com> Tue, 11 August 2015 15:31 UTC

Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750A01A0063 for <ipsec@ietfa.amsl.com>; Tue, 11 Aug 2015 08:31:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.67
X-Spam-Level:
X-Spam-Status: No, score=0.67 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqREXBU6eInJ for <ipsec@ietfa.amsl.com>; Tue, 11 Aug 2015 08:31:00 -0700 (PDT)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A880E1A0115 for <ipsec@ietf.org>; Tue, 11 Aug 2015 08:30:59 -0700 (PDT)
Received: by lagz9 with SMTP id z9so73115160lag.3 for <ipsec@ietf.org>; Tue, 11 Aug 2015 08:30:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type; bh=i5FotddBrCx8/Fzj8wm2pInoyCLigQZfqMJ83muYdlA=; b=TX4O9yuqGULrwE4/bFxRALXdyqi1DhA011N/p/llTMllyV2t6u/cFngwAGlt0kqLXN tufgyPVcA96Q1jQEKaJW1CZJLWGtgt+LARJZ9n9nfHd4CMVZZtVJRYerlDoBVTM9pCym 2r+/iZlLKrtPOG58G1by7ds/yB0fNUIvlKbqh2eNP6wWTHmyuOWvJgBa6llfF0N+U35B Ewwn1q+OlJlvatqLQRyK9z4Kl3lEEHrh5lJxW9t0L908D+5kYDTMKPge0fqteFufn2Ta LgDxr7JsBn5h/OuRC9D5RYlycQpH5P21sHF6XPELSb4wVKH4FSkK460JxmBH1j60MndC Sh9Q==
X-Received: by 10.152.23.4 with SMTP id i4mr27092243laf.51.1439307058155; Tue, 11 Aug 2015 08:30:58 -0700 (PDT)
Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id kx11sm534080lac.41.2015.08.11.08.30.56 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 11 Aug 2015 08:30:56 -0700 (PDT)
Message-ID: <A9C06DC5B0D8480ABE7094D35AE0378F@buildpc>
From: Valery Smyslov <svanru@gmail.com>
To: Dharmanandana Reddy Pothula <dharmanandana.pothulam@huawei.com>, pwouters@redhat.com
References: <3F00A55B1B111141BAE547DB25D09FE27DCD6FC1@szxeml523-mbs.china.huawei.com>
Date: Tue, 11 Aug 2015 18:30:58 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_1DCE_01D0D463.DDF0A1D0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipsec/D9RVlz3DiWvN7-pnyq9FMwCdwu0>
Cc: ipsec@ietf.org
Subject: Re: [IPsec] [IPSec] The NULL Authentication Method in IKEv2 Protocol - draft-ietf-ipsecme-ikev2-null-auth-07
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2015 15:31:01 -0000

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: svan@elvis.ru ; pwouters@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