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

From: Alan DeKok <[email-masked]>
Date: Fri, 11 Jun 2010 10:00:43 +0200

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

 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?

  A statement about privacy and security, with a reference to an
existing netconf document would be good.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Jun 2010 10:09:56 +0200

> Should one be used?  If not, why?

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

There has been progress very recently on formulating a security
considerations template for documents that contain NETCONF/YANG data
models and I think it would be good if this document would indeed
follow these guidelines.

/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: Alan DeKok <[email-masked]>
Date: Fri, 11 Jun 2010 10:30:32 +0200

Martin Bjorklund wrote:
>> NETCONF runs over SSH or TLS or TLS/BEEP or SOAP/HTTPS. 

  I saw that.

> In other

  OK.

> Actually, this document follows the latest security considerations
> template.
> 
> However, the template does not mention that NETCONF runs over a secure
> transport.  Maybe the template (and this document) should be updated
> to make this clear?

 That would be good.  I saw the discussion on the template in the list
archives, and was surprised that it mentioned only access to data, and
not security or privacy.

  Alan DeKok.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Jun 2010 10:55:06 +0200

> Actually, this document follows the latest security considerations

I guess I have to dig out the latest guidelines now... OK, I stand
corrected - the template is indeed pretty short for a read-only
module.
 
> transport.  Maybe the template (and this document) should be updated

Yes, it seems some introductionary text in the security considerations
about NETCONF might be useful, especially since not all people are
familiar with NETCONF yet. Here is a first draft:

   The YANG module defined in this memo is designed to be accessed 
   via the NETCONF protocol [RFC4741]. The lowest NETCONF layer is
   the secure transport layer and the mandatory to implement secure
   transport is SSH [RFC4742].

I am CCing Bert Wijnen since he drove the development of the security
considerations template.

/js

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Fri, 11 Jun 2010 16:49:50 +0200

Juergen, I will add your text to the template.

I am assuming that Dan will check this further with the securioty ADs.
The status (as far as I know) is that the security ADs are/were
evaluating our latest template (modulo one typio and your new  text).

Bert
----- Original Message ----- 
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; "Bert Wijnen" 
<[email-masked]>
Sent: Friday, June 11, 2010 10:55 AM
Subject: Re: [secdir] secdir review of draft-ietf-netconf-monitoring

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 11 Jun 2010 10:19:49 +0200 (CEST)

Hi,

/martin

---

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:
    >> 
    >> 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

---

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.