Subject: [Netconf] AD review of draft-ietf-netconf-monitoring-12

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 27 Apr 2010 12:39:05 +0200

Please find below the AD review of draft-ietf-netconf-monitoring-12.
This document is ready for IETF Last Call and the issues and questions
raised below can be solved together with the other IETF Last Call
comments. 

Technical 

T1: 
username (string)
     If present, the username contains an identifier which can be
     used to uniquely identify an individual client (human or
     machine).

Why 'if present'? Are there situations where the server does not know
the unique identity of the client? 

T2: 
    
 If requested schema is not unique, the <error-tag> is
     'operation-failed', and <error-app-tag> is 'data-not-unique'.

What does 'if requested schema is not unique' mean - that the version
parameter is not included in the request, and there are more than one
version available? Are there other cases? 

T3. The Security Considerations section will need to be replaced with
text that conforms to the guidelines for SC sections in YANG modules
documents which - hopefully - will be approved by the time of
publication of this document. In the meantime it would not harm to
re-write this section in the next revision of the I-D according go the
latest proposal on this respect (would be a good opportunity to verify
the guidelines with 'running code'. 

Editorial

E1: ADs commenting on other NETMOD and NETCONF documents consider
NETCONF as acronyms that need to be expanded at first occurrence. 

E2. copyright year in the YANG module should be changes to 2010. 

E3. in the description of netconf-soap-ver-beep and
netconf-soap-over-https I think the more correct and complete
description is 'NETCONF over SOAP over BEEP' and 'NETCONF over SOAP over
HTTPS' and not 'NETCONF SOAP ....'

E4. description of yang and yin - no need for 'YANG is a ...' 'YIN is an
...' 

Thanks and Regards,

Dan

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 28 Apr 2010 12:56:26 +0200 (CEST)

Hi,

My comments inline.

> the unique identity of the client? 

RFC 5539 (NETCONF over TLS) does not specify how to derive a username.
But maybe the intention of 5539 is that implementations will derive a
user name (in a non-standardized way)?  If so, I agree we should
remove the 'if present' text.

> version available? Are there other cases? 

If the device has multiple revisions and or multiple formats
available, and no revision or format parameter is specified, this
error will occur.   In the YANG model this is described as:

   If more than one schema matches the requested parameters, the
   <error-tag> is 'operation-failed', and <error-app-tag> is
  'data-not-unique'.";

which maybe is better.

> the guidelines with 'running code'. 

Ok.

> NETCONF as acronyms that need to be expanded at first occurrence. 

Ok.

> E2. copyright year in the YANG module should be changes to 2010. 

Ok.

> HTTPS' and not 'NETCONF SOAP ....'

Ok.

> E4. description of yang and yin - no need for 'YANG is a ...' 'YIN is an

How about:

  identity yang {
    base schema-format;
    description
      "The YANG data modeling language for NETCONF";
    reference
      "RFC XXXX:  YANG - A data modeling language for NETCONF";
  }

  identity yin {
    base schema-format;
    reference
      "The YIN syntax for YANG.";
    reference
      "RFC XXXX:  YANG - A data modeling language for NETCONF";
   // RFC Ed.: replace XXXX with actual RFC number and remove this note
  }

/martin

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 28 Apr 2010 13:05:16 +0200

Thanks for the fast response. See in-line a few responses.

I suggest that you do not update the document now, but we rather send it
to IETF LC and consider these comments together with the other IETF LC
comments. Mehmet (as document shepherd) - are you OK with this? 

Dan

> -----Original Message-----
> From: Martin Bjorklund [mailto:[email-masked]] 
> Sent: Wednesday, April 28, 2010 1:56 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12
> 
> Hi,
> 
> My comments inline.
> 
> But maybe the intention of 5539 is that implementations will 
> derive a user name (in a non-standardized way)?  If so, I 
> agree we should remove the 'if present' text.

I do not know whether we need a standard, but if the user name is always
known than 'if present' is not needed. 

>    <error-tag> is 'operation-failed', and <error-app-tag> is

I agree the text in the YANG model is better. 'unique' sounds odd here. 

> > description is 'NETCONF over SOAP over BEEP' and 'NETCONF over SOAP 
> > over HTTPS' and not 'NETCONF SOAP ....'
> 
> Ok.
> 
> > E4. description of yang and yin - no need for 'YANG is a 
> ...' 'YIN is 
> > an ...'
> 
> How about:
> 
>   identity yang {
>     base schema-format;
>     description

OK.

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 28 Apr 2010 13:23:22 +0200

Hi Dan,

yes. We can submit an update later together with other fixes.

Cheers,
Mehmet

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Romascanu, 
> Dan (Dan)
> Sent: Wednesday, April 28, 2010 1:05 PM
> To: Martin Bjorklund
> Cc: [email-masked]
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Mark Scott <[email-masked]>
Date: Wed, 28 Apr 2010 11:06:15 -0400

Hi Dan,

The 'if present' for the username node covers cases where there may not be a specific 'username' for the session (as Martin noted below), but also cases where the server may choose to specifically omit this from the response.  E.g. user specific data may be considered sensitive in some implementations and access to it may be more restricted than the other session details.

In addition to the changes agreed below we will also:
  - fix the double reference (in the yin identity) in the yang module.
  - include the new security text in the RFC body

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ersue, Mehmet (NSN - DE/Munich)
Sent: April-28-10 7:23 AM
To: ext Romascanu, Dan (Dan); Martin Bjorklund
Cc: [email-masked]
Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12

Hi Dan,

Cheers,
Mehmet

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 29 Apr 2010 09:51:56 +0200

> From: Mark Scott [mailto:[email-masked]] 
> Sent: Wednesday, April 28, 2010 6:06 PM
> To: Ersue, Mehmet (NSN - DE/Munich); Romascanu, Dan (Dan); 
> Martin Bjorklund
> Cc: [email-masked]
> Subject: RE: [Netconf] AD review of draft-ietf-netconf-monitoring-12
> 
> Hi Dan,
> 
> The 'if present' for the username node covers cases where 
> there may not be a specific 'username' for the session (as 
> Martin noted below), but also cases where the server may 
> choose to specifically omit this from the response.  E.g. 
> user specific data may be considered sensitive in some 
> implementations and access to it may be more restricted than 
> the other session details.
> 

This later seems to me a different case than 'if present'. The
information exists but is considered security-sensitive. I also do not
think that it is an implementation-specific issue, but a
deployment-specific issue. How does the server 'choose' to omit the user
name from a response? Is this a global (per server) decision or a per
user decision? 

Dan

---

From: Mark Scott <[email-masked]>
Date: Fri, 30 Apr 2010 09:51:46 -0400

Dan,

In one of our previous implementations only users whose privilege level included 'security admin' were allowed to see user specific data in any responses.  Such privileges were configured per user (i.e. per customer deployment) but the set of sensitive data was fixed on the server (i.e. per our server implementation).

In this case we consciously chose not to use any of the existing errors to indicate partial operation or partial data.  This was on advice of our security primes who felt that indicating partial data invites further attempts to access it.
	- clearly this implementation was not 4741 compliant so I'm not proposing the above behaviour as standard but I assume others have dealt with such cases similarly

In terms of clarifying this in the monitoring draft:

I agree the term 'if present' isn't clear.

How about:  'if the session is authorized to access such data the username will be in the reply.  If not this data must be omitted from the response.'?

When adding the new yang module security template I can also specifically list the 'username' as potentially sensitive read-only data.  

The template already contains multiple 'may be considered sensitive' clauses which reflect the points above.

Mark

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: April-29-10 3:52 AM
To: Mark Scott; Ersue, Mehmet (NSN - DE/Munich); Martin Bjorklund
Cc: [email-masked]
Subject: RE: [Netconf] AD review of draft-ietf-netconf-monitoring-12

Dan

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Apr 2010 10:35:49 -0700

> The template already contains multiple 'may be considered sensitive' clauses which reflect the points above.

I don't think we should create any special cases that might
conflict with the NACM standard in the future.
The monitoring draft should have a security considerations
section, and not say anything about what the server must do
if unauthorized data needs to be handled.
This draft just needs to identify and explain the sensitive data.

> Mark

Andy

---

From: Mark Scott <[email-masked]>
Date: Fri, 30 Apr 2010 13:59:45 -0400

Thanks Andy,

The security section will be updated and will include 'username' details per the new yang module template.

I will also remove the text suggesting the special handling ('if present') from sec 2.1.4:

"username (string)
     The username contains an identifier which can be used to 
     uniquely identify an individual client (human or machine)."

and from the yang module:

"leaf username  {
          type string;
          description
            "The username contains an identifier which can
             be used to uniquely identify an individual client (human
             or machine).  This is likely to be implementation specific
             and subject to the security requirements of the device
             vendor and/or operators,  e.g., an SSH user, a host RSA
             fingerprint or other identifier deemed acceptable.";
        }"

cheers,
Mark

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: April-30-10 1:36 PM
To: Mark Scott
Cc: Romascanu, Dan (Dan); Ersue, Mehmet (NSN - DE/Munich); Martin Bjorklund; [email-masked]
Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 30 Apr 2010 21:34:39 +0200

>      uniquely identify an individual client (human or machine)."

Now that we have the text in front of us: 'contains an identifier' or
'is an identifier'? what does 'uniquely identify an individual client'
mean? If I have user joe using two clients a and b to access a server
concurrently, will the usernames be "joe-a" and "joe-b"? Likely not,
but the text says "uniquely identify an individual client". And what
does (human or machine) mean? Whether joe relates to a human or a
program, a server won't know. So what about this:

      The username identifies the authenticated identity on which
      behalf a client accesses a server.

I believe this is shorter and more precise.
 
>              fingerprint or other identifier deemed acceptable.";

Similar changes should be done here if people like my proposal.

/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: Martin Bjorklund <[email-masked]>
Date: Fri, 30 Apr 2010 22:52:11 +0200 (CEST)

> This draft just needs to identify and explain the sensitive data.

I fully agree with this.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 30 Apr 2010 22:57:43 +0200 (CEST)

Mark Scott <[email-masked]> wrote:
> Thanks Andy,
> 
> The security section will be updated and will include 'username'
> details per the new yang module template. 
> 

If we agree that the username is always there, we should add a
'mandatory true;' statement to the leaf.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 1 May 2010 08:32:35 +0200

> > This draft just needs to identify and explain the sensitive data.

+1

/js