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

Dharmanandana Reddy Pothula <dharmanandana.pothulam@huawei.com> Tue, 11 August 2015 14:45 UTC

Return-Path: <dharmanandana.pothulam@huawei.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 70FB71A8A97 for <ipsec@ietfa.amsl.com>; Tue, 11 Aug 2015 07:45:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 HxH5DvlAkh3O for <ipsec@ietfa.amsl.com>; Tue, 11 Aug 2015 07:45:05 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F351A901F for <ipsec@ietf.org>; Tue, 11 Aug 2015 07:45:04 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWD05773; Tue, 11 Aug 2015 14:45:02 +0000 (GMT)
Received: from SZXEML434-HUB.china.huawei.com (10.82.67.225) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 11 Aug 2015 15:45:01 +0100
Received: from SZXEML523-MBS.china.huawei.com ([169.254.6.251]) by szxeml434-hub.china.huawei.com ([10.82.67.225]) with mapi id 14.03.0235.001; Tue, 11 Aug 2015 22:44:39 +0800
From: Dharmanandana Reddy Pothula <dharmanandana.pothulam@huawei.com>
To: "svan@elvis.ru" <svan@elvis.ru>, "pwouters@redhat.com" <pwouters@redhat.com>
Thread-Topic: [IPSec] The NULL Authentication Method in IKEv2 Protocol - draft-ietf-ipsecme-ikev2-null-auth-07
Thread-Index: AQHQ1EGAjZ3Y+npme0qm+hAhnlEYhg==
Date: Tue, 11 Aug 2015 14:44:38 +0000
Message-ID: <3F00A55B1B111141BAE547DB25D09FE27DCD6FC1@szxeml523-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.212.129]
Content-Type: multipart/alternative; boundary="_000_3F00A55B1B111141BAE547DB25D09FE27DCD6FC1szxeml523mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipsec/1Y8u8E6R7ibip0Dcxpoowg2VnDw>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: [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 14:45:07 -0000

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