On Fri, Mar 08, 2019 at 02:55:40PM -0500, Viktor Dukhovni wrote:
> On Fri, Mar 08, 2019 at 12:43:18PM -0500, Michael Richardson wrote:
> > > [...]. Using DNS for SD in a
> > > widespread fashion only exacerbates the problem.
> >
> > It seems that you are arguing for a technology fix to a management problem.
> > (the "why we can't have nice things" lament comes to mind)
>
> Sometimes the management structure around a technology reflects the
> capabilities of the available tools.
And ofter software architecture reflects organization.
> When an the configuration data for a system such as an organization's
> DNS is managed as a single "configuration file" or as a datastore
> with very coarse-grained access control (permit or deny write access
> to all records), it is natural to erect a moat around the system
> to keep the marauding hoards at bay.
Typically the moat is a proxy that does implement appropriate access
control policy.
> When on the other hand, the datastore is designed with fine-grained
> access control, allowing self-service registration and delegated
> life-cycle management for individual data elements, the administrator
> responsibities shrink to just keeping the system running, and they
> no longer stand in the way of users managing their own data.
Indeed.
If only we had a reasonable and widely-used authorization system...
> The real problem we face is that there is no pervasive user
> authentication technology (some organizations have Kerberos, some
> PKI smartcards, some just username + password with a variety of
> backends) and then also no common way to manage authorization.
A few things:
1) _Naming_ is the most important thing.
It doesn't matter whether you use Kerberos or PKIX or whatever,
provided you can get useful, simple, usable names out of it. All the
better if you can support a common naming scheme across multiple
autheotcation systems.
Just say no to x.400/x.500-style naming. Kerberos gets it almost
right.
Of course, you can also have systems that convey authorization data
stripped of identifying information, but even then, you need to be
able to name things if not users.
2) There is no universal *user* authentication system, and this doesn't
look like it's going to get better anytime soon.
3) There's no universal authorization system. We do have things like
SAML and OAuth, which are built mostly for browsers and which at
least federate, but that's it.
Re: authentication, my theory is that we can leverage TLS and DANE to
authenticate not just services, but issuers of rfc822Name SAN bearing EE
certs to authenticate users, using the DNSSEC PKI. Such a system would
have instant federation via normal DNS(SEC) zone delegation/signing.
A DANE-based system for authenticating users would be no worse than the
WebPKI (which anyways isn't useful for authenticating users), and
probably better because DNSSEC is a proper hierarchical PKI. DNSSEC
does have all the issues that any PKI has (issuers can impersonate), but
it's still better than a system where federation has to be manually
agreed, like Kerberos. We'd still need something like certificate
transparency, naturally.
> Absent a common authentication and authorization substrate and a a
> datamodel that tracks fine-grained resource owners and supports
> self-service, unsurprisingly, we end up with centrally managed
> systems.
Worse: we end up with non-federation.
Users have to make myriad accounts authenticated with passwords, instead
of just a few (one for each of one's online personas) authenticated with
devices.
> To make alternative management structures possible for DNS, there
> needs to be a datastore that facilitates delegation of responsibility
> for particular nodes or RRsets. This has to integrate with whatever
> goes for authentication and authorization in the organization in
> question.
My proposal would be to take a page from labelled security systems and
have a _notional_ (but optionally real) label indicated by either a
"_label" RRset or a LABEL RR type whose RDATA names a label for
authorization. Such a label would be associated with rules/policies --
ACLs if you wish -- detailing who can do what with the domainname the
_label is prefixed to.
; Protects all things below foo.bar.example. that don't have their
; own label.
_label.foo.bar.example. IN TXT "foo_group_private_resources"
; Protects all things below host1.foo.bar.example. that don't have
; their own label. The "|parent_label_applies" means that that
; foo.bar.example.'s label also applies (i.e., a subject must be
; granted access by both authorization labels)
_label.host1.foo.bar.example. IN TXT "jane_user_resources|parent_label_applies"
> A few organizations invest in building such systems. Most organize
> around whatever tool comes from the DNS vendor, with DNS administration
> determined by the choice of Microsoft Active Directory, Infoblox,
> PowerDNS, BIND with flat-file zone data, ...
>
> The problem isn't DNS, it is that we lack a broadly applicable
> technology that most organizations can use to expose fine-grained
> access control for configuration data.
+1. But worse than that: *anything else* than DNS will tend to have the
same issues. LDAP, for example, has the same damned problems.
Thus, to say "DNS is too difficult to manage, let's build something
else", without addressing these issues, is bound to result in more of
the same.
It's so easy to reinvent wheels, and so hard to get rid of legacy. We
should at the very least understand the issues with the old wheels
before we discard them -- they're never really removed, only left to rot
and give us new old fun security vulnerabilities.
Nico
--
