Re: [v6ops] [EXTERNAL] Re: Improving ND security

Vasilenko Eduard <vasilenko.eduard@huawei.com> Mon, 03 August 2020 18:02 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E829B3A104E; Mon, 3 Aug 2020 11:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, 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 KSBLiafBASyu; Mon, 3 Aug 2020 11:02:11 -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 6AA803A1036; Mon, 3 Aug 2020 11:02:11 -0700 (PDT)
Received: from lhreml719-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 522212D315CB6A5BF080; Mon, 3 Aug 2020 19:02:08 +0100 (IST)
Received: from msceml705-chm.china.huawei.com (10.219.141.144) by lhreml719-chm.china.huawei.com (10.201.108.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 3 Aug 2020 19:02:08 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml705-chm.china.huawei.com (10.219.141.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 3 Aug 2020 21:02:07 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 3 Aug 2020 21:02:07 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, Christian Huitema <huitema@huitema.net>, Fernando Gont <fernando@gont.com.ar>
CC: 6man <ipv6@ietf.org>, v6ops list <v6ops@ietf.org>
Thread-Topic: [v6ops] [EXTERNAL] Re: Improving ND security
Thread-Index: AQHWZ2MUnNPDF6+dz0W13zbI2SbhcKkiBzuAgAAHOoCABIr6k///1REAgAAFLgCAADvHMA==
Date: Mon, 3 Aug 2020 18:02:07 +0000
Message-ID: <7a5dddaa44d349d4bba86af063b980a5@huawei.com>
References: <3978163f-8815-1bd4-0fda-d84df9cbe684@gont.com.ar> <AA568F39-3733-4F73-872E-2E84EDA2F077@huitema.net> <2bef98c10f194c8f8c1a8a8601082966@boeing.com>
In-Reply-To: <2bef98c10f194c8f8c1a8a8601082966@boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.204.125]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/zPcsh7JfGY881bAQvwJ5rw-CwkY>
Subject: Re: [v6ops] [EXTERNAL] Re: Improving ND security
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2020 18:02:13 -0000

Hi Fred,
SEND assumes RSA "RSASSA-PKCS1-v1_5  algorithm and SHA-1 hash" that is good enough for majority of purposes.
Currently Elliptic-curve cryptography is more popular, but it is not mandatory - RSA is good enough.

Teredo specification assumes that "authentication algorithm, shared with the server", "agreed-upon authentication algorithm".
Hence, it is not possible to tell exactly how secure it is.
But because by default "To maximize interoperability, this specification defines a default algorithm in which the authentication value is computed according the HMAC specification [RFC2104] and the SHA1 function [FIPS-180]."
We could say that it is much weaker then SEND, because HMAC in principle is much weaker then open key cryptography (RSA).

And we are comparing orange to apple here, because
- SEND is used for neighbor authentication
- Teredo is the tunnel
They have different purpose in networking.

Eduard
-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin (US), Fred L
Sent: 3 августа 2020 г. 20:20
To: Christian Huitema <huitema@huitema.net>et>; Fernando Gont <fernando@gont.com.ar>
Cc: 6man <ipv6@ietf.org>rg>; v6ops list <v6ops@ietf.org>
Subject: Re: [v6ops] [EXTERNAL] Re: Improving ND security

Christian,

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@huitema.net]
> Sent: Monday, August 03, 2020 10:02 AM
> To: Fernando Gont <fernando@gont.com.ar>
> Cc: Templin (US), Fred L <Fred.L.Templin@boeing.com>om>; Pascal Thubert 
> (pthubert) <pthubert@cisco.com>om>; v6ops list <v6ops@ietf.org>rg>; 6man 
> <ipv6@ietf.org>
> Subject: Re: [v6ops] [EXTERNAL] Re: Improving ND security
> 
> This message was sent from outside of Boeing. Please do not click 
> links or open attachments unless you recognize the sender and know that the content is safe.
> 
> > On Aug 3, 2020, at 9:35 AM, Fernando Gont <fernando@gont.com.ar> wrote:
> >
> > On 3/8/20 11:22, Templin (US), Fred L wrote:
> >> ...
> >
> >
> >
> >> But then, RFC4380 offers a “poor-man’s” alternative to SEND/CGA. It 
> >> places a message authentication code in the encapsulation
> headers of IPv6 ND messages so that the messages can pass a rudimentary authentication check.
> >
> > You mean the Teredo spec? If so, I don't think it includes any sort of poor-man's SEND-CGA.
> 
> Configuration mistakes were a big concern during the design of Teredo, 
> and that's a reason why Teredo embeds continuity tests. But these tests will not resist an on-path attacker, let alone an on-link attacker.



What has been the experience with RFC4380 security in-the-wild? Is it considered "secure enough" out of the box? Or, if you had to do it again would you incorporate something "more secure" like SEND/CGA?

Thanks - Fred


> -- Christian Huitema

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops