Hi,I am aware this discussion have moved to uta (added to cc), but I do not have any thread there to respond yet. And I have idea dnsop people might want to comment about.
First issue is this should allow banning devices stolen to deny access into protected internal names. To make it possible, you need each device to identify separately and then have ability to ban such device, when its owner lost control for it. If you have identified just a group membership, then you would have to issue a new certs for all remaining machines in group. Does not seem better. If you use internal-only resolver like we do over VPN, they can identify you via IP address anyway. They would have just a better crypto proof of your identity. Does not matter on corporate network like ours, no anonymity reduced.
What I think should be contained in the proposal is ability to "remember" last authenticated user on the secure connection. We already have GSS-TSIG support (RFC 8945), which can provide ability of a machine to authenticate. Sure, normal GSS-TSIG is done per-message only, which would be inefficient on long lived TLS connection with many queries.
But what if we implemented storing last authenticated user/machine on the connection. Next message would not have to contain TKEY records again, because they are still part of protected channel already verified. Unlike plain UDP, we have secure way to connect it to previous authenticated message. It is somehow more complex and more complicated to deploy, but should be able to reuse existing implementation with minor changes. For example bind9 supports krb5 authentication already. If it could signal to client that all following queries would be considered signed with the same user as the first verified message, it may save following per-queries signing within the same channel. It would have to do the same again on a new connection, but not for each query, just the first.
It would be somehow tricky to setup, especially since DNS cannot be used to discover kerberos servers on zero trust machines. Because only authenticated connection to protective server can be used. It should be possible, even though not ideal.
Client certificates per machine is still a better idea and a better variant for the future. Especially for machines with TPM chip, which can store private key only in single protected place.
I am not sure, is it possible to authenticate (again) using client certificate on a TLS connection after another client cert were accepted already? TKEY allows changed authenticated user later, but I doubt it would be useful when machine principal were used. TKEY can distinguish between unauthenticated and authenticated, but should we care in a single connection?
Ideally, there should be some signalling from the server, notifying client it does not have to send TSIG signatures of following messages anymore. EDNS0 extension perhaps?
Opinions? Best Regards, Petr Menšík On 23/07/2024 19:51, Jessica Krynitsky wrote:
Hi Tiru,I agree, and the need to be able to enforce an organizational hierarchy was one of our early requirements as well. Our thinking was that with mTLS, the organization could naturally use PKI to represent this structure (although I will not pretend that OAuth cannot do this too). With client certificates authenticating over TLS, these certs can represent a client device rather than a user identity, and this is largely up to the implementer/organization/network owner to decide the details. We viewed token-based auth as more strongly tied to user identities, and potentially a higher barrier to entry for small organizations which may already have PKI and associated policies.Thanks! Jess
-- Petr Menšík Software Engineer, RHEL Red Hat,https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
