Subject: Re: [Netconf] implementing: [draft-ietf-netconf-rfc5539bis-05]

From: Kent Watsen <[email-masked]>
Date: Tue, 1 Apr 2014 19:11:42 +0000

Hi Vaibhav and Radek,

My responses to your issues are below.

BTW, congratulations on having the first TLS-based NETCONF call-home
implementation that I'm aware of.  Did you use the current
"netconf-server" configuration format for input?

Best,
Kent

>Issue #1
>--------
>
>- How to handle ssh host key verification when multiple hosts are behind a
>  NAT? - This is probably implementation specific. It depends how an SSH
>client stores hosts keys. We thought to share this issue along anyway.

This is for SSH?  The Reverse-SSH draft describes options that don't rely
on IP addresses specifically to support NAT cases.  Whether forward or
reverse, the same applies.

>Issue #2
>--------
>
>- How to handle TLS certificate hostname verification when multiple hosts
>are
>  behind a NAT? - Similar to #1. The NMS should have some kind of
>pre-defined
>knowledge, that the hostname is correct (expected for the certificate).
>Maybe
>this can be mentioned more explicitely in the NETCONF over TLS text.

The Reverse SSH draft also speaks to this too, recommending that the
device's certificate encode a unique identifier (e.g., serial-number).
But to remove the burden from the NMS, the device-vendor SHOULD ship their
device's from factory with this certificate pre-installed.  This
certificate SHOULD be signed by a chain-of-trust to the vendor's
well-known trust-anchor certificate.  This way, the NMS only needs to
trust the trust anchor and know in advance what unique-identifiers it
expects, in order to authenticate devices.

>Issue #3
>--------
>
>- What shall be the strictness of the TLS certificate mutual verification?
>  a) validate the peer certificate against a trusted CA chain.
>  b) validate using a) and check if peer certificate is locally installed.
>
>  - We think it should be configurable, but it is _not_ covered by
>    [ietf-netconf-server] data model. Should it be there?

Since you ask if it should be configurable via the netconf-server module,
I assume the question regards how the device authenticates the NMS's
client-certificate, right?  Is this what "cert-maps" in the netconf-server
module is for?

>Issue #4
>--------
>
>- Do we need to document NETCONF client-side configuration for NETCONF
>call
>  home? - This is connected with #3 - do we need to configure how the
>client
>should verify the server certificates? Or is validation of the
>certificates
>completely out of scope (for both, server and client)?

For the server authenticating the client, the netconf-server module has
"MUST close the connection" when no match found.  For the client, it looks
like the first paragraph of rfc5539bis section 2.4.1 (Server Identity)
covers it.  Are you looking for something more?

>Issue #5
>--------
>
>- [Section 2.6]: "Implementations of the protocol specified in this
>document
>  MAY implement any TLS cipher suite that provides mutual authentication
>  [RFC5246].  However, implementations MUST support TLS 1.2 [RFC5246] and
>are
>  REQUIRED to support the mandatory-to-implement cipher suite, which is
>  TLS_RSA_WITH_AES_128_CBC_SHA.  This document is assumed to apply to
>future
>  versions of TLS; in which case, the mandatory-to- implement cipher
>suite for
>  the implemented version MUST be supported."
>
>  - The CIPHER suites for TLS v1.2 are mandated by [RFC 5246: Section 9].
>Do
>    we need to mention them in this document?  We think we don't.
>Mandatory
>    ciphers are specified by TLS specification and will probably change in
>    future versions of TLS.

I don't think they need to be defined here, at least not now.

>Issue #6
>--------
>
>- [Section 2.4]: "Implementations MAY optionally support TLS
>certificate-based
>  authentication [RFC5246]."
>
>  a) Does the MAY hint towards allowing PSK-based TLS support?
>  b) We searched a bit on PSK-based TLS support in open-source projects:
>    - openssl supports PSK, also available in s_server
>    - stunnel does not support PSK, likely patchable.
>    - python does not support PSK (neither Python 2 nor Python 3)

