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.