[DNSOP] Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

[Petr Menšík <[e-mail]>]

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