Re: [secdir] [Netconf] review of draft-ietf-netconf-call-home-11
Kent Watsen <kwatsen@juniper.net> Mon, 12 October 2015 14:23 UTC
Return-Path: <kwatsen@juniper.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6571B3327; Mon, 12 Oct 2015 07:23:14 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 0jJOlI3IwkQO; Mon, 12 Oct 2015 07:23:10 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0775.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::775]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5321B3325; Mon, 12 Oct 2015 07:23:10 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.293.16; Mon, 12 Oct 2015 14:22:47 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Mon, 12 Oct 2015 14:22:47 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Benoit Claise <bclaise@cisco.com>, Simon Josefsson <simon@josefsson.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, NETCONF <netconf@ietf.org>, "draft-ietf-netconf-call-home.all@ietf.org" <draft-ietf-netconf-call-home.all@ietf.org>
Thread-Topic: [Netconf] review of draft-ietf-netconf-call-home-11
Thread-Index: AQHRANYkB04UoC2GL0O6JoJSU3KY855ng5wAgAAqloA=
Date: Mon, 12 Oct 2015 14:22:47 +0000
Message-ID: <D24136E6.E6AAA%kwatsen@juniper.net>
References: <8737xnp0rm.fsf@latte.josefsson.org> <561B663C.7080408@cisco.com>
In-Reply-To: <561B663C.7080408@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.10]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:mtMJbu/hjTiUoNx8Q92XiUakzMn05EW5vLtzfRCmWjo8/UXLiMNYqaZHUIXiWswR1OWoMZ+5RbY1V22a7AbOcVUquw4ZtKZYpsCJzvStuW+9B5K3OGWIDZcTAhT38dz6iwLxeDKC67K/e8Zj67zMtg==; 24:eN7ZhYoU+Tj/Lhpboey59x3sST/fvuQuUNRZyZpyFHs8bgaahZOho1/hsx3Szj8vVn0RpI+MJKYCYZBfyu2rPOIjtxdZ5+YaUZhPMDo1zSM=; 20:EZ+kCxYZi73CQNX9Y30LYbkVu9v8LgybcQpcY4aSjygIVlR4Dcwgb9gnZI5re3wjp0AiWkbJVrabi+jFBRYXxw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-microsoft-antispam-prvs: <CO1PR05MB457FB51020731113BEE22F3A5310@CO1PR05MB457.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457;
x-forefront-prvs: 0727122FC6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(52604005)(199003)(164054003)(377454003)(189002)(2501003)(102836002)(11100500001)(122556002)(15975445007)(2201001)(107886002)(36756003)(86362001)(5007970100001)(87936001)(105586002)(2950100001)(106116001)(189998001)(106356001)(10400500002)(2900100001)(99286002)(83506001)(40100003)(230783001)(66066001)(50986999)(5008740100001)(4001350100001)(19580405001)(76176999)(19580395003)(64706001)(97736004)(101416001)(5001770100001)(5001960100002)(5004730100002)(5002640100001)(46102003)(16236675004)(54356999)(19617315012)(92566002)(81156007); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D24136E6E6AAAkwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2015 14:22:47.5849 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/OqgEuq0c1QNNEj5RuI_vXoYl9xc>
X-Mailman-Approved-At: Thu, 22 Oct 2015 07:18:02 -0700
Subject: Re: [secdir] [Netconf] review of draft-ietf-netconf-call-home-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Oct 2015 14:23:14 -0000
Hi Simon, Regarding your two comments: 1. Are non-certificate-based TLS out of scope for NETCONF/RESTCONF? Yes or, more specifically, both NETCONF over TLS and and RESTCONF restrict TLS to certificates. The relevant text is in RFC 7589, Section 1 and draft-ietf-netconf-restconf-07, Section 2.2. Do you think there should be a note in this draft stating this as well? 2. Section 2 says 'The term "NETCONF/RESTCONF client" can refer to the [RFC6241], Section 1.1 "client".' Does Benoit's suggestion to replace "can refer" with "refers" satisfy the language vagueness issue? - And also, are you satisfied with having the single reference to RFC6241, since RESTCONF pulls the term from RFC6241 as well? Thanks Kent From: Benoit Claise <bclaise@cisco.com<mailto:bclaise@cisco.com>> Date: Monday, October 12, 2015 at 3:50 AM To: Simon Josefsson <simon@josefsson.org<mailto:simon@josefsson.org>>, "iesg@ietf.org<mailto:iesg@ietf.org>" <iesg@ietf.org<mailto:iesg@ietf.org>>, "secdir@ietf.org<mailto:secdir@ietf.org>" <secdir@ietf.org<mailto:secdir@ietf.org>>, "draft-ietf-netconf-call-home.all@tools.ietf.org<mailto:draft-ietf-netconf-call-home.all@tools.ietf.org>" <draft-ietf-netconf-call-home.all@tools.ietf.org<mailto:draft-ietf-netconf-call-home.all@tools.ietf.org>>, "netconf@ietf.org<mailto:netconf@ietf.org>" <netconf@ietf.org<mailto:netconf@ietf.org>> Subject: Re: [Netconf] review of draft-ietf-netconf-call-home-11 Hi Simon, Thanks for your review. One comment below. Hi. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I believe the document is ready. One main security concern is the reversal of roles that this document introduce, but letting TCP clients act as TLS/SSH servers, and vice versa, is not unheard of. As long as proper peer authentication is performed, and other parts of the security protocols are properly performed, I see no fundamental problem with this. I'm sure some implementations will need to be tweaked to deal with this, and terminology might confusing at times. The 'Security Considerations' section does a good job discussing this, and some other issues too. Two minor questions: 1) Are non-certificate-based TLS out of scope for NETCONF/RESTCONF? I see no discussion of it in this draft, and text in the document implicitly assumes host keys (SSH) or certificates (TLS) are used. Think about TLS-PSK for example, which seems like a relevant idea for embedded devices. This may not be the document to adress this, but if there is work towards that goal already, it might be useful to align this document with that. 2) Section 2 says 'The term "NETCONF/RESTCONF client" can refer to the [RFC6241], Section 1.1 "client".'. Shouldn't this say the term may refer to a RESTCONF client and reference draft-ietf-netconf-restconf? Or is that not intentional? The use of the word 'can' make this text vague to me. The previous section (1.5) says that 'NETCONF/RESTCONF' is an abbrevation for 'the NETCONF or the RESTCONF'. The same comment applies to section 3. Maybe this is a misunderstanding on my side, but the text confused me so it may be useful to resolve. I mentioned this point in my AD review (http://www.ietf.org/mail-archive/web/netconf/current/msg10535.html). I now realize that I made a typo in my email: NETCONF/RESTCONF client" can refers to the RFC 6241 section 1.1 "client" This should read: "NETCONF/RESTCONF client" refers to the RFC 6241 section 1.1 "client" Ditto for NETCONF/RESTCONF server. This takes care of the confusing "can" word. Thanks for spotting that. Regarding the draft-ietf-netconf-restconf reference now. https://tools.ietf.org/html/draft-ietf-netconf-restconf-07#section-1.4.1 refers to RFC 6241 for the client. So I believe that we're good with a single reference to RFC 6241 in this draft. Regards, Benoit Thanks, /Simon
- [secdir] review of draft-ietf-netconf-call-home-11 Simon Josefsson
- Re: [secdir] review of draft-ietf-netconf-call-ho… Benoit Claise
- Re: [secdir] [Netconf] review of draft-ietf-netco… Simon Josefsson
- Re: [secdir] [Netconf] review of draft-ietf-netco… Kent Watsen