Re: [secdir] Secdir Review of draft-ietf-netconf-rfc5539bis-09

t.p. <daedulus@btconnect.com> Tue, 10 March 2015 12:32 UTC

Return-Path: <daedulus@btconnect.com>
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 325DE1ACD54; Tue, 10 Mar 2015 05:32:56 -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, SPF_HELO_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 yPQQojV_aimY; Tue, 10 Mar 2015 05:32:53 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0760.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::760]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021BA1ACDB2; Tue, 10 Mar 2015 05:32:52 -0700 (PDT)
Received: from AM3PR07MB242.eurprd07.prod.outlook.com (10.242.18.141) by AM3PR07MB0711.eurprd07.prod.outlook.com (25.160.6.15) with Microsoft SMTP Server (TLS) id 15.1.106.15; Tue, 10 Mar 2015 12:15:17 +0000
Received: from pc6 (86.185.85.149) by AM3PR07MB242.eurprd07.prod.outlook.com (10.242.18.141) with Microsoft SMTP Server (TLS) id 15.1.106.15; Tue, 10 Mar 2015 12:15:16 +0000
Message-ID: <000b01d05b2b$8d3ab2a0$4001a8c0@gateway.2wire.net>
From: t.p. <daedulus@btconnect.com>
To: Sam Hartman <hartmans-ietf@mit.edu>, <ietf@ietf.org>, <secdir@ietf.org>, <iesg@ietf.org>
References: <tslioeagymn.fsf@mit.edu>
Date: Tue, 10 Mar 2015 12:12:14 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.185.85.149]
X-ClientProxiedBy: DB4PR02CA0028.eurprd02.prod.outlook.com (10.242.174.156) To AM3PR07MB242.eurprd07.prod.outlook.com (10.242.18.141)
Authentication-Results: mit.edu; dkim=none (message not signed) header.d=none;
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB242; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB0711;
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(51704005)(129404003)(33646002)(50226001)(61296003)(116806002)(1556002)(86362001)(50466002)(230783001)(19580405001)(23756003)(19580395003)(44716002)(87976001)(2201001)(77096005)(77156002)(62966003)(47776003)(42186005)(40100003)(46102003)(76176999)(92566002)(62236002)(122386002)(81686999)(81816999)(66066001)(44736004)(50986999)(1456003)(2171001)(84392001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB242; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en;
X-Microsoft-Antispam-PRVS: <AM3PR07MB242C5E08B31C8A7A596DCA5C6180@AM3PR07MB242.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:AM3PR07MB242; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB242;
X-Forefront-PRVS: 051158ECBB
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2015 12:15:16.6850 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB242
X-OriginatorOrg: btconnect.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/pUZ2P0GCyFz-UedMLsLp6f-jM-g>
X-Mailman-Approved-At: Tue, 10 Mar 2015 05:34:29 -0700
Cc: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org
Subject: Re: [secdir] Secdir Review of draft-ietf-netconf-rfc5539bis-09
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: <http://www.ietf.org/mail-archive/web/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: Tue, 10 Mar 2015 12:32:56 -0000

----- Original Message -----
From: "Sam Hartman" <hartmans-ietf@mit.edu>
To: <ietf@ietf.org>rg>; <secdir@ietf.org>rg>; <iesg@ietf.org>
Cc: <draft-ietf-netconf-rfc5539bis.all@tools.ietf.org>
Sent: Monday, March 09, 2015 12:10 PM
Subject: Secdir Review of draft-ietf-netconf-rfc5539bis-09


>
> This is an update to netconf over TLS with mutual X.509
authentication.
>
> In general, this looks fairly good.
>
> I'd ask the security ADs to take a look at two things:
>
> * The text on certificate validation in section 5.
> Certificate validation has a number of options, none of which are
> described or specified in this text.
> Is that good enough for this application?  (Probably)
>
> In section 7, there is a description of how the netconf server finds
the
> username of the client.
> It talks about a certificate fingerprint without a reference to a
> specific algorithm.
> I'm aware of multiple algorithms for fingerprints.
> This text is probably too vague for interoperability.

Sam

I see what you mean but had a different model in mind.  The fingerprint
is not transmitted as part of the tls/netconf protocol, I assume that it
is only generated within a server when a certificate arrives over the
tls/netconf protocol and is then compared with a prestored list of
fingerprints within the server.

So as long as the same algorithm is used within the server, then it does
not matter what is used.  If, instead, the prestored list of
fingerprints is generated outside the server and installed as a file,
then yes, the algorithm used to create the prestored list must be the
same as that used within the server when a certificate arrives over the
tls/netconf protocol.  That is the only issue I can see.

However, this I-D used to contain a data model to go with it but that
has been put into a different I-D namely netconf-server.  That data
model imports a YANG data type tls-fingerprint which is defined as a one
octet hashing algorithm identifier followed by the fingerprint value.
The  octet value is taken from the IANA TLS Hash Algorithm Registry (RFC
5246).

So if the YANG data model is used, then the algorithm is part of the
model and the server can look up what has been used in its prestored
list of fingerprints.  If users do not use the YANG data model, well
that is up to them

Hope this helps

Tom Petch
>