Query about tkey-gssapi-keytab and secure updates
isc at sunnyday.sk
isc at sunnyday.sk
Thu Nov 12 22:57:10 UTC 2020
Hello all,
I send one more time my post as I realized that DMARC DNS record is not
friend for mailing lists
and failed to delivery for many domains.
I am trying to extend my understanding about tkey-gssapi-keytab
statement
and possibility to use multiple principal names in single keytab file
From documentation:
tkey-gssapi-keytab
This is the KRB5 keytab file to use for GSS-TSIG updates.
If this option is set and tkey-gssapi-credential is not set,
updates are allowed with any key matching a principal in the specified
keytab.
1. tkey-gssapi-keytab
Do I understand correctly that DNS server will allow any update after
received TKEY query matching Principal Name in my keytab file?
Is there any verification of client and client's signature?
I am not clear what would be usage if DNS server itself with not
perform any verification is GSS-TSIG signature
Below test show details that even with failed 'failed
gss_inquire_cred' - Secure updates is accepted
2. Does this support multiple Principal Names in single keytab file?
(I feel like should be the case, but I have unexpected result in my
test below
3. tkey-gssapi-credential
I understand that only with this parameter DNS server will
authenticate keys exchange in handshake
Does it imply that I can use only one Prinipal Name with GSS-TSIG?
I do not see that option can be defined multiple times
I understand that this parameter is not required anyway - [RT #22629]
4. Is there additional resources explaining overal GSS-TSIG handling?
Reading C-code is not really my cup of cofee.
===================================================================================================================
Our test plan:
Merging to MS AD environments to single ISC BIND DNS server with secure
updates using update-policy
For testing, I create two AD domains (no domain trust at all)
* test.local
* test1.local
During multiple testing, it looks like that using 'tkey-gssapi-keytab'
is not enough to verify properly secure updates
Let me details result of my example:
named.conf
options {
directory "/usr/local/etc/namedb/working";
listen-on {
"any";
};
pid-file "/var/run/named/pid";
tkey-gssapi-keytab "/usr/local/etc/namedb/working/keytab.krb5";
};_
zone "test.local" {
type master;
file "/usr/local/etc/namedb/master/test.local";
update-policy {
grant "TEST.LOCAL" ms-self "." "ANY";
};
auto-dnssec maintain;
};
zone "test1.local" {
type master;
file "/usr/local/etc/namedb/master/test1.local";
update-policy {
grant "TEST1.LOCAL" ms-self "." "ANY";
};
auto-dnssec maintain;
};
keytab file is loaded and I can get TGT from AD for TEST.LOCAL
root at dns2:~ # ktutil -k /usr/local/etc/namedb/working/keytab.krb5 list
/usr/local/etc/namedb/working/keytab.krb5:
Vno Type Principal Aliases
9 arcfour-hmac-md5 DNS/dns2.test.local at TEST.LOCAL
root at dns2:~ # kinit -k -t /usr/local/etc/namedb/working/keytab.krb5
DNS/dns2.test.local at TEST.LOCAL
root at dns2:~ # klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: DNS/dns2.test.local at TEST.LOCAL_
Issued Expires Principal_
Nov 4 23:28:05 2020 Nov 5 09:28:03 2020 krbtgt/TEST.LOCAL at TEST.LOCAL
root at dns2:~ #
Possible challenge I see is that BIND does not use keytab file to
compare GSS request with keytab;
I can see on debug 8 gss messages with failure 'No No kerberos
credential available'
04-Nov-2020 23:29:04.945 client @0x803875000 10.0.110.207#61795
(612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): query:
612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592 IN TKEY -T
(10.0.50.33)m
04-Nov-2020 23:29:04.947 failed gss_inquire_cred: GSSAPI error: Major =
Unspecified GSS failure. Minor code may provide more information, Minor
= No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_0).
04-Nov-2020 23:29:04.950 gss-api source name (accept) is
AD207$@TEST.LOCAL
04-Nov-2020 23:29:04.951 process_gsstkey(): dns_tsigerror_noerror
04-Nov-2020 23:29:04.951 client @0x803875000 10.0.110.207#61795
(612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): send
04-Nov-2020 23:29:04.951 client @0x803875000 10.0.110.207#61795
(612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): sendto
04-Nov-2020 23:29:04.952 client @0x803875000 10.0.110.207#61795
(612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): senddone
04-Nov-2020 23:29:04.952 client @0x803875000 10.0.110.207#61795
(612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): next
04-Nov-2020 23:29:04.952 client @0x803875000 10.0.110.207#61795
(612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): endrequest
04-Nov-2020 23:29:04.952 client @0x803875000 10.0.110.207#61795:
closetcp
04-Nov-2020 23:29:04.953 client @0x804c11000 10.0.110.207#61795: next
04-Nov-2020 23:29:04.953 client @0x804c11000 10.0.110.207#61795: request
failed: end of file
04-Nov-2020 23:29:04.953 client @0x804c11000 10.0.110.207#61795:
endrequest
04-Nov-2020 23:29:04.953 client @0x804c11000 10.0.110.207#61795:
closetcp
04-Nov-2020 23:29:04.953 client @0x803bfa400 10.0.110.207#51833: UDP
request
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833: using
view '_default'
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833: request
has valid signature: AD207\$\@TEST.LOCAL
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key
AD207\$\@TEST.LOCAL: recursion available
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key
AD207\$\@TEST.LOCAL: update
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key
AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': prerequisites are OK
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key
AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': update section
prescan OK
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key
AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': deleting rrset at
'ad207.test.local' AAAA
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key
AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': deleting rrset at
'ad207.test.local' A
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key
AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': adding an RR at
'ad207.test.local' A 10.0.110.207
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key
AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': redundant request
but still update get in and is approved.
The same is accepted also for client from second domain - TEST1.LOCAL
Even I do not have keytab loaded with Principal Name from TEST1.LOCAL,
update will get in
04-Nov-2020 23:31:39.879 client @0x803875000 10.0.110.216#59439
(932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): query:
932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2 IN TKEY -T
(10.0.50.33)
04-Nov-2020 23:31:39.880 failed gss_inquire_cred: GSSAPI error: Major =
Unspecified GSS failure. Minor code may provide more information, Minor
= No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_0).
04-Nov-2020 23:31:39.884 gss-api source name (accept) is
AD206$@TEST1.LOCAL
04-Nov-2020 23:31:39.884 process_gsstkey(): dns_tsigerror_noerror
04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439
(932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): send
04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439
(932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): sendto
04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439
(932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): senddone
04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439
(932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): next
04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439
(932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): endrequest
04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439:
closetcp
04-Nov-2020 23:31:39.885 client @0x804811a00 10.0.110.216#59439: next
04-Nov-2020 23:31:39.885 client @0x804811a00 10.0.110.216#59439: request
failed: end of file
04-Nov-2020 23:31:39.885 client @0x804811a00 10.0.110.216#59439:
endrequest
04-Nov-2020 23:31:39.885 client @0x804811a00 10.0.110.216#59439:
closetcp
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407: UDP
request
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407: using
view '_default'
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407: request
has valid signature: AD206\$\@TEST1.LOCAL
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: recursion available
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: update
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': prerequisites are
OK
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': update section
prescan OK
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': deleting rrset at
'ad206.test1.local' AAAA
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': deleting rrset at
'ad206.test1.local' A
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': adding an RR at
'ad206.test1.local' A 10.0.110.206
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': adding an RR at
'ad206.test1.local' A 10.0.110.216
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': redundant request
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: send
This update was not expected to get accepted.
=======================================
I did modification of test to include tkey-gssapi-credential
where I got more expected result
tkey-gssapi-credential "DNS/dns2.test.local at TEST.LOCAL";
Update into main domain TEST.LOCAL shows sucessfull GSS
04-Nov-2020 23:35:12.167 client @0x803875000 10.0.110.207#60534: query
04-Nov-2020 23:35:12.167 client @0x803875000 10.0.110.207#60534
(612-ms-7.12-9a6b9d.7a3e8427-1ed6-11eb-438f-005056bd8592): query:
612-ms-7.12-9a6b9d.7a3e8427-1ed6-11eb-438f-005056bd8592 IN TKEY -T
(10.0.50.33)
04-Nov-2020 23:35:12.168 gss cred: "DNS/dns2.test.local at TEST.LOCAL",
GSS_C_ACCEPT, 4294967295
04-Nov-2020 23:35:12.170 gss-api source name (accept) is
AD207$@TEST.LOCAL
04-Nov-2020 23:35:12.170 process_gsstkey(): dns_tsigerror_noerror
with 2nd domain TEST1.LOCAL, ending in error
04-Nov-2020 23:36:07.223 client @0x804c11000 10.0.110.216#62340
(932-ms-7.53-192491b.2db42801-1eb9-11eb-d293-005056bddce2): query:
932-ms-7.53-192491b.2db42801-1eb9-11eb-d293-005056bddce2 IN TKEY -T
(10.0.50.33)
04-Nov-2020 23:36:07.224 gss cred: "DNS/dns2.test.local at TEST.LOCAL",
GSS_C_ACCEPT, 4294967295
04-Nov-2020 23:36:07.224 failed gss_accept_sec_context: GSSAPI error:
Major = Unspecified GSS failure. Minor code may provide more
information, Minor = Cannot find key for DNS/dns2.test.local at TEST.LOCAL
kvno 3 in keytab (request ticket server
DNS/dns2.test.local at TEST1.LOCAL).
04-Nov-2020 23:36:07.224 process_gsstkey(): dns_tsigerror_badkey
where I understood that I apply explicitly 1 'security credential' to
verify GSS;
Of course, update for TEST1.LOCAL is not valid for TEST.LOCAL Principal
name
Appreciate any feedback on this topic.
Best Regards,
Peter
More information about the bind-users
mailing list