[Freeipa-devel] DNS update mechanism: news about update authorization

[Simo Sorce]

On Fri, 2013-03-01 at 15:29 +0100, Petr Spacek wrote:
> Hello list,
> 
> we would like to share some news about DNS update mechanism:
> 
> - It is possible to allow particular principal to update all records in a zone.
> 
> - It is possible to allow clients to update own PTR records. PTR update can be 
> "authenticated and authorized" by source IP address of the TCP connection from 
> the client. E.g. client with IP address 192.0.2.31 is able to modify only PTR 
> record with name 31.0.2.192.in-addr.arpa., nothing else.
> 
> See examples in following how-to:
> http://freeipa.org/page/Dynamic_updates_with_GSS-TSIG#Dynamic_update_policy
> 
> 
> Simo pointed to fact that "TCP authenticated" update requests can be more 
> secure than current approach with "PTR synchronization" magic (done inside 
> bind-dyndb-ldap).
> 
> Unfortunately, it is not possible to combine TCP "authentication" with 
> GSS-TSIG signature. BIND's ACL check mechanism stops at first match, so it is 
> not possible to combine multiple requirements.
> 
> 'tcp-self' rule ignores request signature completely. Implementation of (TCP 
> && signed) requirement will require patching BIND. I don't like that idea, 
> because we will deviate from plain BIND docs and it will cause confusion.
> 
> We can propose a change and send patches to ISC. It should be possible to 
> implement new 'tcp-signed-self' mechanism with only few lines of code. The 
> question is how it should behave:
> 
> Is *any* signature enough? I.e. anybody with valid Kerberos ticket is allowed 
> to do tcp-self update?

Should be at least a host/ principal, otherwise a mere user could change
the PTR record, would be even better if we can match the fqdn int the
host/ principal to the content of the PTR record.

So if you sign with principal for host/foo.bar.baz and come from
10.11.22.33 then you can only create a PTR record of 10.11.22.33 ->
foo.bar.baz

> Should we implement configurable realm check? I.e. the update will be allowed 
> only if the update is signed by principal from specified Kerberos realm?

This too would be nice but not as important.

> How it should work with Kerberos trusts?

You would prevent principals from a trusted domain to update DNS
entries.
Checking for the REALM part should be optional. 

> Also, it should be possible to implement more strict check: Updated name in 
> reverse zone (e.g. 31.0.2.192.in-addr.arpa.) has to match client's IP address 
> and *at the same time* name stored to PTR record has to match name in client's 
> principal.
> 
> Example:
> - client's IP address: 192.0.2.31
> - client's principal: host/client.example.com at TRUSTED.EXAMPLE.COM

Yeah I should have read the whole message trough before starting
replying :-)

> This particular client is allowed only to add record:
> 31.0.2.192.in-addr.arpa. IN PTR client.example.com.
> 
> Question is how to authorize record deletion. I tend to allow all delete 
> operations for (reverse) name matching client's IP address.

Yes this would be ok, worst case the PTR is lost.
Again I would allow only by principals of the type host/* or maybe DNS/*
not from every principal.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York