Query about tkey-gssapi-keytab and secure updates

Thu, 12 Nov 2020 14:58:40 -0800 

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@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@TEST.LOCAL
root@dns2:~ # kinit -k -t /usr/local/etc/namedb/working/keytab.krb5 DNS/dns2.test.local@TEST.LOCAL 
root@dns2:~ # klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: DNS/dns2.test.local@TEST.LOCAL_

Issued Expires Principal_
Nov 4 23:28:05 2020 Nov 5 09:28:03 2020 krbtgt/TEST.LOCAL@TEST.LOCAL
root@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@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@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@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@TEST.LOCAL kvno 3 in keytab (request ticket server DNS/dns2.test.local@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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to