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.
> 

--
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.