[Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT)

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

Hi All,

I assume this is the only remaining DISCUSS.

Any comments? Pls also check the mail below from 
David Harrington.

Mehmet 


-----Original Message-----
From: Ersue, Mehmet (NSN - DE/Munich) 
Sent: Thursday, March 03, 2011 5:04 PM
To: 'ext David Harrington'
Cc: [e-mail]; 'ext Romascanu, Dan
(Dan)'; [e-mail]; 'The IESG'
Subject: RE: David Harrington's Discuss on
draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT)

Hi David,

I think we need to differentiate between NETCONF message layer 
and transport layer.

I also think the SSH transport document should not define how 
a username should look like nor define any transformation 
algorithm from format A to format X.

SSH transport is kept simple for what it transports and does 
also not interpret any XML content.

SSH transport depends at the end on what it gets from underlying 
SSH implementation.

I believe to define any constraints on the username is more 
appropriate to do in the NETCONF base document rather than 
in 4742bis.

Cheers, 
Mehmet 


> -----Original Message-----
> From: ext David Harrington [mailto:[e-mail]]
> Sent: Thursday, March 03, 2011 4:33 PM
> To: Ersue, Mehmet (NSN - DE/Munich)
> Cc: [e-mail]; 'ext Romascanu, Dan
> (Dan)'; [e-mail]; 'The IESG'
> Subject: RE: David Harrington's Discuss on draft-ietf-netconf-
> rfc4742bis-07: (withDISCUSS and COMMENT)
> 
> Hi Mehmet,
> 
> this looks good as far as it goes.
> 
> However, this does not adress these issues:
> 
> 1) the username is used externally to netconf, e.g. in a config file
> for some access control method. username is not just used *inside*
> netconf. While the default for netconf is utf-8, and the "user name"
> field in SSH is utf-8, it is implementation-dependent what the SSH
> implementation provides to applications. It could be good to specify
> that netconf username MUST be utf-8, for interoperability reasons. If
> what the SSH implementation (for example) provides is not utf-8, then
> the netconf SSH-transport implementation SHOULD convert it to utf-8.
> If the SSH implementation provides an identity already in utf-8, this
> is a no-op.
> 
> 2) But the problem is bigger than just utf-8. the username is used
> externally to netconf, e.g. in a config file for some access control
> method. username is not just used *inside* netconf. At some point, you
> need to do comparisons between what the transport provides for an
> identity, and an access control database representation of identities.
> For example, from draft-ietf-netconf-access-control:
>   3.   Check all the <group> entries for ones that contain a <user-
>         name> entry that matches the user name for the session making
>         the request.  Add to these groups the set of groups provided
> by
>         the transport layer.
> 
> How will you define a matching algorithm that is interoperable across
> implementations? Does the match algorithm include internationalized
> names? control characters? How long is the username allowed to be? How
> large a buffer MUST be supported to handle whatever username is
> provided by a transport? What if an SSH implementation decides to
> simply pass the application a complete X509 certificate representing
> the identity - should netconf implementations be expected to handle
> that? Maybe you want to use the username in scripts; Must the
> characters in username be printable?
> 
> Since you are not specifying an access control mechanism at this
> point, you are relying on existing system access controls to work.
> Assuming a CLI-based approach, possibly with scripting and/or a config
> file, you proibably want username to be in a format that is likely to
> be acceptable to the existing mechanism (or future standardized
> mechanisms). I recommend some constraints (and I would be satisfied
> with RECOMMENDS/SHOULD).
> 
> By not specifying any constraints on username, you are forcing all
> other parts of the system that use username (including all future
> netconf access control standards) to deal with a completely wide-open
> set of requirements to accommodate whatever the SSH implementation
> gives you.
> 
> 3) You still haven't dealt with the uniqueness question. What if the
> SSH transport returns username="dbh" for David B Harrington, and the
> TLS transport returns username="dbh" for Dwight B Harrison? How will
> you accommodate both in an access control rule set?
> 
> dbh
> 
> > -----Original Message-----
> > From: Ersue, Mehmet (NSN - DE/Munich) [mailto:[e-mail]]
> > Sent: Thursday, March 03, 2011 7:11 AM
> > To: ext David Harrington
> > Cc: [e-mail]; ext
> > Romascanu, Dan (Dan); [e-mail]
> > Subject: RE: David Harrington's Discuss on
> > draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT)
> >
> > Hi David,
> >
> > we copied now following change to the RFC Editors note:
> >
> > See
> > https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc4742bis
> > /writeup/.
> >
> > Thanks & Regards,
> > Mehmet
> > (document shepherd)
> >
> >
> > 2. Section 3.
> >
> > 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.
> >
> >
> > Cheers,
> > Mehmet
> >
> >
> > > -----Original Message-----
> > > From: ext David Harrington [mailto:[e-mail]]
> > > Sent: Wednesday, March 02, 2011 12:20 AM
> > > To: Ersue, Mehmet (NSN - DE/Munich)
> > > Cc: 'The IESG'; [e-mail]; 'ext
> > > Romascanu, Dan (Dan)'; [e-mail]
> > > 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:[e-mail]]
> > > > Sent: Tuesday, March 01, 2011 4:39 PM
> > > > To: ext David Harrington
> > > > Cc: The IESG; [e-mail];
> > > > ext Romascanu, Dan (Dan); [e-mail]
> > > > 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:[e-mail]]
> > > > Sent: Monday, February 28, 2011 11:23 PM
> > > > To: The IESG
> > > > Cc: [e-mail];
> > > > [e-mail]
> > > > 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?
> > > >
> > > >
> > > >
> >
> >