-----Original Message----- From: t.p. [mailto:daedulus@xxxxxxxxxxxxx] Sent: Tuesday, March 10, 2015 1:12 PM To: Sam Hartman; ietf@xxxxxxxx; secdir@xxxxxxxx; iesg@xxxxxxxx Cc: draft-ietf-netconf-rfc5539bis.all@xxxxxxxxxxxxxx Subject: Re: Secdir Review of draft-ietf-netconf-rfc5539bis-09 ----- Original Message ----- From: "Sam Hartman" <hartmans-ietf@xxxxxxx> To: <ietf@xxxxxxxx>; <secdir@xxxxxxxx>; <iesg@xxxxxxxx> Cc: <draft-ietf-netconf-rfc5539bis.all@xxxxxxxxxxxxxx> 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 >