Re: [TICTOC] Secdir last call review of draft-ietf-tictoc-1588v2-yang-10
Jiangyuanlong <jiangyuanlong@huawei.com> Thu, 04 October 2018 09:15 UTC
Return-Path: <jiangyuanlong@huawei.com>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17E6130E0A; Thu, 4 Oct 2018 02:15:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 oxDsSRHxUsQ0; Thu, 4 Oct 2018 02:15:09 -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 AD407130E01; Thu, 4 Oct 2018 02:15:09 -0700 (PDT)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D4EE56DE90C09; Thu, 4 Oct 2018 10:15:03 +0100 (IST)
Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 4 Oct 2018 10:15:05 +0100
Received: from DGGEML532-MBS.china.huawei.com ([169.254.7.198]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0399.000; Thu, 4 Oct 2018 17:14:56 +0800
From: Jiangyuanlong <jiangyuanlong@huawei.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Samuel Weiler <weiler@csail.mit.edu>
CC: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-tictoc-1588v2-yang.all@ietf.org" <draft-ietf-tictoc-1588v2-yang.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "tictoc@ietf.org" <tictoc@ietf.org>
Thread-Topic: Secdir last call review of draft-ietf-tictoc-1588v2-yang-10
Thread-Index: AQHUWyxprlJobJE8SkG6p5wwETcTdaUN3WSAgADqBeA=
Date: Thu, 04 Oct 2018 09:14:55 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBC21275C@dggeml532-mbs.china.huawei.com>
References: <153857993505.8974.13448340837663409232@ietfa.amsl.com> <20181004024953.GK56675@kduck.kaduk.org>
In-Reply-To: <20181004024953.GK56675@kduck.kaduk.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.124.168]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/tictoc/bQrOOu-tT29W352m6cWqB_lgruk>
Subject: Re: [TICTOC] Secdir last call review of draft-ietf-tictoc-1588v2-yang-10
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Oct 2018 09:15:12 -0000
Ben and Samuel, Yes, the draft says:" The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory- to-implement secure transport is TLS [RFC8446]." Thus authentication is a mandatory part of this layer. BTW, the security considerations in this draft are fully in accordance with "Guidelines for Authors and Reviewers of YANG Data Model Documents" https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#page-13 (which is now in RFC Editor Queue), and all future YANG docs developed in the IETF are requested to follow its guidelines). Thanks, Yuanlong > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > Sent: Thursday, October 04, 2018 10:50 AM > To: Samuel Weiler > Cc: secdir@ietf.org; draft-ietf-tictoc-1588v2-yang.all@ietf.org; ietf@ietf.org; > tictoc@ietf.org > Subject: Re: Secdir last call review of draft-ietf-tictoc-1588v2-yang-10 > > On Wed, Oct 03, 2018 at 08:18:55AM -0700, Samuel Weiler wrote: > > Reviewer: Samuel Weiler > > Review result: Has Issues > > > > I wonder whether there should be a requirement to use authentication > when > > making updates. As the doc says: > > The NETCONF and RESTCONF secure transport layers already handle the > authentication requirements. E.g., RFC 8040 Section 2.5: > > The RESTCONF server MUST authenticate client access to any protected > resource. If the RESTCONF client is not authenticated, the server > SHOULD send an HTTP response with a "401 Unauthorized" status-line, > as defined in Section 3.1 of [RFC7235]. The error-tag value > "access-denied" is used in this case. > > But thank you for doing the review, and you're right that this is > important! > > -Ben > > > Write operations (e.g., edit-config) to these data nodes without > > proper protection can have a negative effect on network operations. > > > > I'm sure someone will argue "if this is used in a closed network, we can > avoid > > the use of authentication". Prudence suggests that "closed" networks > don't > > remain that way forever, and defense-in-depth is advisable. Let's add a > MUST > > or at least a SHOULD. > > > >
- [TICTOC] Secdir last call review of draft-ietf-ti… Samuel Weiler
- Re: [TICTOC] Secdir last call review of draft-iet… Benjamin Kaduk
- Re: [TICTOC] Secdir last call review of draft-iet… Jiangyuanlong