[Netconf] 4742bis RFC Editors notes WAS:RE: David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT)

["Ersue, Mehmet (NSN - DE/Munich)" <[e-mail]>]

Hi All,

unfortunately there are two bugs in 4742bis v08, which need 
to be added to the RFC Editors notes. I assume Dan will change 
the IESG write-up page soon.

Change 1:
======
Appendix A) from v07 got somehow deleted and needs to be 
added again.

Change 2:
======
The text in Section 3.1 contains MUST statements copied from
4741 and is inappropriate. As requested by Alexey we had 
changed the formulation but forgot to update the Write-up page.

--------------------------------------------------------------------

RFC Editors notes for draft-ietf-netconf-rfc4742bis-08.txt:

OLD (v08):
[empty]

NEW:
Appendix A. Changes from RFC 4742	 		
				
	This section lists major changes between this document and RFC
4742.			
				
	o Introduced the new Chunked Framing Mechanism to solve known

	security issues with the EOM framing.			
				
	o Extended text in Security Considerations, added text on EOM

	issues.			
				
	o Added examples to show new chunked encoding properly,
highlighted			
	the location of new lines.			
				
	o Stated that the extraction of the SSH user name by a NETCONF

	server is implementation-dependent.			
				
	o Changed use of the terms client/server, manager/agent to SSH

	client/server and NETCONF client/server.			
				
	o Consistently used the term operation, instead of command or

	message.			
				
	o Integrated previously-approved errata from			
	http://rfc-editor.org/errata_search.php?rfc=4742



3. Section 3.1.

OLD (v08):
   As specified in [I-D.ietf-netconf-4741bis] the NETCONF server MUST
   indicate its capabilities by sending an XML document containing a
   <hello> element as soon as the NETCONF session is established.  The
   NETCONF client can parse this message to determine which NETCONF
   capabilities are supported by the NETCONF server.

   As [I-D.ietf-netconf-4741bis] states the NETCONF client must also
   send an XML document containing a <hello> element to indicate the
   NETCONF client's capabilities to the NETCONF server.  The document
   containing the <hello> element MUST be the first XML document that
   the NETCONF client sends after the NETCONF session is established.

NEW:
   As specified in [I-D.ietf-netconf-4741bis] the NETCONF server
indicates its 
   capabilities by sending an XML document containing a <hello> element
as 
   soon as the NETCONF session is established.  The NETCONF client can
parse 
   this message to determine which NETCONF capabilities are supported by
the 
   NETCONF server.

   As [I-D.ietf-netconf-4741bis] further specifies, the NETCONF client
also 
   sends an XML document containing a <hello> element to indicate the
NETCONF 
   client's capabilities to the NETCONF server.  The document containing
the 
   <hello> element is the first XML document that the NETCONF client
sends 
   after the NETCONF session is established.

Cheers, 
Mehmet 



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of ext Bert (IETF) Wijnen
> Sent: Tuesday, March 15, 2011 10:39 AM
> To: David Harrington
> Cc: netconf; The IESG; [e-mail]; draft-ietf-
> [e-mail]
> Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-
> netconf-4741bis-09: (with DISCUSS and COMMENT)
> 
> 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 <[e-mail]>
> To: 	<[e-mail]>
> 
> 
> 
> Hi -
> 
> >  From: "Juergen Schoenwaelder"<[e-mail]>
> >  To: "Ersue, Mehmet (NSN - DE/Munich)"<[e-mail]>
> >  Cc:<[e-mail]>
> >  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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf