Draft: draft-ietf-homenet-front-end-naming-delegation

Commentary: This clears up the IPsec references , adding a new section on provisioning that needs to be fleshed out . tracks this . This documents IPsec requirements ( needs API and transport mode ) and SIG(0 ) ( needs interface to OAUTH2 ) , settling for the onboarding process being a WebAPI , while the DNS transfer is IXFR / AXFR over DTLS . 
 Section 12 needs to be fleshed out . 
 OOps , I rewrote Privacy Considerations since that was section 12 .
The advantage of TLS/DTLS is that this technology is widely deployed,
and most of the devices already embed TLS/DTLS libraries, possibly
also taking advantage of hardware acceleration.  Further, TLS/DTLS
provides authentication facilities and can use certificates to
authenticate the DM and the HNA.  On the other hand, using TLS/DTLS
requires implementing DNS exchanges over TLS/DTLS, as well as a new
service port.  This document RECOMMENDS this option.
The HNA SHOULD authenticate inbound connections from the DM using
standard mechanisms, such as a public certificate with baked-in root
certificates on the HNA, or via DANE {!RFC6698}}.
IPsec RFC4301 IKEv2 RFC7296 MAY also be used to secure transactions
between the HNA and the DM.  Similarly to TLS/DTLS, most HNAs already
embed an IPsec stack, and IKEv2 supports multiple authentication
mechanisms via the EAP framework.  In addition, IPsec can be used to
protect DNS exchanges between the HNA and the DM without any
modifications of the DNS server or client.  DNS integration over
IPsec only requires an additional security policy in the Security
Policy Database (SPD).  One disadvantage of IPsec is that NATs and
firewall traversal may be problematic.  However, in our case, the HNA
is connected to the Internet, and IPsec communication between the HNA
and the DM should not be impacted by middle boxes.
How the PSK can be used by any of the TSIG, TLS/DTLS or IPsec
protocols: Authentication based on certificates implies a mutual
authentication and thus requires the HNA to manage a private key, a
public key, or certificates, as well as Certificate Authorities.
This adds complexity to the configuration especially on the HNA side.
For this reason, we RECOMMEND that the HNA MAY use PSK or certificate
based authentication, and that the DM MUST support PSK and
certificate based authentication.
The advantage of TLS/DTLS is that this technology is widely deployed,
and most of the devices already embed TLS/DTLS libraries, possibly
also taking advantage of hardware acceleration.  Further, TLS/DTLS
provides authentication facilities and can use certificates to
mutually authenticate the DM and HNA at the applicationlayer,
including available API.  On the other hand, using TLS/DTLS requires
implementing DNS exchanges over TLS/DTLS, as well as a new service
port.
The HNA SHOULD authenticate inbound connections from the DM using
standard mechanisms, such as a public certificate with baked-in root
certificates on the HNA, or via DANE {!RFC6698}}.  The HNA is
expected to be provisioned with a connection to the DM by the
manufacturer, or during some user-initiated onboarding process, see
hna-provisioning.
IPsec RFC4301 and IKEv2 RFC7296 were considered.  They would need to
operate in transport mode, and the authenticated end points would
need to be visible to the applications, and this is not commonly
available at the time of this writing.
A pure DNS solution using TSIG and/or SIG(0) to authenticate message
was also considered.  hna-provisioning envisions one mechanism would
involve the end user, with a browser, signing up to a service
provider, with a resulting OAUTH2 token to be provided to the HNA.  A
way to translate this OAUTH2 token from HTTPS web space to DNS SIG(0)
space seems overly problematic, and so the enrollment protocol using
web APIs was determined to be easier to implement at scale.
Note also that authentication of message exchanges between the HNA
and the DM SHOULD NOT use the external IP address of the HNA to index
the appropriate keys.  As detailed in sec-renumbering, the IP
addresses of the DM and the Hidden Primary are subject to change, for
example while the network is being renumbered.  This means that the
necessary keys to authenticate transaction SHOULD NOT be indexed
using the IP address, and SHOULD be resilient to IP address changes.
Note also that authentication of message exchanges between the HNA
and the DM SHOULD NOT use the external IP address of the HNA to index
the appropriate keys.  As detailed in sec-renumbering, the IP
addresses of the DM and the Hidden Primary are subject to change, for
example while the network is being renumbered.  This means that the
necessary keys to authenticate transaction SHOULD NOT be indexed
using the IP address, and SHOULD be resilient to IP address changes.
This should apply to any OAUTH2 token produced as envisioned by hna-
provisioning.
This section details what needs to be provisioned into the HNA and
serves as a requirements statement for mechanisms.
A number of deployment have been envisionned, this section aims at
providing a brief description.  The use cases are not limitatives and
this section is not normative.
A specific vendor with specific relations with a registrar or a
registry may sell a CPE that is provisioned with provisioned domain
name.  Such domain name does not need to be necessary human readable.
One possible way is that the vendor also provisions the HNA with a
private and public keys as well as a certificate.  Note that these
keys are not expected to be used for DNSSEC signing.  Instead these
keys are solely used by the HNA to proceed to the authentication.
Normally the keys should be necessary and sufficient to proceed to
the authentication.  The reason to combine the domain name and the
key is that outsourcing infrastructure are likely handle names better
than keys and that domain names might be used as a login which
enables the key to be regenerated.
When the home network owner plugs the CPE at home, the relation
between HNA and DM is expected to work out-of-the-box.
An CPE that is not preconfigured may also take advanatge to the
protocol defined in this document but some configuration steps will
be needed.
Either the registrar is also providing the outsourcing
infrastructure or the home network needs to create a specific
account on the outsourcing infrastructure.  * If the outsourcing
provider is the registrar, the outsourcing has by design a proof
of ownership of the domain name by the homenet owner.  In this
case, it is expected the infrastructure provides the necessary
parameters to the home network owner to configure the HNA.  A good
way to provide the parameters would be the home network be able to
copy/paste a JSON object.  What matters at that point is the
outsourcing infrastructure being able to generate authentication
credentials for the HNA to authenticate itself to the outsourcing
infrastructure.  This obviously requires the home network to
provide the public key gnerated by the HNA in a CSR.
If the outsourcing infrastructure is not the registrar, then the
proof of ownership needs to be established using protocols like
ACME for example that will end in the generation of a certificate.
ACME is used here to the purpose of automating the generation of
the certificate, the CA may be a specific CA or the outsourcing
infrastructure.  With that being done, the outsourcing
infrastructure has a roof of ownership and can proceed as above.
This section is not normative and intends to illustrate how the HNA
builds the Homenet Zone.
As depicted in fig-naming-arch, the Public Homenet Zone is hosted on
the Public Authoritative Server(s), whereas the Homenet Zone is
hosted on the HNA.  This section considers that the HNA builds the
zone that will be effectively published on the Public Authoritative
Server(s).  In other words "Homenet to Public Zone transformation" is
the identity also commonly designated as "no operation" (NOP).
In that case, the Homenet Zone should configure its Name Server RRset
(NS) and Start of Authority (SOA) with the values associated with the
Public Authoritative Server(s).  This is illustrated in fig-homenet-
zone. public.primary.example.net is the FQDN of the Public
Authoritative Server(s), and IP1, IP2, IP3, IP4 are the associated IP
addresses.  Then the HNA should add the additional new nodes that
enter the home network, remove those that should be removed, and sign
the Homenet Zone.
The SOA RRset is defined in RFC1033, RFC1035 and RFC2308.  This SOA
is specific, as it is used for the synchronization between the Hidden
Primary and the DM and published on the DNS Public Authoritative
Server(s)..
MNAME: indicates the primary.  In our case the zone is published
on the Public Authoritative Server(s), and its name MUST be
included.  If multiple Public Authoritative Server(s) are
involved, one of them MUST be chosen.  More specifically, the HNA
MUST NOT include the name of the Hidden Primary.
RNAME: indicates the email address to reach the administrator.
RFC2142 recommends using hostmaster@domain and replacing the '@'
sign by '.'.
REFRESH and RETRY: indicate respectively in seconds how often
secondaries need to check the primary, and the time between two
refresh when a refresh has failed.  Default values indicated by
RFC1033 are 3600 (1 hour) for refresh and 600 (10 minutes) for
retry.  This value might be too long for highly dynamic content.
However, the Public Authoritative Server(s) and the HNA are
expected to implement NOTIFY RFC1996.  So whilst shorter refresh
timers might increase the bandwidth usage for secondaries hosting
large number of zones, it will have little practical impact on the
elapsed time required to achieve synchronization between the
Outsourcing Infrastructure and the Hidden Master.  As a result,
the default values are acceptable.
EXPIRE: is the upper limit data SHOULD be kept in absence of
refresh.  The default value indicated by RFC1033 is 3600000
(approx. 42 days).  In home network architectures, the HNA
provides both the DNS synchronization and the access to the home
network.  This device may be plugged and unplugged by the end user
without notification, thus we recommend a long expiry timer.
MINIMUM: indicates the minimum TTL.  The default value indicated
by RFC1033 is 86400 (1 day).  For home network, this value MAY be
reduced, and 3600 (1 hour) seems more appropriate.
This section specifies the various parameters required by the HNA to
configure the naming architecture of this document.  This section is
informational, and is intended to clarify the information handled by
the HNA and the various settings to be done.
DM: The associated FQDNs or IP addresses of the DM.  IP addresses
are optional and the FQDN is sufficient.  To secure the binding
name and IP addresses, a DNSSEC exchange is required.  Otherwise,
the IP addresses should be entered manually.
Authentication data: Associated Data.  PSK only requires a single
argument.  If other authentication mechanisms based on
certificates are used, then HNA private keys, certificates and
certification authority should be specified.
Public Authoritative Server(s): The FQDN or IP addresses of the
Public Authoritative Server(s).  It MAY correspond to the data
that will be set in the NS RRsets and SOA of the Homenet Zone.  IP
addresses are optional and the FQDN is sufficient.  To secure the
binding between name and IP addresses, a DNSSEC exchange is
required.  Otherwise, the IP addresses should be entered manually.
Registered Homenet Domain: The domain name used to establish the
secure channel.  This name is used by the DM and the HNA for the
primary / secondary configuration as well as to index the NOTIFY
queries of the HNA when the HNA has been renumbered.
Setting the Homenet Zone requires the following information.
Registered Homenet Domain: The Domain Name of the zone.  Multiple
Registered Homenet Domains may be provided.  This will generate
the creation of multiple Public Homenet Zones.
Public Authoritative Server(s): The Public Authoritative Server(s)
associated with the Registered Homenet Domain.  Multiple Public
Authoritative Server(s) may be provided.