MIME-Version: 1.0
In-Reply-To: <rt-3.8.6-32683-1374606367-1866.32879-5-0@isc.org>
References: <RT-Ticket-32879@isc.org> <514308A8.1070603@redhat.com> <rt-3.8.6-32683-1374606367-1866.32879-5-0@isc.org>
Message-ID: <51EF6F45.80207@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Organization: Red Hat
Subject: Re: [ISC-Bugs #32879] New update-policy match type proposal: authenticated PTR update
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
Date: Wed, 24 Jul 2013 08:08:05 +0200
To: bind-suggest@isc.org
Content-Transfer-Encoding: 7bit
From: Petr Spacek <pspacek@redhat.com>
RT-Message-ID: <rt-3.8.6-32174-1374646104-633.32879-0-0@isc.org>
Content-Length: 3934

Hello Evan,

it is still in my TODO list. At the moment, I work on support for DNSSEC in 
our own LDAP database driver for BIND9.

We contacted ISC regarding this LDAP driver in [ISC-Bugs #24733].
(Home page is https://fedorahosted.org/bind-dyndb-ldap/)

Update policy for authenticated changes to PTR records will be the next step. 
Are there some rough deadlines we have to meet for earliest possible inclusion 
in BIND9? I mean something like 'patches for upcoming releases are accepted 
till end of August, December, and then April'?

Thank you.

Petr Spacek

On 23.7.2013 21:06, Evan Hunt via RT wrote:
> Hello Petr,
>
> I never heard back from you about patches for this work.  Has any progress
> been made on it?  I still think it sounds like a useful idea.
>
> On Fri Mar 15 11:40:38 2013, pspacek@redhat.com wrote:
>> Hello,
>>
>> I would like to propose new match-type usable in BIND's update-policy
>> for
>> secure (authenticated and TCP-verified) PTR updates.
>>
>> The idea came from project FreeIPA (www.freeipa.org), sponsored by Red
>> Hat.
>>
>> Previous discussion about PTR record updates can be found in mailing
>> list archive:
>> https://www.redhat.com/archives/freeipa-devel/2013-March/msg00006.html
>>
>> Please let us know if you are interested in this functionality. We
>> could
>> contribute patches.
>>
>>
>> Current state - why we need a new type:
>> - With krb5-self and ms-self match-types it is possible to require
>> TSIG/GSSAPI
>> authentication, but it is not possible to use IP address of the signer
>> for
>> additional verification.
>> I.e. in the case where all hosts are allowed to update reverse zone,
>> single
>> compromised host can mess with whole reverse zone.
>>
>> - With tcp-self match-type it is possible to limit PTR record updates
>> in
>> reverse zone to names matching source IP address of the TCP
>> connection, but
>> request signature is ignored in that case.
>> E.g. any user logged to a machine can send update request and modify
>> PTR
>> record of the machine to arbitrary value.
>>
>>
>> Proposal:
>> Add new match-types tcp-krb5-self and tcp-ms-self for secure PTR
>> updates.
>> - Proposed match-types require same valid signature as krb5-self and
>> ms-self.
>> i.e. host/<hostname>@CONFIGURED.REALM and
>> <hostname>$@CONFIGURED.REALM.
>>
>> - Source IP address of the TCP connection have to exactly match
>> updated name
>> in the same way as for tcp-self.
>>
>> - New PTR data sent by client have to match host name in the
>> signature.
>>
>>
>> Example: A update request allowed by tcp-krb5-self:
>>
>> update-policy = 'grant EXAMPLE.COM tcp-krb5-self;'
>> source IP address = 192.0.2.1
>> Kerberos principal = host/client.example.com@EXAMPLE.COM
>> update request =
>>    update add 2.0.192.in-addr.arpa. 3600 IN PTR client.example.com
>>
>> Request above should be *denied* if:
>> - Source IP address doesn't match updated name (property of current
>> tcp-self
>> match-type). I.e. compromised host can mess only with record
>> associated to
>> it's actual IP address.
>>
>> - Signer's REALM doesn't match realm specified in update policy
>> (property of
>> current krb5-self match-type), i.e. hosts coming via cross-realm
>> trusts are
>> not allowed to update records if realm is not '*'.
>>
>> - New PTR data doesn't match signer's name, i.e. client.example.com is
>> not
>> allowed to update PTR record associated with it's IP address with data
>> like
>> secureserver.example.com.
>>
>> If we combine requirements above, one compromised host is able to mess
>> only
>> with PTR record associated with it's actual IP address and is not able
>> to
>> create record pointing to a fake name.
>>
>>
>> Record deletion is a problem, but we tend to allow client to delete
>> all PTR
>> records under name associated with it's IP address.
>>
>> Please let us know if you are interested in this functionality. We
>> could
>> contribute patches.


-- 
Petr^2 Spacek