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

[Petr Spacek]

On 1.3.2013 15:39, Simo Sorce wrote:
> 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.

I agree. We could imitate krb5-self semantics:
Service part is hardcoded to 'host/' and REALM part is configurable:
'grant IPA.EXAMPLE.COM tcp-krb5-self;'

Variant for AD machines:
'grant AD.EXAMPLE.COM tcp-ms-self;'
AD variant will match names "machine$@AD.EXAMPLE.COM".

-- 
Petr^2 Spacek