Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT)

"Bert (IETF) Wijnen" <bertietf@bwijnen.net> Tue, 15 March 2011 09:37 UTC

Return-Path: <bertietf@bwijnen.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18BAD3A6C5B; Tue, 15 Mar 2011 02:37:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.535
X-Spam-Level:
X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tz4C6pOmt+Wr; Tue, 15 Mar 2011 02:37:46 -0700 (PDT)
Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 17D243A6C4D; Tue, 15 Mar 2011 02:37:45 -0700 (PDT)
Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <bertietf@bwijnen.net>) id 1PzQiX-0006u4-Gb; Tue, 15 Mar 2011 10:39:07 +0100
Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from <bertietf@bwijnen.net>) id 1PzQiX-0006o5-4f; Tue, 15 Mar 2011 10:39:05 +0100
Message-ID: <4D7F33B8.10209@bwijnen.net>
Date: Tue, 15 Mar 2011 10:39:04 +0100
From: "Bert (IETF) Wijnen" <bertietf@bwijnen.net>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8
MIME-Version: 1.0
To: David Harrington <ietfdbh@comcast.net>
References: <20110301230555.15990.2719.idtracker@localhost>
In-Reply-To: <20110301230555.15990.2719.idtracker@localhost>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd439f10eb9968d39f4befda78fe62bf70f
Cc: netconf <netconf@ietf.org>, The IESG <iesg@ietf.org>, netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org
Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2011 09:37:48 -0000

David,

as you do know I think (at least my memory says that you were
in the NETCONF session where this was discussed), the WG
has extensively discussed the issue of "how to derive/extract
the username from the SSH layer". We then had major consensus
(not full consensus, I believe you indeed objected somewhat)
that "implementation dependent" was the way to go.

Over the last few weeks, the WG has also discussed your DISCUSS,
and yet more people have expressed that "implementation dependent"
is the best we can do in this situation.

If anything needs to be done, then it seems that SSH needs to
be "fixed". See wg email thread extracts below.

However, we have tried to address your DISCUSS with the
following text changes, so that at least at the NETCONF
level we do as much as we can.

PLEASE reconsider your DISCUSS and see if you can clear it
with the following changes that have been posted in new
revisions of the 4741bis and 4742bis documents:

For 4741bis, add one sentence and change "MUST explain how" into
"MUST provide". Exact change:

OLD:

    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.

NEW:

    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 username is a string of characters that match
    the "Char" production from section 2.2 of [W3C.REC-xml-20001006] .
    The algorithm used to derive the username is transport protocol
    specific and in addition specific to the authentication mechanism
    used by the transport protocol.  The transport protocol MUST provide
    a username to be used by the other NETCONF layers.


for rfc4742bis, the proposed change is:

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

NEW:
     The username provided by the SSH implementation will be made
available to the NETCONF message layer as the NETCONF username
without modification. If the username does not comply to the NETCONF
requirements on usernames [I-D.ietf-netconf-4741bis] , i.e., the
username is not representable in XML, the SSH session MUST be
dropped. Any transformations applied to the authenticated identity
of the SSH client made by the SSH server (e.g., via authentication
services or mappings to system accounts) are outside the scope of
this document.


We have also addressed your other discuss points and most of your remarks/comments.
The complete diffs are here:
http://tools.ietf.org/wg/netconf/draft-ietf-netconf-4741bis/draft-ietf-netconf-4741bis-10-from-09.diff.html
http://tools.ietf.org/wg/netconf/draft-ietf-netconf-rfc4742bis/draft-ietf-netconf-rfc4742bis-08-from-07.diff.html

Bert Wijnen
Document shepherd 4741bis
Mehmet Ersue
Document shepherd 4742bis

-------- Original Message --------
Subject: 	Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT)
Date: 	Thu, 10 Mar 2011 11:01:41 -0800
From: 	Randy Presuhn <randy_presuhn@mindspring.com>
To: 	<netconf@ietf.org>



Hi -

>  From: "Juergen Schoenwaelder"<j.schoenwaelder@jacobs-university.de>
>  To: "Ersue, Mehmet (NSN - DE/Munich)"<mehmet.ersue@nsn.com>
>  Cc:<netconf@ietf.org>
>  Sent: Thursday, March 10, 2011 10:33 AM
>  Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT)
...
>  >  "How the NETCONF Server extracts the user name from the SSH layer is
>  >  implementation-dependent."
>  >
>  >  What SSH transport document could say is e.g. (but not much more):
>  >
>  >  "   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.
>  >
>  >      The user name provided by the SSH implementation will be made
>  >      available to NETCONF message layer as NETCONF username without
>  >      any modification. Any transformations applied to the authenticated
>  >      user name by the SSH layer are outside the scope of this document."
>  >
>  >  However this would be insufficient with the MUST statement in 4741bis
>  >  above. IMO 4741bis shouldn't impose to 4742bis something, which 4742bis
>  >  cannot provide

Let's get real.  Even though "implementation-dependent" isn't the most
satisfying way of describing how something happens, there are times
(and this is probably one) where it's the only reasonable way, unless
one is willing to accept that any effort to further specify matters will almost
inevitably end up over-constraining implementations.

...
>  I maintain the statement that a NETCONF transport that does not
>  provide a username is unacceptable - or we give up on access
>  control.

Agreed.  "Implementation-dependent" may be distasteful, but the
alternative of abandoning access control would be throwing the
baby out with the bathwater.

>   The issue is also not that SSH does not provide a username -
>  the issue is that documenting exactly how this is done without
>  restricting SSH authentication protocols and/or AAA systems is
>  difficult. Since the easy way forward of declaring this implementation
>  dependent does not seem to fly, someone has to cast creative text that
>  says a bit more than "this implementation dependent" without saying
>  too much. This is what we should discuss, not the MUST provide
>  username requirement in 4741bis.

I agree that the username requirement is not what should be
under discussion.  I reluctantly agree that if this group is unwilling to let
the implementation-dependent sleeping dog lie, the only alternative is
to spell out and get agreement on the "blessed" set of implementation-
dependent things that might be done to produce a username.  And I
strongly agree that that exercise will need to take care not to say too
much - an over-specification here could cause as much trouble as the
under-specification that caused the mess in the first place.

Randy

-----In a later email (dated 3/11/2011) Randy further stated:

There are apparently different expectations of what satisfies
a requirement to explain how something is done.  For me,
"it's implementation dependent" is a perfectly reasonable way
to address such a requirement when the realities of deployed
infrastructure don't permit a more detailed description.  Ugly?
Yes, but the alternative is to "fix" SSH, and that seems far
outside this group's charter.

Randy
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf