I'm obviously jumping into the middle of what appears to be an ongoing
discussion of the NETCONF over TLS work.
Let me say that in the ISMS work, in which SNMP Transport Models and
Transport Security Models are defined, the goal was to leverage existing AAA
infrastructures. One deployment barrier to SNMPv3 is that the configuration
of PSKs on each managed entity makes administration difficult. If the user
base for NETCONF is anything like the user base for SNMP, you may eventually
see the same objection.
Quoting from Section 1, Introduction, of RFC 4279:
Second, pre-shared keys may be more convenient from a key
management point of view. For instance, in closed environments
where the connections are mostly configured manually in advance,
it may be easier to configure a PSK than to use certificates.
Another case is when the parties already have a mechanism for
setting up a shared secret key, and that mechanism could be used
to "bootstrap" a key for authenticating a TLS connection.
The intended use case for TLS PKS authentication is "closed environments"
where manual configuration of PSKs is reasonable. This is similar to the
model for SNMP / USM.
In the ISMS work, we have made allusions to the fact that having a
centralized AAA database behind SNMP authentication has the benefit of
allowing that database of user identity to be common among multiple
purposes, including NETCONF. In enterprises, the AAA database may in fact
be a corporate "single sign-on" solution. I think the potential for
leveraging existing AAA infrastructures for use with NETCONF is something
that users will eventually require.
In order to effectively use RADIUS or other AAA for authentication (and
possibly for authorization), two properties need to apply:
(1) The only PSK (shared credential) that needs to be configured on the
managed entity is the shared secret used between the AAA client and the AAA
server.
(2) The form of user identity (e.g. username and password) that is required
of the user to access the managed entity is one that can be used within the
existing AAA authentication methods.
In order to accomplish (2) you can either restrict the form of credentials
to the existing set for the AAA protocol, or you can extend the existing
set.
While the current PSK authentication proposal for NETCONF over TLS is
technically sound, it is similar in its scaling properties to the USM
authentication mechanism for SNMPv3. I think it therefore inherits the same
deployment constraints. I believe this is what Eliot was talking about when
he says "...not having such an extension leads us towards an SNMPv3 problem
and a future ISMS analog".
So, what are the existing RADIUS authentication mechanisms?
(1) Username and Password (e.g. PAP)
(2) Username, Challenge and Digest (e.g. CHAP or MS-CHAP)
(3) EAP (supposedly restricted to the network access use case)
(4) HTTP Digest
While NETCONF relies
on the transport layer for the user authentication, we are forced to
provide a profile for using password within TLS "without" modifying
TLS (note that there are some expired IDs that propose using OTP and
passwords within TLS, e.g., draft-linn-otp-tls).
This is indeed a limitation. In the ISMS work for SNMP, we chose SSH as a
transport, rather than TLS, partly because network operators were already
routinely using SSH. Additionally, SSH integrates with Username and
Password authentication (among other methods).
Regarding the transformations, I guess the exact encoding with RADIUS
is implementation dependent. But I think RADIUS recommends UTF-8,
(doesn't it?).
That's simply a mechanism for supporting I18N for human readable strings
that are used in RADIUS.
If then it will be OK for the document when relying on
RFC4279 (the PSK identity, identity hint, and password are converted
to a character string, and then encoded to octets using UTF-8).
Well, you're still looking at adding a new authentication method, or at
least defining a new profile for adapted use of an existing one, to support
this form of credentials. I haven't looked at the details; this may not be
too onerous, from a protocol definition perspective.
The attractiveness of leveraging existing AAA infrastructure, however, is to
leverage *existing* AAA infrastructure, rather that requiring deployment of
an enhanced version. This leads to the strategy of re-using one of the
existing authentication methods, rather than inventing a new one.
Regards,
Dave Nelson