Subject: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT)

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 1 Mar 2011 17:09:15 +0100

Hi All,

attached is the DISCUSS David Harrington entered on
draft-ietf-netconf-rfc4742bis-07.

We discussed the issue with the username in the NETCONF WG intensively 
(see the 4742bis discussion in
http://www.ietf.org/proceedings/78/minutes/netconf.txt).

Naming policies might differ between administrative domains and 
identities represented as usernames mean different things in 
different operating systems.
Following the statement in RFC 5592 the WG decided that the 
method to obtain the username for the NETCONF Server from SSH 
should be implementation-dependant.

I agree, that such an explanation is missing in the current draft.
I would suggest to add following text to
draft-ietf-netconf-rfc4742bis-07:

OLD:
   How the NETCONF Server extracts the SSH user name from the SSH layer
   is implementation-dependent.

NEW:
   There is no standard way for an application running on an SSH server 
   to determine a user name for the current session. It may be necessary

   to use a mapping algorithm to transform an SSH identity to a user. 

   How the NETCONF Server extracts the SSH user name from the SSH layer
   is implementation-dependent. Any transformations applied to the
   authenticated user name by the SSH server are outside the scope of
   this document.

Please comment. If you disagree please send a concrete text proposal.

Cheers, 
Mehmet 

-----Original Message-----
From: ext David Harrington [mailto:[email-masked]] 
Sent: Monday, February 28, 2011 11:23 PM
To: The IESG
Cc: [email-masked];
[email-masked]
Subject: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07:
(withDISCUSS and COMMENT)

David Harrington has entered the following ballot position for
draft-ietf-netconf-rfc4742bis-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

1) 4741bis says: "The authentication process MUST result in an
authenticated client
   identity whose permissions are known to the server.  The
   authenticated identity of a client is commonly referred to as the
   NETCONF username.  The algorithm used to derive the username is
   transport protocol specific and in addition specific to the
   authentication mechanism used by the transport protocol.  NETCONF
   transport protocols therefore MUST explain how a NETCONF username is
   derived from the authentication mechanisms supported by the transport
   protocol.

   The access permissions of a given client, identified by its NETCONF
   username, are part of the configuration of the NETCONF server.  These
   permissions MUST be enforced during the remainder of the NETCONF
   session.  The details how access control is configured is outside the
   scope of this document."

4742bis says: "How the NETCONF Server extracts the SSH user name from
the SSH layer
   is implementation-dependent."

This is not an explanation. Assuming an operator must specify access
control rights for a user in the configuration o fthe server, it is
important that the operator understands what the netconf username(s)
will be. That is presumably why it is important for the Netconf
transport protocol specification to explain the algorithm for deriving
the username.

RFC5592 defines an SSH subsystem for use with SNMP, and has had to deal
with similar issues, including constraints about not changing the
username associated with a session, allowing "user@host" style naming,
etc.
Maybe those are not needed for netconf, but the above
"implementation-dependent" explanations seems woefully inadequate.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) The IANA section does not specify that the assigned port is a TCP
port. should it?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Mar 2011 18:15:35 +0100

>    authenticated user name by the SSH server are outside the scope of

I would even shorten the text as follows:

    There is no standard way for an application running on an SSH
    server to determine a user name for the current session.  How the
    NETCONF Server extracts the user name from the SSH layer is
    therefore implementation-dependent. Any transformations applied to
    the authenticated user name by the SSH layer are outside the scope
    of this document.

My reasoning is that any transformations really happen before the
NETCONF server even gets to see a user name, at least this was my
understanding when we discussed this in the WG meeting.

/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: "t.petch" <[email-masked]>
Date: Tue, 1 Mar 2011 17:46:07 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Cc: "Netconf" <[email-masked]>
Sent: Tuesday, March 01, 2011 6:15 PM
> understanding when we discussed this in the WG meeting.

I prefer Juergen's formulation, especially as it gets rid of
'SSH identity' which I think wrong.

Tom Petch

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Phil Shafer <[email-masked]>
Date: Tue, 1 Mar 2011 14:45:38 -0500

>username associated with a session, allowing "user@host" style naming,

The idea of "user@host" is completely local to the client.  The SSH
server has no clue that this is going on.  I'm a bit shocked that
this is an issue for SNMP, but admittedly haven't read 5592.

>"implementation-dependent" explanations seems woefully inadequate.

Sure, but it is the truth.  That's definitely worth something ;^)

In particular, the interesting case is the use of RADIUS to accept
a user name (and password) but to return (to the SSH server) a
distinct "local" user name that is used for local privs.

For example, I can say "ssh test@junos" and the JUNOS box will
be presented with the user name "test" (having no clue that I am
really "phil", as mentioned above).  The SSH server then presents
this user name ("test") to the RADIUS server for authentication.
The RADIUS server can return the local user "operator", which is
the account present in /etc/master.passwd (where "test" need not
be present in /etc/master.passwd).  At this point, I am permitted
to login as "operator".

The behavior of the system toward the original user name ("test")
is completely dependent on the SSH/RADIUS/login/PAM/etc implementation.

In a unix-based system, the original user name is returned by
getlogin(), but this is not something we are looking to standardize.
In other systems, the entire idea of "users" is not defined.  You
get only a "Password:" prompt for a normal login, and the SSH server
implementation completely ignores the user name.  On others, you
can use RADIUS, but all users are mapped to a single local user,
regardless of what RADIUS returns.

I'm not sure what text changes are needed, but the brutal truth
remains that the behavior toward the original user name is
implementation dependent.

Thanks,
 Phil

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 03 Mar 2011 09:16:15 -0800

>>>>> On Tue, 1 Mar 2011 14:45:38 -0500, Phil Shafer <[email-masked]> said:

PS> The idea of "user@host" is completely local to the client.  The SSH
PS> server has no clue that this is going on.  I'm a bit shocked that
PS> this is an issue for SNMP, but admittedly haven't read 5592.

Don't worry Phil, you don't need to read it.  It's a client side
specifier only in 5592 for how to specify a connection to a remote server.
-- 
Wes Hardaker
Cobham Analytic Solutions