> On 29 Jul 2015, at 08:19, Patrick Ben Koetter <p...@sys4.de> wrote:
>
> 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/
>
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.
> AFAIK it has also been discussed at the recent IETF meeting.
>
> That's all there is for the moment.
I’m hoping to hear more about this going forward.
---
Ian Maddison
_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane
