Subject: Re: [Netconf] [secdir] secdir review of draft-ietf-netconf-monitoring

From: Sam Hartman <[email-masked]>
Date: Wed, 16 Jun 2010 20:26:33 -0400

>>>>> "Juergen" == Juergen Schoenwaelder <[email-masked]> writes:

    >> The document defines a data model for netconf monitoring.  The
    >> security considerations section says in part:
    >> 
    >> Some of the readable data nodes in this YANG module may be
    >> considered sensitive or vulnerable in some network environments.
    >> It is thus important to control read access (e.g. via get,
    >> get-config or notification) to these data nodes.
    >> 
    >> What is unclear from the document is whether or not the data is
    >> secure *after* access is gained.  i.e. is there a secure
    >> transport layer?  Should one be used?  If not, why?

    Juergen> NETCONF runs over SSH or TLS or TLS/BEEP or SOAP/HTTPS. In
    Juergen> other words, all existing NETCONF transports are
    Juergen> "secure". The revision of the NETCONF specification being
    Juergen> worked on is going to make this hopefully clearer by
    Juergen> calling the transport layer "secure transports".

I'll admit that if I read the netconf document and it described
something as "secure transport," it would raise a concern in my mind.
"secure" as an adjective is generally meaningless.  Typically it's
applied to make people feel that security objectives are met without
actually stating those objectives.

Presumably by secure, you mean something like:

* Transport authenticates identity of server to client and client to
  server
* Transport provides integrity protection and confidentiality for data
  transported
* Transport provides replay protection on a per-session level as well as
  within a session

I'd be far more interested in the core document making these security
services explicit than in having it replace all instances of transport
with "secure transport."

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Jun 2010 09:23:50 +0200

> services explicit than in having it replace all instances of transport

Yes, I agree.

/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: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Jun 2010 13:19:55 +0200

> services explicit than in having it replace all instances of transport

There is text in section 2 of draft-ietf-netconf-4741bis-02 talking
about security requirements of the transports - and this text is
pretty much the same as the text that can be found in section 2 of RFC
4741. I will go over the text to see whether it can be further
tightened or detailed (e.g. I see replay protection is not explicitely
mentioned). But it definitely not the case that "secure transport" is
a meaningless adjective in the NETCONF world even today.

/js

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Jun 2010 09:01:32 -0400

OK.  I did review the netconf core spec when it came before the IESG and
was happy with it at the time.