I'm not sure what other options this text might be alluding to either.

>Issue #7
>--------
>
>- [Section 2.4.1]: "the NETCONF client MUST check its understanding of the
>  NETCONF server hostname against the server's identity" [...] "If the
>NETCONF
>  client has external information as to the expected identity of the
>NETCONF
>  server, the hostname check MAY be omitted."
>
>  a) MAY vs MUST

There's one "MUST" and one "MAY" in the quoted text, but I don't have an
issue with either statement as written.  That said, there is a different
concern related to how a "hostname" applies in the call-home case.

>Issue #8
>--------
>
>- [Section 2.3]: "The NETCONF server MUST NOT process any NETCONF messages
>  received after the <close-session> operation."
>
>  This is mandated by NETCONF protocol specification. Would it be better
>to
>  just refer to RFC 6241?

Yes, I think so.

>Issue #9
>--------
>
>- [Section 2.1.1]: Client to Server
>- [Section 2.1.2]: Server to Client
>
>  The client and server reverse roles during a NETCONF CALL HOME. Would
>it be
>better to explicitly prefix "NETCONF" in the section titles?

Well, first off, section 2.1.2 is titled "Server to Client (Call Home)".
The "(Call Home)" seems to clearly identify what each section is about.
At least nothing seems out of place to me.  Is the following what you'd
like to see instead?

- [Section 2.1.1]: NETCONF Client to NETCONF Server
- [Section 2.1.2]: NETCONF Server to NETCONF Client

I don't think this is better; it looks very busy.  Not having the "(Call
Home)" makes it harder to understand.  My opinion only, maybe others feel
strongly the other way.

Thanks,
Kent

---

From: Radek Krejčí <[email-masked]>
Date: Wed, 02 Apr 2014 14:53:36 +0200

HiKent,
comments to issues, where I have something to say, inline..

> "netconf-server" configuration format for input?

Not yet, but I'm working on it. So far, we have a standalone app that
initiate call home according to the command line arguments. But I'm
going to integrate it into the NETCONF server using ietf-netconf-server
data model.

> reverse, the same applies.

yes, as mentioned, this is probably implementation specific regarding
how OpenSSH's client usually stores known hosts and then checks if the
key of the specific remote host changed. I think that description in
Reverse SSH draft sec 5 is enough.

> expects, in order to authenticate devices.

I just think, that description of the server side identification in
Reverse SSH draft (sec 5) is more clear than the section in rfc5539bis
(sec 2.4.1). Probably because in the first case, it is focused only to
reverse connection while rfc5539bis describes both, forward and reverse
connection. As mentioned in #7, the first paragraph of sec 2.4.1 states
that "...client MUST check its understanding of the NETCONF server
hostname..." but the last paragraph says "the hostname check MAY be
omitted" (if it MUST be checked, it is not allowed to be omitted). I
think that it should be clearly stated, what applies to forward and what
applies to reverse connection.

> client-certificate, right?  Is this what "cert-maps" in the netconf-server

in this point, it is about a device - but not actually authentication
(which is covered by cert-maps), but verification if the client
certificate is valid and mainly trusted and can be passed further to
cert-to-username mapping. We have options to trust to all certificates
signed by a trusted CA (chain) or trust only to an explicit list of
certificates (similar to what client can do when checking server
identity). But AFAIK there is no such setting in the netconf-server data
model. We don't insist on putting this to the data model, we are just
asking WG if it is supposed to be there or it is expected to be
implementation-specific (because somewhere it must be specified/configured).

> covers it.  Are you looking for something more?

just asking if someone is willing to explicitly describe configuration
(data model?) for a client side. Specifically the configuration how the
server certificate is supposed to be validated (chain-of-trust, list of
trusted server certificates/keys,...). Personally, I don't think that
this is necessary.

> concern related to how a "hostname" applies in the call-home case.

Already mentioned in my comment to #2 - where it is said what applies to
call-home? I don't see any note about difference between forward and
reverse connection in whole section 2.4.

Regards,
Radek

---

From: Kent Watsen <[email-masked]>
Date: Wed, 2 Apr 2014 17:58:10 +0000

>Reverse SSH draft sec 5 is enough.

Agreed.  No change to Reverse SSH text.

>applies to reverse connection.

Agreed, a change to the 5529bis text is needed.

>implementation-specific (because somewhere it must be

I think I see what you're saying now and I think that it might be an issue
with draft-ietf-netmod-system-mgmt, which defines how user's passwords and
ssh-keys can be configured.  Missing from section 3.5 (User Authentication
Model) in that draft is any place where a TLS client-certificate (or a CA
that can vouch for client certificates) can be configured.  Which I think
your question is primarily about.

There may also be a larger question regarding if the netconf-server draft
should depend on the netmod-system draft.   Also, we might want to
double-check that it makes sense to have cert-maps and psk-maps in the
netconf-server model at all.  What do you think?

>trusted server certificates/keys,...). Personally, I don't think that

Agreed, no need to explain how clients can verify servers.  Though,
wherever server-certificates are configured, it should be noted that the
certificate MAY be signed by a chain of CAs and that, when the case
arises, that the server MUST return the entire chain-of-certificates
during TLS connection establishment.

>reverse connection in whole section 2.4.

Yeap, and as mentioned in #2 above, a change to the 5529bis text is needed.

Thanks,
Kent

---

From: Radek Krejčí <[email-masked]>
Date: Thu, 03 Apr 2014 11:03:19 +0200

> your question is primarily about.

yes, but I don't think that it can be set on per-user basis since in TLS
you get username from a client certificate and this mapping is done
after validation of the certificate. So, TLS client-cert / trusted CAs
configuration should be placed into /system/authentication/ and it will
be applied to all users (resp. in time when there is no knowledge about
a specific username)

> netconf-server model at all.  What do you think?

agree. Actually I don't have a preference where these configuration
items should be (system-mgmt or netconf-server), but it should be all in
the same document. Sec 3.5 in netmod-system-mgmt says that "the
authentication parameters defined in this document are primarily used to
configure authentication of NETCONF users" which can be also applied to
cert-maps and psk-maps, right?

Regards,
Radek

---

From: Radek Krejčí <[email-masked]>
Date: Fri, 04 Apr 2014 13:43:56 +0200

Hi,
I have update to this.

I checked ietf-x509-cert-to-name in more detail and I have a question to
the description in grouping cert-to-name/list cert-to-name. The text
says, that the fingerprint value in configuration data can match 1) a
client certificate or 2) CA certificate that is part of CA chain in a
client certificate. The text speaks about matching for purposes of
cert-to-name mapping, but can it be also read as "presented certificate
is _trusted_ if 1) its fingerprint matches.. or 2) fingerprint of one of
its CA certificate in its chain matches ..fingerprint value in
configuration data"?

If so, it actually specifies what I was missing.Previously I missed that
the fingerprint value can refer also to a CA certificate. However,
moving user authentication config for SSH (currently in system-mgmt) and
TLS (cert-maps and psk-maps) together may not to be a bad idea.

Radek

Dne 3.4.2014 11:03, Radek Krejčí napsal(a):
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Fri, 4 Apr 2014 15:26:37 +0000

+andy

>be applied to all users (resp. in time when there is no knowledge about

OK, so missing is a way to configure a list of trusted CA certs and
trusted client certs at a system-wide level.

>cert-maps and psk-maps, right?

Yes, I think that netmod-system-mgmt should be updated.  Unfortunately, it
is currently being reviewed by IESG.  I don't know if it's too late now.

Andy, if you're already updating netmod-system-mgmt, can we move the
cert-maps, psk-maps into it?  - and also add the configuration of
system-wide trusted CA and client certs mentioned above?

Kent