Subject: [Netconf] comment on draft-ietf-netconf-rfc5539bis-05

From: Martin Bjorklund <[email-masked]>
Date: Wed, 05 Mar 2014 11:12:28 +0000 (GMT)

Hi,

I have reviewed this document, and have just one comment.

The last paragraph of section 2.4.1 says:

  If the NETCONF client has external information as to the expected
  identity of the NETCONF server, the hostname check MAY be omitted.

There are some MUSTs in the preceding paragraphs, and it is not clear
to me what "the hostname check" refers to.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 18 Mar 2014 10:38:45 +0100

> to me what "the hostname check" refers to.

I agree that this needs to be clarified in particular for outgoing
call-home connections and I am not sure this is an easy one to
address.

For a conventional NETCONF client, you typically specify the hostname
of the NETCONF server and then you check whether the certificate
presented by the server is valid and matches the hostname.

For call home, this is getting tricky. The NETCONF server has local
config that says connect to TCP endpoint X to reach the NETCONF
client. The NETCONF client now starts the TLS and receives a
certificate which likely asserts a hostname. While the TLS client can
validate the certificate, the question remains how the client verifies
it is really talking to the right server? Since it does not know the
hostname, we have three options (at least):

1) The certificate must include the IP address used by the NETCONF
   server when it initiated the call home procedure.

2) The NETCONF client does a reverse lookup to obtain a hostname that
   is then checked against the certificate (but can we trust DNS? -
   likely not).

3) The NETCONF client has configured call home information that
   associates IP addresses of NETCONF servers calling home with either
   a hostname or likely even better with certificate fingerprints.
   This, of course, makes call home of yet unknown devices
   non-automatic.

Note that the SSH call home mechanism has a similar problem to solve
and I am not sure I understand what the solution is there either.
There is some high-level text about host-keys and a recommendation
that host-keys should be signed by a common key but I do not get from
this what needs to be implemented. The server configuration I-D has
a host-keys container but there is not much description here either:

                  "An ordered listing of the SSH host keys the
                   device should advertise to the application.";

                      "The name of a host key the device should
                       advertise during the SSH key exchange.";

I do not know what the idea here is - establish the SSH and NETCONF
session, then do a get-config to retrieve the keys and if the
information does not match what I have used, drop the sessions?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 18 Mar 2014 17:18:15 +0000

>call-home connections and I am not sure this is an easy one to

The lines quoted above were cut-n-pasted from HTTP Over TLS (RFC 2818)
section 3.1 (server identity):
http://tools.ietf.org/html/rfc2818#section-3.1.  I raised this issue
before, on the -03 version of this draft, but see no follow-ups in the
archives:

    http://www.ietf.org/mail-archive/web/netconf/current/msg08075.html

>   This, of course, makes call home of yet unknown devices

Ultimately, we want to apply the same reasoning presented in the Reverse
SSH draft, section 5 (SSH Server Identification and Verification).  As for
terminology, please note that when the TLS draft refers to "hostname", it
means the component identifying the server in a URL.  Also, when the
Reverse SSH draft refers to "Host Key", it is equivalent to the server
certificate in TLS.  So, the same rules apply:

1) it is possible for the NMS to identify the device solely via its
source-IP, but only works in networks with static addresses.  This
strategy requires the NMS to have a store of trusted IP addresses.

2) it is possible for the NMS to identify the device via its certificate.
Think "strcmp()".  This could be either via comparing the entire
certificate or a fingerprint of the certificate.  But this strategy
requires the NMS to have a store of trusted device certificates.

3) it is *recommended* for the NMS to identify the device via information
contained inside the certificate - a unique identifier (e.g., serial
number, FQDN, etc.).  But this strategy requires the NMS to have a store
of trusted unique identifiers.  This approach is recommended because it
works even the certificate changes so long as the identifier is the same.

4) Making #3 even better, it is further recommended the NMS validates the
device's certificate via path-verification to a trusted CA (not explicitly
as described in #2).  This enables the NMS to have to trust just a single
certificate (the CA's), not each device's...

Makes sense?

>information does not match what I have used, drop the sessions?

You are probably familiar with SSH host-keys like "id_rsa.pub" and
"id_dsa.pub".  When using OpenSSH, the sshd_config file can contain one of
more "HostKey" entries, an ordered list.  The ordering is important to the
SSH protocol, not just the OpenSSH implementation.  The configuration
described in the netconf server configuration draft mentioned above maps
directly onto this concept, enabling it to be configurable per NMS.

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 18 Mar 2014 18:53:34 +0100

> certificate (the CA's), not each device's...

No. First, there needs to be an interoperable procedure for a
standard. Second, this is not about how to extract an identity or
something like that but how to check that the identity presented is an
expected identity, means it is trust worthy and not an attempt to fool
the NETCONF client.

> "id_dsa.pub".

These typically are _not_ host keys.

> When using OpenSSH, the sshd_config file can contain one of

If this is the thing you want to solve, this first of needs to be
described clearly. But then I am not sure why this needs to be solved.
My SSH servers all have keys of different types, e.g.,

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

and somehow clients manage to use the servers without me configuring
things. Are we moving into general SSH server configuration territory?
Should these details be handled by a generic SSH server configuration
data model, I mean is this essential for every NETCONF over SSH call
home implementation?

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 18 Mar 2014 22:28:12 +0000

>expected identity, means it is trust worthy and not an attempt to fool

There is no foolery here, this is how it works.  When using a TLS-client
library, it undoubtedly provides a callback that will be executed for the
app to state whether the server's certificate can be trusted.  In addition
to the certificate itself (and any intermediate certs that may also have
been provided), the callback will likely also a handle to a "connection"
object of some sort, from which the application can learn the peer's
source IP address.  So that's it, the app has an IP-address, a certificate
(+intermediate certs), and its preconfigured state.

>These typically are _not_ host keys.

You're right, I meant ssh_host_rsa_key.pub and ssh_host_dsa_key.pub.

>data model, I mean is this essential for every NETCONF over SSH call

It is SSH-server configuration, yes, but not for the generic server
listening on port 22 and also not for any generic configuration option.
We just need enough to support the netconf-server config model draft (keep
alive interval, keep alive count max, etc.).   Being able to configure
which SSH HostKeys are presented is equivalent to being able to configure
which TLS server-certificate the device should present, if there is more
than one, which is completely possible.

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 21 Mar 2014 08:46:47 +0100

> (+intermediate certs), and its preconfigured state.

So what is this preconfigured state? How is the decision been taken?
All implementation specific? So I need to study the vendors handbooks
to figure out how setup things?

> than one, which is completely possible.

This is inconsistent. We have no configuration model for all these
things for the regular case - why do we now go ahead and define some
of this for the call home case?

/js