[tsvwg] RFC 6083: Query regarding NULL AUTH Key in DTLS over SCTP

Sidhartha pant <sidhartha.pant@huawei.com> Sat, 30 May 2020 09:58 UTC

Return-Path: <sidhartha.pant@huawei.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63813A083D for <tsvwg@ietfa.amsl.com>; Sat, 30 May 2020 02:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 L2KF6lD-Ar5f for <tsvwg@ietfa.amsl.com>; Sat, 30 May 2020 02:58:06 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830A23A083C for <tsvwg@ietf.org>; Sat, 30 May 2020 02:58:06 -0700 (PDT)
Received: from lhreml709-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E1B2A5F57C80ED786570; Sat, 30 May 2020 10:57:59 +0100 (IST)
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Sat, 30 May 2020 10:57:59 +0100
Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Sat, 30 May 2020 10:57:59 +0100
Received: from BLREML503-MBS.china.huawei.com ([169.254.12.46]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0487.000; Sat, 30 May 2020 15:27:46 +0530
From: Sidhartha pant <sidhartha.pant@huawei.com>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>, "Michael.Tuexen@lurchi.franken.de" <Michael.Tuexen@lurchi.franken.de>
CC: Ashutosh prakash <ashutosh.prakash@huawei.com>, Jyoti Ranjan Senapati <jyotiranjans@huawei.com>, Shweta r <shweta.k.r@huawei.com>
Thread-Topic: RFC 6083: Query regarding NULL AUTH Key in DTLS over SCTP
Thread-Index: AdY2ZfN+7pwAjJQbSayamwauTjOeWQ==
Date: Sat, 30 May 2020 09:57:45 +0000
Message-ID: <67CF347253A4874C8F2A2A8CD1D9460B72DE94F7@BLREML503-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.150.217]
Content-Type: multipart/alternative; boundary="_000_67CF347253A4874C8F2A2A8CD1D9460B72DE94F7BLREML503MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/MGgJXLm4Na1iXUuYP8xn-R-cNsU>
Subject: [tsvwg] RFC 6083: Query regarding NULL AUTH Key in DTLS over SCTP
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 May 2020 09:58:09 -0000

Hi Michael,

I have query regarding RFC 6083 section 4.8, as per this section:-

"The endpoint-pair shared secret for Shared Key Identifier 0 is empty
   and MUST be used when establishing a DTLS connection"

Also according to the RFC 4895 section 9. An endpoint is safe from an attack from the "Man in the Middle" (MTM) if the endpoint pair shared Key is used.


"If an endpoint pair shared key is used, even a true man in the middle

   cannot inject chunks, which are required to be authenticated, even if

   he intercepts the initial message exchange.  The endpoint also knows

   that it is accepting authenticated chunks from a peer who knows the

   endpoint pair shared key."



Now if we assume a Man in the middle exist who can sniff the packets and spoof the Peer IP address.

My question is for the initial SCTP handshake when NULL Key (Shared key id 0) is used how can SCTP protect from an Man In the middle which can inject packets required to be authenticated , for example ABORT. In such case this MTM can Abort the establishment of association even before the Master Secret and an endpoint pair shared key is derived from DTLS handshake.



Is there something I am missing here or SCTP is vulnerable during this initial phase of DTLS over SCTP link setup.

Best Regards,

Sidhartha Pant



Huawei Technologies India Pvt. Ltd.

Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield

Bengaluru-560066, Karnataka

Tel: + 91-80-49160700 Ext 71594 II Mob: +919886174874 Email:

spant@huawei.com<mailto:spant@huawei.com>