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

[Petr Spacek]

On 1.3.2013 16:15, Petr Spacek wrote:
> 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".

News from ISC: Evan Hunt replied that ISC can include our patches with this 
functionality.

I created ticket covering this task:
https://fedorahosted.org/bind-dyndb-ldap/ticket/112

-- 
Petr^2 Spacek