Kerberos authenticated dynamic update forwarding

[Mark Andrews]

GSS-TSIG requires a TKEY exchange to generate a TSIG key which is used to sign the UPDATE message.

Forwarding does not generally make sense with GSS-TSIG because to complete the TKEY exchange
the master and the client need to be able to communicate directly.  In theory you could send
a UPDATE to a slave and forward that *after* establishing the TSIG with the master directly.

named supports forwarding of TSIG and SIG(0) signed update messages.  The later requires this
fix on the forwarding server.

3961.   [bug]           Forwarding of SIG(0) signed UPDATE messages failed with
                        BADSIG.  [RT #37216]

The fix preserves the transaction ID when forwarding the SIG(0) signed message.

Mark

> On 4 Feb 2020, at 15:47, Matthew Davis <isc.org at virtual.drop.net> wrote:
> 
> Greetings.
> 
>    Please excuse this re-posting.  My initial messages was inadvertently marked as SPAM by my MTA.
>    I need some guidance on how configure dynamic dns updates forwarding when using tsig-gss (kerberos) authentication.  I have successfully setup tsig-gss authentication when updating the master directly.  I have the need to have the client send the update to a slave that then forwards the update to the master.
> 
>    The design is the master, slaves, and clients are all part of the same kerberos realm.  The master has a service keytab of DNS/<master.fqdn>@REALM defined for bind.  Each client  has the host keytab of host/<client.fqdn>@REALM.  On the slave I have tried 3 different service keytab combinations in for bind configuration.
> 
> 	• DNS/<slave.fqdn>@REALM only
> 	• DNS/<slave.fqdn>@REALM and DNS/<master.fqdn>@REALM
> 	• DNS/<master.fqdn at REALM> only
>   The clients can update their own records successfully when connecting directly with the master. With slave bind keytab only contain the its own service keytab, the client and slave will not exchange information.  When I added the master keytab entry on the slave, the slave attempts to forward the request to the master.  However the  update fails.  The logs on the slave indicate the following: 
> named[15934]: client <client.ip.address>#45780/key host/client.my.zone\@REALM: signer "host/client.my.zone\@REALM" approved
> named[15934]: client <client.ip.address>#45780/key host/client.my.zone\@REALM: forwarding update for zone 'my.zone/IN'
> named[15934]: zone my.zone/IN: forwarding dynamic update: unexpected response: master <master.ip.address>#53 returned: NOTAUTH
> 
> The master logs the following:
> named[17809]: client <slave.ip.addres>#48733: request has invalid signature: TSIG 1114672902.sig-<master.fqdn>: tsig verify failure (BADKEY)
> 
> 
> The update policy for the zone on the master is:
> 
> update-policy {
>         grant REALM krb5-self * SSHFP;
> };
> I suspect I simply do not have the correct keytab combinations.  I am unclear what the correct combination would be.
> -- 
> Matthew Davis
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org