URL issues

[Wes Hardaker <wjhns1@hardakers.net>]

There are a number of issues that relate to how the netconf protocol
deals with urls.

In the netconf protocol, the URL capability adds a powerful mechanism
allowing one protocol to stream information through the use of
another.  With power, of course, comes problems.

1) In the netconf protocol, authentication comes via the underlying
   transport.  This authentication could be provided in a number of
   ways, depending of course on the transport being used and the
   authentication mechanisms it can negotiate or make use of.  Many of
   the protocols and question smartly make use of credentials which
   are not forwarded to the netconf agent (public keys, proxy
   authentication protocols, or similar based technologies).  However,
   in the section which documents the URL capability there is no
   discussion of what authentication mechanism is used for the
   protocol defined by the URL to be used.  It is not clear whether
   the intent is that the credentials are forwarded when possible or
   if it is always expected that the connections are anonymous.
   Something resolving this question should be inserted into the document.

2) Many of these protocols (such as: http, ftp, ...) allow for the
   encoding of user names and passwords into the URL itself.  This is
   of course helpful to resolve the above issue, however it is also a
   problem when you have used a better form of authentication when
   talking to the agent during the netconf protocol, such as one which
   does not force the disclosure of the authentication information
   (passwords; eg, via the use of a public/private key technology) and
   suddenly the user is forced to disclose a different form of
   authentication information.  Although fundamentally this does not
   appear to be a huge issue, the problem comes when you are
   intentionally using a protocol that protects the user from having
   to disclose his credentials to a large number of devices, one of
   which may be compromised, and thus can be relatively sure that his
   credentials cannot be stolen by one compromise device to gain
   access to the remainder of the uncompromised devices.  This is,
   only a problem, when a non-anonymous usage is specified in the URL
   (IE, a user-name/password is included).

   The other half of this problem is when an operator believes he is
   sending his user name and password over a trusted transport,
   because he trusts the netconf protocol, but forgets that (or
   doesn't know that!) the transport for the operation in question
   will end up sending his credentials in clear text through the next
   protocol.  When an untrusted secondary protocol is used, it allows
   for server impersonation attacks.
   
3) In the case of anonymous URL protocol usage, you end up with either
   one of two cases:

   a) The connection transport for the protocol specified in the URL is
      a trusted transport the allows anonymous connections (https, eg).
      In this case, the validity of the server can be checked by the
      netconf agent.  But, the agent needs to first be configured to be
      told what acceptable remote identity is (such as the public key
      or ancestry key of the remote server when using the https
      protocol).

   b) The connection transport is also anonymous, such as raw http or
      raw ftp.  This is the worst scenario, as it allows for
      connections were important data is transferred that neither side
      is trusted by the other side.
   
4) Any netconf protocol operation that allows both the source and
   target to be set to (remote) URLs allows anyone with valid and
   authentication credentials to effectively copy files from one
   location to another and yet the logs on the source and target
   machines will make it look as if everything came and went to the
   netconf enabled machine rather than from the machine with a
   protocol operation was actually initiated.  This is primarily
   useful in situations where a user wants to hide the fact that he is
   done something and thus confuse the audit trail.  It is quite
   possibly completely bypasses any authorization checks in the
   netconf device,  Unless the future authorization model allows the
   specification of legitimate source and destination source and
   target parameters.  The most simple fix for this particular problem
   would be to simply specify that operations must always specify one
   local destination or source during a protocol operation.

   A similar problem is that some of the operations permit the use of
   URLs in a singular form.  delete-config could be used to hide the
   deletion of an important file on a remote machine, as 6.8.5.3 says
   that it is augmented to support URLs.  The intention, I'm sure, was
   only for the file: protocol token, but there is no limitation on
   what it'll accept.

Chaining multiple protocols together is extremely hard to be done
securely.  Heck, if you look at most other security Working Groups
you'll find that they're having a hard time doing it within their own
security protocols.  Welcome to the In.

summary fun: when considering the operations and the source and
target specifications within the netconf protocol, be sure to consider
issues that arise due to man in the middle attacks, server
impersonation attacks, credentials stealing attacks by compromised
devices and by sniffing of unsecured secondary protocols.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>