Ted Lemon wrote on 08/06/2019 05:50:
On Jun 7, 2019, at 11:36 PM, Michael Richardson <[email protected]
<mailto:[email protected]>> wrote:
Can we use TLS for authorization, assuming that we have trusted
certificates
at both ends? Perhaps this is more of a: did anyone implement this?
How is trust established? Sure, doing TSIG over TLS is no problem.
Bootstrapping trust is always going to be an issue no matter what we do.
There can be multiple ways to bootstrap this, and multiple possible
providers pre-configured in the GUI.
Possible alternatives for further investigation:
1) something burned in at manufacturing time + trust between the
manufacturer and the DNS Outsourcing Infra provider.
An initial query from the HNA to the infra could include a proposed
domain name e.g. an AXFR or SOA query for <hn-ULA>.example.com sent to
the DM together with SIG(0) signing of this name.
The signing could be done by a private key held at the manufacturer.
SIG(0) doesn't protect the wrapper, only the query data, so the query
can be signed in advance off-line before anything like the homenet IP
address is known.
The DNS outsourcing infra can check this signature either using an
associated public key that is hosted on the manufacturer's DNS in a
pre-agreed location. e.g. homenet-keys.manufacturer.com. Or the
manufacturer could pre-share this public key with the DNS outsourcing
provider out of band.
2) Out of band sign up using a public/private key held at the DNS
outsourcing service provider at service sign up time (https + credit
card + CGI script on the service provider's web site -> delegated domain
name + SIG(0) signed delegated domain name query on the HNA for the
initial query to the DM). The DM only needs to know the current valid
public keys used for the SIG(0), and the private key and credit card
details can be held elsewhere and regularly rotated.
3) Trust based on the TLS + certificate chain, rather than anything at
the DNS application level. Currently very much hand waving on my part up
until now. I've seen DANE being able to validate TLS connections based
on a certificate chain (e.g. RFC 6698 DANE-TA(2) Trust anchor assertion,
with a common trust anchor like let's encrypt X3 root) and was thinking
we could leverage that somehow for mutual authentication, along with
perhaps DNS over HTTPS (RFC8484). On the DM end that could use standard
TLSA records published in the parent zone to validate the DM to the HNA.
In the other direction we'd have to somehow to process a certificate
from the HNA to identify the manufacturer or end user to the DM. But
that's a well-known problem in web server land.
Thoughts?
--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
