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

"Ersue, Mehmet (Nokia - DE/Munich)" <> Wed, 11 March 2015 11:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 28D751A6F27; Wed, 11 Mar 2015 04:37:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TY7rWL51r3Gr; Wed, 11 Mar 2015 04:37:13 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 108341A00EA; Wed, 11 Mar 2015 04:37:12 -0700 (PDT)
Received: from ([]) by (8.14.3/8.14.3) with ESMTP id t2BBb8Ec019801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Mar 2015 11:37:08 GMT
Received: from ([]) by ( with ESMTP id t2BBb5mo015965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Mar 2015 12:37:08 +0100
Received: from ([]) by ([]) with mapi id 14.03.0224.002; Wed, 11 Mar 2015 12:37:06 +0100
From: "Ersue, Mehmet (Nokia - DE/Munich)" <>
To: "t.p." <>, Sam Hartman <>, "" <>, "" <>, "" <>
Thread-Topic: Secdir Review of draft-ietf-netconf-rfc5539bis-09
Thread-Index: AQHQW0n9mJmt5LFRvU2BKdI4qUhc050XKMHA
Date: Wed, 11 Mar 2015 11:37:05 +0000
Message-ID: <>
References: <> <000b01d05b2b$8d3ab2a0$>
In-Reply-To: <000b01d05b2b$8d3ab2a0$>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R)
X-purgate: clean
X-purgate: This mail is considered clean (visit for further information)
X-purgate-size: 2681
X-purgate-ID: 151667::1426073829-000067C4-B36833DA/0/0
Archived-At: <>
X-Mailman-Approved-At: Wed, 11 Mar 2015 04:52:29 -0700
Cc: "" <>
Subject: Re: [secdir] Secdir Review of draft-ietf-netconf-rfc5539bis-09
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Mar 2015 11:37:15 -0000

-----Original Message-----
From: t.p. [] 
Sent: Tuesday, March 10, 2015 1:12 PM
To: Sam Hartman;;;
Subject: Re: Secdir Review of draft-ietf-netconf-rfc5539bis-09

----- Original Message -----
From: "Sam Hartman" <>
To: <>rg>; <>rg>; <>
Cc: <>
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
> 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
> 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.


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

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