Subject: [dane] DANE client+server authentication

From: Ian Maddison <[email-masked]>
Date: Wed, 29 Jul 2015 00:42:52 +0200

I’m looking for a way to run a recursive name server on a public IP address restricted to pre-configured roaming clients.

Is, or will it be feasible to leverage DANE-TA to reliably authenticate both the clients and server in order to run this type of service ?

—
Ian Maddison

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 28 Jul 2015 23:46:46 +0000

On Wed, Jul 29, 2015 at 12:42:52AM +0200, Ian Maddison wrote:

> I'm looking for a way to run a recursive name server on a public IP address
> restricted to pre-configured roaming clients.
> 
> Is, or will it be feasible to leverage DANE-TA to reliably authenticate
> both the clients and server in order to run this type of service?

No, not possible.

And I am afraid this is not an end-user help/support forum, so this
type of question belongs elsewhere, e.g. the BIND or unbound users
list, or similar.

-- 
	Viktor.

---

From: Ian Maddison <[email-masked]>
Date: Wed, 29 Jul 2015 02:37:08 +0200

> On 29 Jul 2015, at 01:46, Viktor Dukhovni <[email-masked]> wrote:
> 

Oh ok, I'm sorry about that. 

Although I’ve followed this list for several years, improved readability for one of your drafts and helped fix an an error or two, it seems I may have missed details regarding client authentication and would appreciate a pointer, if that’s not too much to ask :)

---

From: Patrick Ben Koetter <[email-masked]>
Date: Wed, 29 Jul 2015 08:19:55 +0200

> Although I’ve followed this list for several years, improved readability for one of your drafts and helped fix an an error or two, it seems I may have missed details regarding client authentication…

There's no usable client authentication at the moment.
A first draft for client authentication has been published:

https://datatracker.ietf.org/doc/draft-huque-dane-client-cert/

AFAIK it has also been discussed at the recent IETF meeting.

That's all there is for the moment.

p@rick

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

---

From: Paul Wouters <[email-masked]>
Date: Wed, 29 Jul 2015 08:40:38 +0200

Configure an IPsec tunnel in the clients and run IPSec on the namespaces and block port 53 without IPSec. I actually presented a simple IKEv2 libreswan config to do song from android/iPhone 

Sent from my iPhone

> On Jul 29, 2015, at 00:42, Ian Maddison <[email-masked]> wrote:
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Ian Maddison <[email-masked]>
Date: Wed, 29 Jul 2015 10:39:16 +0200

> On 29 Jul 2015, at 08:19, Patrick Ben Koetter <[email-masked]> wrote:
> 

Thanks. Sorry, I should’ve been clearer, that’s the draft I had in mind, namely:

...3…

  Clients often have dynamic or unpredictable addresses, and may 
  move around the network, so tying their identity to network addresses
  is not feasible or wise.

   The client generates (or has generated for it) a private and public
   key pair, and a certificate binding the name to its public key.  This
   certificate has a corresponding TLSA record published in the DNS,
   which allows it to be authenticated directly via the DNS (using the
   DANE-TA or DANE-EE usage modes)...

...5…

   Hence, to address this issue generally, a client identity signaling
   solution will need to be devised, whereby the client indicates its
   DANE identity (i.e. its domain name identity and the fact that this
   identity has an associated TLSA record) to the server.  Application
   specific protocol enhancements are one way to achieve this, e.g. a
   new SMTP command.  A more general way would be to develop a new 
   TLS extension to convey this information.

   [Another internet draft is currently being written to define such a
   TLS extension to convey DANE client identity.]

…7…

   A TLS Client conforming to this specification MUST have a signed DNS
   TLSA record published corresponding to its DNS name and X.509
   certificate.  The client presents this certificate in the TLS
   handshake with the server.  The presented client certificate MUST
   have have the client’s DNS name specified either in the Subject
   Alternative Name extension’s dNSName type, or the SRVName type.

   Servers may have their own whitelisting and authorization rules for
   which certificates they accept.  For example a TLS server may be
   configured to only allow TLS sessions from clients with certificate
   identities within a specific domain or set of domains.

> That's all there is for the moment.

I’m hoping to hear more about this going forward.

---
Ian Maddison

---

From: William Stouder-Studenmund <[email-masked]>
Date: Tue, 28 Jul 2015 18:55:24 -0700

> On Jul 28, 2015, at 5:37 PM, Ian Maddison <[email-masked]> wrote:
> 
> 

The key issue I see is that you said “roaming” clients. DANE requires the cooperation of the system administrator and the operators of the DNS infrastructure. That’s great where the server administrators work with the local DNS operators, either as they are the same people or they work for the same company.

I would not trust DNS operators of “roaming” clients. I would not trust the DNS operators of a random cafe your clients are using for connectivity. I do not know of a good way for your clients to upload TLSA records each time the client gets an IP address nor would I really trust what a coffee company tried to tell me was the right certificate information for the client even IF it were plausible that the client provided it.

DANE is really great for telling a connecting agent security information about the system it is connecting to. That would be the client and server respectively.

I think the server should just require client certs in its TLS negotiation and decide if it likes or dislikes (trusts or doesn’t trust) the certificate it gets.

Take care,

Bill

---

From: Shumon Huque <[email-masked]>
Date: Wed, 29 Jul 2015 10:58:14 -0400

> Thanks. Sorry, I should’ve been clearer, that’s the draft I had in mind,

[...]

> I’m hoping to hear more about this going forward.
Yes, the draft was presented at the DANE working group meeting at IETF93 in
Prague last week. This is primarily geared towards client authentication
(via X.509 certificates or raw public keys) in TLS applications. It is
probably not a great fit for your originally mentioned use case of
authentication and access control at DNS recursive servers which don't
typically use TLS today. There are plans in the pipeline to do DNS over TLS
between stubs and recursive servers, but even then, there are
bootstrapping, circular dependency, and configuration challenges that might
not make this draft suitable for that case.

For client access control to a recursive server, for now I'd suggest
looking at other approaches, e.g. TSIG, IPsec, etc. If in an enterprise
environment with a central authentication system, GSS-TSIG might be an
option for scalable per-client authentication and access control. All of
this could run over TLS in the future for privacy protection.

That said, we're hoping to move the TLSA client certificates draft forward.
One thing I forgot to do at IETF is to ask the working group chairs to
gauge interest in adopting the draft. I will send a separate note about
that on list shortly.

Shumon Huque.