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 Spacek
Software engineer
Red Hat

Email: pspacek@redhat.com
Web: www.redhat.com
Tel.: +420 532 294 185