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
- [Netconf] Fwd: David Harrington's Discuss on draf… Bert (IETF) Wijnen
- Re: [Netconf] David Harrington's Discuss on draft… Bert (IETF) Wijnen
- Re: [Netconf] David Harrington's Discuss on draft… Bert (IETF) Wijnen
- Re: [Netconf] David Harrington's Discuss on draft… Juergen Schoenwaelder
- Re: [Netconf] David Harrington's Discuss on draft… Martin Bjorklund
- Re: [Netconf] David Harrington's Discuss on draft… Juergen Schoenwaelder
- Re: [Netconf] David Harrington's Discuss on draft… Martin Bjorklund
- Re: [Netconf] David Harrington's Discuss on draft… Juergen Schoenwaelder
- Re: [Netconf] David Harrington's Discuss on draft… David Harrington
- Re: [Netconf] David Harrington's Discuss on draft… Phil Shafer
- Re: [Netconf] David Harrington's Discuss on draft… Martin Bjorklund
- Re: [Netconf] David Harrington's Discuss on draft… Phil Shafer
- Re: [Netconf] David Harrington's Discuss on draft… Martin Bjorklund
- Re: [Netconf] David Harrington's Discuss on draft… Andy Bierman
- Re: [Netconf] David Harrington's Discuss ondraft-… Randy Presuhn
- Re: [Netconf] David Harrington's Discuss on draft… Juergen Schoenwaelder
- Re: [Netconf] David Harrington's Discuss ondraft-… Juergen Schoenwaelder
- Re: [Netconf] David Harrington's Discuss on draft… David Harrington
- Re: [Netconf] David Harrington's Discuss on draft… David Harrington
- Re: [Netconf] David Harrington's Discuss on draft… Martin Bjorklund
- Re: [Netconf] David Harrington's Discuss ondraft-… Randy Presuhn
- Re: [Netconf] David Harrington's Discuss ondraft-… Juergen Schoenwaelder
- Re: [Netconf] David Harrington's Discuss on draft… Ersue, Mehmet (NSN - DE/Munich)
- Re: [Netconf] David Harrington's Discuss on draft… Bert (IETF) Wijnen
- Re: [Netconf] David Harrington's Discuss on draft… Juergen Schoenwaelder
- Re: [Netconf] David Harrington's Discuss on draft… Ersue, Mehmet (NSN - DE/Munich)
- Re: [Netconf] David Harrington's Discuss on draft… Juergen Schoenwaelder
- Re: [Netconf] David Harrington's Discuss on draft… Andy Bierman
- Re: [Netconf] David Harrington's Discuss on draft… Randy Presuhn
- Re: [Netconf] David Harrington's Discuss on draft… Ersue, Mehmet (NSN - DE/Munich)
- Re: [Netconf] David Harrington's Discuss on draft… Martin Bjorklund
- Re: [Netconf] David Harrington's Discuss on draft… Phil Shafer
- Re: [Netconf] David Harrington's Discuss on draft… Martin Bjorklund
- Re: [Netconf] David Harrington's Discuss on draft… Phil Shafer
- Re: [Netconf] David Harrington's Discuss on draft… Martin Bjorklund
- Re: [Netconf] David Harrington's Discuss on draft… Phil Shafer
- Re: [Netconf] David Harrington's Discuss on draft… Randy Presuhn
- Re: [Netconf] David Harrington's Discuss on draft… Bert (IETF) Wijnen
- Re: [Netconf] David Harrington's Discuss on draft… Martin Bjorklund
- Re: [Netconf] David Harrington's Discuss on draft… Ersue, Mehmet (NSN - DE/Munich)
- Re: [Netconf] David Harrington's Discuss ondraft-… t.petch
- Re: [Netconf] David Harrington's Discuss on draft… Phil Shafer
- Re: [Netconf] David Harrington's Discuss on draft… Martin Bjorklund
- Re: [Netconf] David Harrington's Discuss on draft… Phil Shafer
- Re: [Netconf] David Harrington's Discuss on draft… David Harrington
- Re: [Netconf] David Harrington's Discuss on draft… Juergen Schoenwaelder
- Re: [Netconf] David Harrington's Discuss on draft… Bert (IETF) Wijnen
- Re: [Netconf] David Harrington's Discuss ondraft-… Ladislav Lhotka
- [Netconf] 4742bis RFC Editors notes WAS:RE: David… Ersue, Mehmet (NSN - DE/Munich)
- Re: [Netconf] David Harrington's Discuss ondraft-… Randy Presuhn
- Re: [Netconf] David Harrington's Discuss ondraft-… Martin Bjorklund
- Re: [Netconf] David Harrington's Discuss ondraft-… Randy Presuhn
- Re: [Netconf] David Harrington's Discuss ondraft-… Martin Bjorklund
- Re: [Netconf] David Harrington's Discuss ondraft-… Andy Bierman
- Re: [Netconf] David Harrington's Discuss ondraft-… Randy Presuhn
- Re: [Netconf] David Harrington's Discuss ondraft-… Ladislav Lhotka
- Re: [Netconf] David Harrington's Discuss ondraft-… Ladislav Lhotka
- Re: [Netconf] David Harrington's Discuss ondraft-… Bert (IETF) Wijnen
- Re: [Netconf] David Harrington's Discuss ondraft-… t.petch
- Re: [Netconf] David Harrington's Discuss ondraft-… Juergen Schoenwaelder
- Re: [Netconf] David Harrington's Discuss ondraft-… t.petch
- Re: [Netconf] David Harrington's Discuss ondraft-… Juergen Schoenwaelder
- Re: [Netconf] David Harrington's Discuss on draft… Wes Hardaker
- Re: [Netconf] David Harrington's Discuss on draft… Juergen Schoenwaelder
- Re: [Netconf] David Harrington's Discuss on draft… Ladislav Lhotka
- Re: [Netconf] David Harrington's Discuss ondraft-… Ersue, Mehmet (NSN - DE/Munich)
- Re: [Netconf] David Harrington's Discuss ondraft-… Martin Bjorklund
- [Netconf] draft-ietf-netconf-4741bis-10 is finish… Bert (IETF) Wijnen
- Re: [Netconf] David Harrington's Discuss on draft… Wes Hardaker
- Re: [Netconf] David Harrington's Discuss ondraft-… Wes Hardaker
- Re: [Netconf] David Harrington's Discuss ondraft-… t.petch
- Re: [Netconf] David Harrington's Discussondraft-i… Randy Presuhn
- Re: [Netconf] draft-ietf-netconf-4741bis-10 is fi… Bert (IETF) Wijnen