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: Wed, 2 Mar 2011 09:57:25 +0100

FYI

Cheers, 
Mehmet 

-----Original Message-----
From: ext David Harrington [mailto:[email-masked]] 
Sent: Wednesday, March 02, 2011 12:20 AM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: 'The IESG'; [email-masked]; 'ext
Romascanu, Dan (Dan)'; [email-masked]
Subject: RE: David Harrington's Discuss on
draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT)

Hi,

I just posted a DISCUSS againat 4741bis for a related issue. 

I think username needs to meet some constraints to make it usable for
the foreseeable uses, such as specifying an access policy for a
specific username. Compare tmSecurityName from RFC3411 and RFC5590,
which constrain the size, the character set, and the expected human
readability. The algorithm must also produce a predictable value for
use by human operators, given knowledge of the authentication
parameters.

I think there is also an issue of the uniqueness of username. If you
have multiple transports supported in a NC implementation, must the
usernames from, say, the SSH transport be unique only amongst the
usernames generated by the SSH transport, or does the username need to
also be unique across the TLS, SOAP, and BEEP transports as well? If
it will be used by an access control mechanism, it will be important
to know what parameters must be specified to uniquelyt identify a
"user", such as in VACM, where we need to know the securityname AND
the security model that generates the securityName.

As with RFC5592, I agree that how you convert the authenticated
identity from SSH depends on the SSH implementation, since the
identity used in SSH (and other protocols) can vary dramatically
depending on the underlying authentication mechanism.

The discuss for 4742bis is the total lack of the explanation REQUIRED
by 4741bis. 

dbh 

> -----Original Message-----
> From: Ersue, Mehmet (NSN - DE/Munich) [mailto:[email-masked]] 
> Sent: Tuesday, March 01, 2011 4:39 PM
> To: ext David Harrington
> Cc: The IESG; [email-masked]; 
> ext Romascanu, Dan (Dan); [email-masked]
> Subject: FW: David Harrington's Discuss on 
> draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT)
> 
> Hi Dave,
> 
> 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 
> we decided that the method to obtain the username for the NETCONF 
> Server from SSH should be implementation-dependant.
> 
> However, I agree that such an explanation is missing in the draft.
> 
> We discussed it again in the NETCONF ML and would like to suggest 
> following text change. 
> 
> 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.  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.
> 
> 
> Would this text be sufficient for you?
> 
> Thank you for your support.
> 
> Regards,
> Mehmet
> (document shepherd)
> 
> -----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: Wed, 2 Mar 2011 11:51:01 +0100

> use by human operators, given knowledge of the authentication

I very much disagree. tmSecurityName faces size constraints because
the SNMP notion of a securityName faces size restrictions and poses
SNMP specific constraints on the character set. NETCONF does not
suffer form this since it supports UTF8 and does not have string size
constraints due to table indexing constraints. It is thus much more
natural to use the security name as it is delivered by the secure
transport. This is how everybody is using SSH. Telling operators they
can't use all user names say SSH allows is simply a broken idea. With
SNMP, we had to do this because SNMP is have all these constraints.

I like to hear an operator telling us that the user name SSH delivers
is not predictable. There are tons of existing command line interfaces
for routers and bridges using SSH. They seem to work in practice. So
where is the problem?
 
> the security model that generates the securityName.

4741bis requires that a transport delivers a user name. Thats all and
similar to how things are done with secure transports in SNMP
land. Whether the ACM likes to scope the user name by the transport or
not is a issue of the ACM design, which is an open work item and out
of scope of 4741bis.

> The discuss for 4742bis is the total lack of the explanation REQUIRED

So you think the proposed new text (see below) is not sufficient?

>     server to determine a user name for the current session.  How the
>     therefore implementation-dependent. Any transformations applied to
>     the authenticated user name by the SSH layer are outside the scope
>     of this document.

I do not see what is missing.

/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: Phil Shafer <[email-masked]>
Date: Wed, 2 Mar 2011 10:41:09 -0500

Juergen Schoenwaelder writes:
>Telling operators they
>can't use all user names say SSH allows is simply a broken idea.

Amen.  Making legitimate SSH user names illegal in NETCONF will
mean that vendors choose between allowing their customers to continue
to use odd user names and to enforce the NETCONF constraint at a
cost to their customers.  That's an easy choice.  So many initial
NETCONF implementations will enforce these constraints until customers
complain, at which time the constraints will simply be removed.

This will definitely not help interoperability, deployment, or
happiness.  And it helps teach people to ignore the constraints in
the RFC, where they really do not need any help.

Thanks,
 Phil