RE: Secdir Review of draft-ietf-netconf-rfc5539bis-09

["Ersue, Mehmet (Nokia - DE/Munich)" <[e-mail]>]

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

----- Original Message -----
From: "Sam Hartman" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
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
>