Subject: [Netconf] FW: DISCUSS and COMMENT: draft-ietf-netconf-monitoring

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 17 Jun 2010 12:20:02 +0200

Dear NETCONF WG,

below is the response Martin sent to one of the last DISCUSSes.

Mehmet

-----Original Message-----
From: ext Martin Bjorklund [mailto:[email-masked]] 
Sent: Thursday, June 17, 2010 11:24 AM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: DISCUSS and COMMENT: draft-ietf-netconf-monitoring 

Hi David,

David Harrington <[email-masked]> wrote:
> Discuss:
> Good job. I ma glad to see this work and the YANG work progressing.
> I have a few thinsg i think should be addressed before this is
approved as a
> standard.
> 
> 1) username - in ISMS we had a lot of trouble determining when and if
the
> user-name from SSH was actually available, and the SSH username can be
blank
> (IIRC). In other transport authentication schemes, a username may not
be
> available. But this information might be critical for use in access
control
> decisions, which currently are implementation-specific. Security
considerations
> does not discuss this potential problem.

I agree that this info is critical for access control, but in this
document the user name is simply reported for monitoring purposes, so
I do not see how the security considerations in this document should
discuss this.

> In ISMS, SSHTM permitted transformations from the "username" used by
the
> transport to a management-system specific identifier. In USM, this is
also done
> via a user table assignment. You should be careful about locking
yourself in.
> 
> 2) existing security infrastructures, such as SSH, may offer features
that
> would make doing a direct mapping between user-name and the nsm
username.
>    Because naming policies might differ between administrative
domains,
>    many SSH client software packages support a user@hostname:port
>    addressing syntax that operators can use to align non-equivalent
>    account names.  The SnmpSSHAddress Textual Convention echos this
>    common SSH notation.
> Again, you might want to avoid a direct mapping requirement.
> 
> I recommend removing the statement about how username is set from SSH,
and
> simply state that the identity is established by the Netconf transport
> protocol. Let the Netconf-ssh decide how to establish a username.

I agree.  This makes sense.  Following your recommendation, I propose
this change (in two places; the text and YANG module):

OLD:

  The username is the client identity that was authenticated by the

  NETCONF transport protocol. The algorithm used to derive the

  username is NETCONF transport protocol specific and in addition

  specific to the authentication mechanism used by the NETCONF

  transport protocol.

  For NETCONF over SSH (RFC4742), the username is the 'user name'

  in the SSH_MSG_USERAUTH_REQUEST (RFC4252, Section 5).

  For other transport protocols, the algorithm to derive the username

  is implementation specific.        

NEW:

  The username is the client identity that was authenticated by the

  NETCONF transport protocol. The algorithm used to derive the

  username is NETCONF transport protocol specific and in addition

  specific to the authentication mechanism used by the NETCONF

  transport protocol.

> 3) the algorithm to derive the username is implementation-specific.
The
> security considerations should discuss that different implementations
might
> derive the same username for different users, so the value might not
be
> comparable across implementatons. In ISMS, we addressed the issue that
an SSH
> transport model might come up wth a name, and then a TLS transport
model come
> up with the same name, even within the same management system. Given
that the
> username might be used to identify who made an undesirable change, and
to
> discipline that person, this is a pretty big "well, maybe this means
this user,
> and maybe it means that user."

With the text proposed above we now simply say that the mechanism to
derive the username is transport specific.  In the session list
defined in this document, we list the username and the transport used
for the session, so I think this addresses your concern that different
transports may derive the same user name.

> 4) Your use of "RFC XXXX" is ambiguous. "identity YANG" and "identity
yin" call
> for a reference to RFC XXXX (the YANG RFC), as does the "module" and
"revision"
> statements (the monitoring RFC). These are different XXXX's.

Each such "XXXX" has a comment to the RFC editor to replace with the
proper RFC number.  But if this ambigous to the RFC editor we can of
course use YYYY etc. as necessary.

> 5) container sessions has an exclusion statement that can be
interpreted
> different ways:
> "Any session not managed by the NETCONF server ... MUST be excluded"
versus
> "(Any session ... with session identifier 0) MUST be excluded"
> versus
> "(Any session not managed ... with session identifier 0) MUST be
excluded"
> (which would exclude all non-zero sessions)
> Can you tighten this?

We simply want to say that all netconf sessions are listed, and I
think the last part is not needed anymore, so I suggest:

OLD:

          "All NETCONF sessions managed by the NETCONF server

           MUST be reported in this list.

           Any sessions not managed by the NETCONF server with

           session identifier 0 MUST be excluded.";

NEW:

          "All NETCONF sessions managed by the NETCONF server

           MUST be reported in this list.";                  

> 6) To avoid unused reference warnings from idnits, in MIB modules we
specify
> outside the module itself what normative references exist in the
module and
> provide citations.

Ok.  I suggest we add to section 5, before <CODE BEGINS>:

   This YANG module imports typedefs from [YANG-TYPES] and references
   [RFC4741], [RFC4742], [RFC4743], [RFC4744], [RFC5539], [xmlschema-2],
   [YANG], [ISO/IEC 19757-2:2008], and [RFC5717].

> Comment:
> 1) section provides an overview of data "which MUST be present".
"MUST" is
> usually used to specify normative behavior. I suggest you specifically
say that
> section 2 is a "non-normative overview", so that if there are errata
that lead
> to conflicts between 2 and 5, there is no question that section 2 is
> non-normative, and section 5 is normative.

As a result of another comment, this text was changed to:

   This section presents an overview of the monitoring data model.  For
   detailed descriptions refer to the normative YANG module provided in
   this document (see Section 5).

> 2) login-time. since clocks on the server and client can differ, this
should
> say the "Time at the server at which the session was established."

Ok.

> 3) source-host: this is the netconf client? (which could be different
than,
> say, the SSH client or the TLS client, etc.)

Yes, I will change to "NETCONF client".

> 4) leaf source-host 
> s/is likely to be implementation-specific
> /is implementation-specific

Ok.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 17 Jun 2010 12:41:55 +0200 (CEST)

Hi,

>   specific to the authentication mechanism used by the NETCONF

It turns out that the 'user name' field can be empty, and the real
user name derived from other authentication messages, see section 3.1
and 3.2 of RFC 4462.  Instead of going into these details in this
document, I think it is better to just say that we report the user
name that the transport gives us.

We can always discuss if 4742bis should talk about this or not.

For reference, RFC 5592 says in 4.1.1:

      How the SSH user name is extracted from the SSH layer is
      implementation-dependent.

/martin

---

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

> We can always discuss if 4742bis should talk about this or not.

I agree that 4742bis is the right place to discuss this. As mentioned
in a separate thread, 4741bis should state which security services the
secure transports must provide and 4741bis should IMHO establish a
requirement that specifications of secure transports must provide a
section explaining how an authenticated user name can be provided.

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