* Viktor Dukhovni <[email protected]>: > On Tue, May 13, 2014 at 08:17:27AM +0200, Olle E. Johansson wrote: > > > > Yes, but we likely can't specify the lookup keys in an application > > > neutral manner. Rather we can discuss the problem generally, and > > > allow individual application protocols to construct appropriate > > > keys. Still there could be some guidance on how to apply DANE to > > > TLS client identity (when the client identity can be mapped to a > > > suitable name in DNS). > > > > That is something that also applies to SIP, where we have an RFC > > about connection reuse in SIP/TLS. For server to server connections > > it is important to be able to verify a list of domains each side > > is authorized to use. Today we do this with a long list of domains in SAN, > > but since my DANE/SIP draft removes that list for server certificates, > > we are now in a situation where client certs use SAN and the server, > > if using DANE, does not. > > > > The question it then boils down to is how I verify an incoming connection > > from an IP address with a name. Maybe a DNSsec-secured reverse lookup > > is a starting point. What's the state of DNSsec in .arpa ? > > IP addresses are a terrible identity lookup key, they are often > dynamically assigned, and even when static often controlled by a > different organization than the one actually operating the host.
ACK > My thinking on client authentication with DANE is that it works > best when the client represents that is acting as or on behalf of > some domain, and when associated TLSA records are present (lookup > key TBD) authenticates the legitimacy of the client. > > For example, with SMTP, clients impute a hostname with EHLO: > > S: 220 s.example ESMTP > C: EHLO c.example > > the server might then perform a lookup (work-around: only if > "c.example IN A ?" returns a validated response, possibly > validated NXDOMAIN or empty): > > _clientauth.c.example. IN TLSA ? > > if this yields secure TLSA records, the server requires that the > client presents a matching certificate and infers a secure client > identity. Sidenote: Ask for client certificate only if TLSA is present? I like that. This would safe us interop errors from clients that can't handle being asked for a client certificate. p@rick > So for server-to-server, SIP the question I would ask is whether > the application protocol carries some sort of client domain assertion? > > If SIP is wrapped in SSL (no STARTTLS unlike SMTP, IMAP, ...) then > the server would always solicit client certs, just in-case, and > verify them once the client indicates its domain in the application > protocol. > > -- > Viktor. > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane -- [*] 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 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
