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

["David Harrington" <[e-mail]>]

Hi Bert and others,

Wow, "mister harrington"????
Actually, I am not a participant in the WG. 
I haven't actually read any emails in this WG since last July.
I also don't think I've been present in a netconf meeting since at
least last July. 
I am subscribed to the ML, but I don't read it. If you think I should
unsubscribe, let me know and I will.

I have discussions about DISCUSSes re: many WG documents, but I do not
subscribe to all mailing lists, and seldom do those discussions happen
on the WG mailing lists. 
The discussions are held in emails addressed to the DISCUSS holder,
and the iesg list, usually by the document authors and/or shepherd,
and the secretariat is working to capture those DISCUSS discussions to
be archived.
and as far as I can tell, that is standard IESG procedure for
discussing DISCUSSes.
It is NOT standard IESG procedure to require ADs to subscribe and hold
discussions on WG mailing lists.
Just so you know.

But since you asked nicely, I'll respond here.

--- The DISCUSS for 4742bis ---

4741bis states 
" NETCONF transport protocols therefore MUST explain how a NETCONF
username is
   derived from the authentication mechanisms supported by the
transport
   protocol."

My concern was not how the "SSH user name" is obtained. It is fine to
me that that is implementation-dependent, since different netconf
transport implementations might choose different SSH implementations
to work with, and might choose different authentication methods, which
will result in different things being returned by the SSH
implementation.
But there is no explanation of how the ***netconf username*** is
derived from the ***SSH user name***.
As I see it from the text, the intention is that the netconf username
has a 1:1 mapping from the SSH user name.
Actually, I think that assumption may be incorrect, as we learned in
ISMS. 
IIRC, SSH is rather ambiguous about whether "user name" MUST contain a
value (e.g., when using GSSAPI)
I think your intent is that ***netconf username will contain whatever
the SSH implementation provides to the netconf transport
implementation***.
I am fine with that intention. But that explanation is not documented
in 4742bis.

--- The DISCUSS for 4741bis ---

I have concerns about whether the ***netconf username*** being
provided by the netconf transport layer to its upper layers is clearly
defined enough. It is unclear what the format is, what the character
set is, and whether the authentication service (e.g., SSH) is included
in what the netconf transport layer provides. 

and the concern is whether what is provided by the netconf transport
layer will meet the assumptions of operators.
What if, I as an implementer chose to provide a netconf username of
the following form?
"dbh<cr>
ssh<cr>
ssh-password algorithm<cr>
<<]]>>
<cr>
<cr>
<tab><tab><lf>
SSH user name = [e-mail]<cr>
"

would this be legal? according to 4741bis and 4742bis, it would appear
to be legal, because anything is acceptable ...
would it be useable by operators to, for example, specify an access
control policy?
or map it to existing native access controls?
would it be useable by operators to configure an access control policy
using netconf? or a CLI?
I fear it would not be.
But I think this would be perfectly legal according to the netconf
standard.
that's my concern.

So maybe 4741bis simply needs to say that since 4741bis defines no
constraints, anything is acceptable in a netconf username, so 4741bis
implementations MUST gracefully accept whatever is provided by the
transport layer as a netconf username.

I think it might be simpler to document the presumed constraints on
character set, control characters, etc.
But that is a WG choice. 
But whether the choice is to constrain the netconf username, or NOT
constrain it in any way, the choice should be documented so the
standard is clear and unambiguous about compliance requirements.

--- The DISCUSS for 4741bis ---

I have a concern that the netconf transport layer might not return the
nature of the authentication mechanism. This might be important to
other parts of the system, such as an access control system.
If the transport layer does not provide this, is it acceptable for an
access control system to violate "netconf layering" to go get that
information? will that information be available when an AC system is
determining permissions?
If so, it is unclear whether the Message layer is actually
transport-independent, as claimed in section 1.2.
and whether upper layers are transport-independent.
The layering diagrams don't really show where an access control system
would fit in the architecture.
My concern is whether upper layers have the information necessary to
identify the authenticated entity.
   o  user: The authenticated identity of the client.  The
authenticated
      identity of a client is commonly referred to as the NETCONF
      username.

section 2.2 says:
   The authentication process MUST result in an authenticated client
   identity whose permissions are known to the server. 
This text does not identify what types of permissions must be known to
the server.
Is this the native access control system that defines the permissions?
what types of permissions are you referring to? permission to
establish an SSH subsystem? open a netconf session? perform
edit-config operations? modify certain portions of the datastore? 
If "dbh" can be returned from two different transports, but represent
two different client identities, how can the server know the
associated permissions?
"whose permissions are known to the server" is really ambiguous.
I think the text is unclear about compliance requirements of the MUST.

Those are my concerns, and I don't see them addressed in the ML
discussions.

dbh

> -----Original Message-----
> From: Bert (IETF) Wijnen [mailto:[e-mail]] 
> Sent: Friday, March 04, 2011 3:42 AM
> To: David Harrington
> Cc: The IESG; [e-mail]; 
> [e-mail]; netconf
> Subject: Re: David Harrington's Discuss on 
> draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT)
> 
> More answers/comments from Juergen below.
> 
> Can I ask mister Harrington to participate in the discussion on the
> NETCONF WG mailing list? That is the only way to get to convergence
> in a reasonable amount of time. Dave, you ARE a particpant in the
WG,
> and I hope you can pay attention there till we reach agreement on
this
> DISCUSS. I hate to have to keep forarding yoru emails to the WG and
> then forward any WG technical responses back to you.
> That is not productive, and things may get lost in that path.
> 
> Thanks,
> Bert Wijnen
> Document shepherd
> 
> -------- Original Message --------
> Subject: 	Re: [Netconf] FW: David Harrington's Discuss on 
> draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT)
> Date: 	Thu, 3 Mar 2011 18:07:23 +0100
> From: 	Juergen Schoenwaelder 
> <[e-mail]>
> Reply-To: 	Juergen Schoenwaelder 
> <[e-mail]>
> To: 	Ersue, Mehmet (NSN - DE/Munich) <[e-mail]>
> CC: 	Netconf <[e-mail]>
> 
> 
> 
> On Thu, Mar 03, 2011 at 05:08:01PM +0100, Ersue, Mehmet (NSN 
> - DE/Munich) wrote:
> 
> >  Any comments? Pls also check the mail below from
> >  David Harrington.
> 
> [... stuff removed I figured out is not helpful to send ...]
> 
> NETCONF is the wrong place to constraint user name. For SSH, this is
> a no-brainer anyway.
> 
> /js
> 
> PS: We dealt with the uniquess questions explaining that this is an
>      ACM issue and note that it is even mentioned in the Security
>      Considerations section:
> 
>     [...] Second, it could be desirable to authorize based on
>     mechanisms available in the secure transport layer (SSH, 
> BEEP, etc).
> 
> PS: RFC 4252 says:
> 
>        byte      SSH_MSG_USERAUTH_REQUEST
>        string    user name in ISO-10646 UTF-8 encoding [RFC3629]
> 
>      RFC 4251 says:
> 
>     string
> 
>        Arbitrary length binary string.  Strings are allowed to
contain
>        arbitrary binary data, including null characters and 8-bit
>        characters.  They are stored as a uint32 containing its
length
>        (number of bytes that follow) and zero (= empty string) or
more
>        bytes that are the value of the string.  Terminating null
>        characters are not used.
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]<http://www.jacobs-university.de/>
> ______________________
> 
> 
> 
> 
> 
> On 3/2/11 12:05 AM, David Harrington wrote:
> > David Harrington has entered the following ballot position for
> > draft-ietf-netconf-4741bis-09: 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) should there be constraints on the basic format of 
> username? if it is expected to be specified by an operator in 
> config files or databases, should it be human-readable? ascii?
utf-8?
> >
> > 2) should the format be predictable, so the operator can 
> determine what the NC username will be, given a knowledge of 
> the corresponding identifier in the secure transport protocol?
> >
> > 3) commit MUST revert at 600 secs, but timeout is 
> configurable., what if somebody sets it to 700 seconds? MUST 
> it still revert at 600? Can a low timeout cause a denial of service?
> >
> >
> > 
>
----------------------------------------------------------------------
> > COMMENT:
> > 
>
----------------------------------------------------------------------
> >
> > 1) copyright in yang module needs updating.
> >
> > 2) appendix F doesn't mention dropping the local file 
> requirement for URLs,
> >
> > 3) terminology should probably define username, not user. 
> It is doubtful username is commonly referred, since it did 
> not exist in 1.0.
> >
> > 4) I found the use of RFC2119 laniguage rather 
> inconsistent. Some uses of "can" probbaly should have been 
> MAY. Some uses of "are" probbaly should have been MUST, to 
> ensure interoperability.
> >
> > 5) I support Lars' Discuss. There is no requirement to use 
> a transport protocol that provides congestion control. If a 
> transport is used that does not already provide congestion 
> control, then the NC transport should provide congestion 
> control. It is RECOMMENDED to use an existing transprt 
> standard that provides congestion control.
> >
> >
> >
> >
> 
>