Re: [dane] DANE and client certificates (DANCE?)

From: Henry Story <henry.story@bblfish.net> · Date: Mon, 11 Jun 2012 18:14:33 +0200

On 11 Jun 2012, at 17:29, Janne Snabb wrote:

> Hi,
> 
> I looked at the current DANE specifications and drafts with my mail
> server admin hat on and was surprised to notice that there is nothing
> about client certificate validation.
> 
> Is this an intentional omission? Is it something that is postponed for
> later date?

Once you have Dane for server authentication it makes client authentication
with WebID even easier to deploy.

See the spec on the w3c at http://webid.info/spec/
You can also see the short video explaining how that works at http://webid.info/
And you can join the community at 
   http://www.w3.org/community/webid/

It is also possible to extend this for trust of issuers as I argued recently
in WebID and eCommerce:

   http://bblfish.net/blog/2012/04/30/

Henry

> 
> I tried to look through the mailing list archives, but did not find
> anything relevant. The DANE WG charter does not seem to be limited to
> server authentication, it just talks about authentication of "Named
> Entities" which in my mind can be both clients and servers. Obviously
> many people are only thinking about web site certificates and web browsers.
> 
> Looks like the current DANE specification could be called DANSE
> (DNS-based Authentication of Named _Server_ Entities). It could be
> relatively easily extended to cover client authentication (DANCE:
> DNS-based Authentication of Named _Client_ Entities). DANSE+DANCE could
> then be finally called DANE when merged together. :)
> 
> 
> I was thinking that something similar to the following could work:
> 
> 1. Mail server foo.example.com wants to send an e-mail to mail server
> bar.example.net using SMTP.
> 
> 2. foo.example.com opens a TCP connection to bar.example.net port 25 and
> issues STARTTLS. foo.example.com might verify the server certificate of
> bar.example.net with DAN(S)E or it might not.
> 
> 3. bar.example.net requests a client certificate in the TLS handshake.
> 
> 4. foo.example.com supplies a client certificate to certify that the
> SMTP connection really comes from it and not from someone who has
> hijacked their IP address.
> 
> 5. bar.example.net is configured to verify SMTP senders using DANCE. It
> performs the following DNS lookups and validations:
> A. reverse lookup the client IP address (returns foo.example.com)
> B. lookup A/AAAA records of foo.example.com and ensure that one of the
> returned IP addresses matches the IP of the incoming connection
> C. lookup TLSA records of _25._tcp._client.foo.example.com (the label
> "_client" could be something different, this is just an example)
> D. verify that one of the TLSA records matches the client certificate
> 
> (Lookups C and probably B need to be DNSSEC validated. Lookup A does not
> need to be DNSSEC validated.)
> 
> 6. At this point bar.example.net knows if foo.example.com authenticated
> with the correct certificate and can proceed accordingly depending on
> the local policies. It might reject the connection/e-mail if the client
> did not provide the correct certificate.
> 
> 
> This way a named client entity (typically a server of some sort, not a
> end-user workstation) could securely announce that when connecting to a
> well-known port at any other entity it shall authenticate using a
> specific client certificate (or a certificate signed by specific CA).
> 
> IMHO it seems pretty pointless to implement DANE for SMTP without the
> ability to verify both sides of the conversation.
> 
> Any thoughts?
> 
> -- 
> Janne Snabb / EPIPE Communications
> snabb@epipe.com - http://epipe.com/
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane

Social Web Architect
http://bblfish.net/