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

[Sam Hartman <[e-mail]>]

>>>>> "Juergen" == Juergen Schoenwaelder <[e-mail]> 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."