TKEY and zone transfer

[Kent Tong]

Hi,

I read that Bind9 supports using TKEY for zone transfers. However, I don't understand how the TKEY negotiation is triggered. In comparison, for dynamic updates, the update-policy will require Bind to determine the identity of the requester, but for zone transfer there is only a allow-transfer which takes an address_match_list only.

Any info? Thanks in advance!

--

Kent Tong

IT author and consultant, child education coach

[Mark Andrews]

In message <CAKs98dGEcc27tdg0+DtvOJbv...@mail.gmail.com>

, Kent Tong writes:
>
> Hi,
>
> I read that Bind9 supports using TKEY for zone transfers. However, I don't
> understand how the TKEY negotiation is triggered. In comparison, for
> dynamic updates, the update-policy will require Bind to determine the
> identity of the requester, but for zone transfer there is only a
> allow-transfer which takes an address_match_list only.

I think you mean TSIG rather than TKEY. Address match lists support
the use of keys.

address_match_list = address_match_list_element ;
[ address_match_list_element; ... ]
address_match_list_element = [ ! ] (ip_address [/length] | key key_id |
acl_name | { address_match_list } )

master:
key "mykey" { algorithm hmacmd5; secret "afasfasfasfasdfsad"; };

zone "example.net" {
type master;
allow-transfer { key mykey; };
file "example.net";
};

slave:
key "mykey" { algorithm hmacmd5; secret "afasfasfasfasdfsad"; };

zone "example.net" {
type slave;
file "example.net";
masters { 1.2.3.4 key mykey; };
};

Mark

> Any info? Thanks in advance!
>
> --
> Kent Tong
> IT author and consultant, child education coach
>

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

[Evan Hunt]

On Tue, Jan 29, 2013 at 04:22:07PM +0800, Kent Tong wrote:
> I read that Bind9 supports using TKEY for zone transfers. However, I don't
> understand how the TKEY negotiation is triggered.

Huh. That is much harder than it ought to be (a fact I hadn't realized
until now, as I'd never had occasion to look closely at this feature until
you asked your question). I've just put in a bug report suggesting we
improve it in a future release.

For now, this is the best I can do for you... though quite honestly, I
think this approach is probably more trouble than it's worth; if it were
me, I'd just use conventional TSIG until there've been some improvements.
But if you really want to use TKEY, here you go, this formula worked for
me:

There's a program in the BIND 9 test suite that you can adapt
to your purposes if you're comfortable with C programming --
bind9/bin/tests/system/tkey/keycreate.c (also keydelete.c for removing
keys after they've been created). You'll need to modify the code to use
port 53 instead of port 5300, and to use different key material (see
below).

First, you need to create a DH (diffie-hellman) key for your server:

$ dnssec-keygen -T KEY -a DH -b 768 -n HOST server
Kserver.+002+32204

Note the key ID (in this example 32204). Put the resulting .key
and .private files into named's working directory, and configure
named.conf to reference that key:

options {
...
tkey-domain "server";
tkey-dhkey "server" 32204;
};

Also, generate a TSIG key to use for the initial TKEY negotiation.
The simplest way to generate TSIG keys is with ddns-confgen:

$ ddns-confgen -q -a hmac-md5 -k tkeyinit
key "tkeyinit" {
algorithm hmac-md5;
secret "RzLQq6b1oBN1QveexTf76g==";
};

Add that key information to your named.conf.

You'll need to copy the name and secret into keycreate.c and keydelete.c:
these written to be test programs; the key material is hard-coded into them.

At this point, you can create a diffie-hellman key for the client, and use
it with keycreate to negotiate a TSIG key with the server:

$ dnssec-keygen -T KEY -a DH -b 768 -n HOST client
Kclient.+002+11382
$ keycreate Kclient.+002+11382 negotiated-key
Knegotiated-key.server.+157+19753
$ cat Knegotiated-key.server.+157+19753.key
negotiated-key.server. IN KEY 512 3 157 MlNODIuzTrNMgSLRCFB1Iw==

The key generated by keycreate can then be used on the client side
to sign transfer requests:

key negotiated-key.server {
algorithm hmac-md5;
secret "MlNODIuzTrNMgSLRCFB1Iw==";
};

zone example.com {
type slave;
masters { 1.2.3.4 key negotiated-key.server };
...
};

...and that should work as long as the server side was configured to allow
transfers using the *initial* TSIG key that was used to create the
negotiated key -- not the negotiated key itself:

zone example.com {
type master;
allow-transfer { key tkeyinit; };
...
};

The transfer request to the server will be signed with the key
negotiated-key.server, not with tkeyinit. The server will still
allow it, though, because tkeyinit is the parent key of
negotiated-key.server. (Note, however, that transfers will also
be allowed for any request signed with tkeyinit, or with any other
key that was negotiated using tkeyinit. I don't know whether there's
a way to make the server accept only one specific negotiated key.)

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

[Kent Tong]

Hi all,

On Wed, Jan 30, 2013 at 5:27 AM, Evan Hunt <ea...@isc.org> wrote: 

The key generated by keycreate can then be used on the client side
to sign transfer requests:

    key negotiated-key.server {
        algorithm hmac-md5;
        secret "MlNODIuzTrNMgSLRCFB1Iw==";
    };

Thanks for the kind and excellent replies! So, currently there is no way for the client to negotiate the key on-demand automatically?

 

    zone example.com {
        type slave;
        masters { 1.2.3.4 key negotiated-key.server };
        ...
    };

BTW, what is the difference between specifying the key in the "masters" setting and specifying the key in a server statement?

 

[Evan Hunt]

On Wed, Jan 30, 2013 at 11:14:04AM +0800, Kent Tong wrote:
> Thanks for the kind and excellent replies! So, currently there is no way
> for the client to negotiate the key on-demand automatically?

I don't see a way, no.

There's a partially-implemented feature where negotiated keys can be dumped
to a file when named shuts down and restored when the it's restarted, so
in principle you could negotiate a key with a server once, and then it
would keep the key as long as necessary. But currently this only works
with GSSAPI keys, I believe.

> > zone example.com {
> > type slave;
> > masters { 1.2.3.4 key negotiated-key.server };
> > ...
> > };
>
> BTW, what is the difference between specifying the key in the "masters"
> setting and specifying the key in a server statement?

If you put it in the masters list then you could use different keys for
different purposes when talking to the same server. If it's in a server
statement, then that server always gets the same key.

[Tony Finch]

Evan Hunt <ea...@isc.org> wrote:
>
> Also, generate a TSIG key to use for the initial TKEY negotiation.

I thought the point of TKEY was to upgrade from slow public key
authentication to fast secret key authentication, i.e. that you would
start off by authenticating the client with SIG(0).

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

[Evan Hunt]

> > Also, generate a TSIG key to use for the initial TKEY negotiation.
>
> I thought the point of TKEY was to upgrade from slow public key
> authentication to fast secret key authentication, i.e. that you would
> start off by authenticating the client with SIG(0).

TKEY should work with SIG(0), but I don't have any code to show you
that generates SIG(0)-signed TKEY requests -- keycreate.c in the test
suite uses TSIG, so I adapted the recipe to that.

(Unless some other DNS implementation provides a tool for this purpose?
If you know of one, please let me know.)