Skip Menu |
 

From: Jochen Hein <jochen@jochen.org>
To: krb5-bugs@mit.edu
Subject: kinit fails for OTP users when using KdcProxy with both IPv4&6 DNS
Date: Wed, 19 Apr 2017 22:32:41 +0200
Download (untitled) / with headers
text/plain 9.5KiB

I'm running krb5-util 1.15 on Debian/Stretch and Ubuntu/Zesty. I'm
working to get my laptop running with KdcProxy, so I can authenticate
externally and use the ticket to access my VPN. I had this working some
weeks ago, but now it fails (probably since I've added IPv6 to my DynDNS
- at least that's my guess now after looking at the traces).

Here's a kinit-trace from a failed try:

Enter OTP Token Value:
[20855] 1492630771.827372: Preauth module otp (141) (real) returned: 0/Success
[20855] 1492630771.827403: Produced preauth for next request: 133, 142
[20855] 1492630771.827427: Encoding request body and padata into FAST request
[20855] 1492630771.827624: Sending request (1152 bytes) to EXAMPLE.ORG
[20855] 1492630771.827681: Resolving hostname freeipa1.example.org
[20855] 1492630771.839716: TLS certificate name matched "freeipa1.example.org"
[20855] 1492630771.843982: Sending HTTPS request to https fd23:e163:19f7:1234:5054:ff:fe85:ba0d:443
[20855] 1492630772.838077: TLS certificate name matched "freeipa1.example.org"
[20855] 1492630772.848431: Sending HTTPS request to https 192.168.30.121:443
[20855] 1492630772.860504: Received answer (0 bytes) from https 192.168.30.121:443
[20855] 1492630772.860538: Terminating TCP connection to https fd23:e163:19f7:1234:5054:ff:fe85:ba0d:443
[20855] 1492630772.860731: Terminating TCP connection to https 192.168.30.121:443
[20855] 1492630772.860926: Response was not from master KDC
[20855] 1492630772.860995: Processing preauth types: 136, 141, 133, 137
[20855] 1492630772.861009: Received cookie: MIT
[20855] 1492630772.861070: Retrying AS request with master KDC
[20855] 1492630772.861087: Getting initial credentials for jochen@EXAMPLE.ORG
[20855] 1492630772.861138: FAST armor ccache: FILE:/home/jochen/.byobu/krb5cc_1004
[20855] 1492630772.861383: Retrieving jkellner@EXAMPLE.ORG -> krb5_ccache_conf_data/fast_avail/krbtgt\/EXAMPLE.ORG\@EXAMPLE.ORG@X-CACHECONF: from FILE:/home/jochen/.byobu/krb5cc_1004 with result: 0/Success
[20855] 1492630772.861406: Read config in FILE:/home/jochen/.byobu/krb5cc_1004 for krbtgt/EXAMPLE.ORG@EXAMPLE.ORG: fast_avail: yes
[20855] 1492630772.861423: Using FAST due to armor ccache negotiation result
[20855] 1492630772.861476: Getting credentials jkellner@EXAMPLE.ORG -> krbtgt/EXAMPLE.ORG@EXAMPLE.ORG using ccache FILE:/home/jochen/.byobu/krb5cc_1004
[20855] 1492630772.861610: Retrieving jkellner@EXAMPLE.ORG -> krbtgt/EXAMPLE.ORG@EXAMPLE.ORG from FILE:/home/jochen/.byobu/krb5cc_1004 with result: 0/Success
[20855] 1492630772.861647: Armor ccache sesion key: aes256-cts/70B6
[20855] 1492630772.861716: Creating authenticator for jkellner@EXAMPLE.ORG -> krbtgt/EXAMPLE.ORG@EXAMPLE.ORG, seqnum 0, subkey aes256-cts/BEBB, session key aes256-cts/70B6
[20855] 1492630772.861883: FAST armor key: aes256-cts/3600
[20855] 1492630772.861931: Encoding request body and padata into FAST request
[20855] 1492630772.862073: Sending request (957 bytes) to EXAMPLE.ORG (master)
kinit: Generic preauthentication failure while getting initial credentials

Here we opened two connections to the KdcProxy, one with IPv4 and one
with IPv6. And since the OTP is probably already used by the first
connection, we finally fail. So, we should try one connection only -
the time between the first and second connect above is about a second.
This seems to be to short to get a valid answer.

If I use only one DNS record, e.g. IPv4, I get (a request seems to take
about two seconds - which looks reasonable: IPA -> ipa-otp -> radius ->
privacyidea):

Enter OTP Token Value:
[29898] 1492631435.928189: Preauth module otp (141) (real) returned: 0/Success
[29898] 1492631435.928218: Produced preauth for next request: 133, 142
[29898] 1492631435.928239: Encoding request body and padata into FAST request
[29898] 1492631435.928427: Sending request (1152 bytes) to EXAMPLE.ORG
[29898] 1492631435.928478: Resolving hostname freeipa1.example.org
[29898] 1492631435.949930: TLS certificate name matched "freeipa1.example.org"
[29898] 1492631435.974021: Sending HTTPS request to https 192.168.30.121:443
[29898] 1492631437.999513: Received answer (1001 bytes) from https 192.168.30.121:443
[29898] 1492631437.999551: Terminating TCP connection to https 192.168.30.121:443
[29898] 1492631437.999800: Response was not from master KDC
[29898] 1492631437.999871: Decoding FAST response
[29898] 1492631438.38: Processing preauth types: (empty)
[29898] 1492631438.62: Produced preauth for next request: (empty)
[29898] 1492631438.84: Salt derived from principal: EXAMPLE.ORGjochen
[29898] 1492631438.114: AS key determined by preauth: aes256-cts/5322
[29898] 1492631438.206: FAST reply key: aes256-cts/0473
[29898] 1492631438.314: Decrypted AS reply; session key is: aes256-cts/D560
[29898] 1492631438.370: FAST negotiation: available
[29898] 1492631438.418: Initializing FILE:/home/jochen/.byobu/krb5cc_1004 with default princ jochen@EXAMPLE.ORG
[29898] 1492631438.732: Storing jochen@EXAMPLE.ORG -> krbtgt/EXAMPLE.ORG@EXAMPLE.ORG in FILE:/home/jochen/.byobu/krb5cc_1004
[29898] 1492631438.887: Storing config in FILE:/home/jochen/.byobu/krb5cc_1004 for krbtgt/EXAMPLE.ORG@EXAMPLE.ORG: fast_avail: yes
[29898] 1492631438.965: Storing jochen@EXAMPLE.ORG -> krb5_ccache_conf_data/fast_avail/krbtgt\/EXAMPLE.ORG\@EXAMPLE.ORG@X-CACHECONF: in FILE:/home/jochen/.byobu/krb5cc_1004
[29898] 1492631438.1041: Storing config in FILE:/home/jochen/.byobu/krb5cc_1004 for krbtgt/EXAMPLE.ORG@EXAMPLE.ORG: pa_type: 141
[29898] 1492631438.1106: Storing jochen@EXAMPLE.ORG -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.ORG\@EXAMPLE.ORG@X-CACHECONF: in FILE:/home/jochen/.byobu/krb5cc_1004
Authenticated to Kerberos v5

My best guess right now is, that we add all IP addresses we resolve to
with add_connection(), and try all, but with OTP we shouldn't - at least
not without a longer timeout.

837 /* Add each address with the specified or preferred transport. */
838 retval = 0;
839 for (a = addrs; a != 0 && retval == 0; a = a->ai_next) {
840 retval = add_connection(conns, transport, defer, a, ind, realm,
841 entry->hostname, portbuf, entry->uri_path,
842 udpbufp);
843 }
844
845 /* For TCP_OR_UDP entries, add each address again with the non-preferred
846 * transport, unless we are avoiding UDP. Flag these as deferred. */
847 if (retval == 0 && entry->transport == TCP_OR_UDP && strategy != NO_UDP) {
848 transport = (strategy == UDP_FIRST) ? TCP : UDP;
849 for (a = addrs; a != 0 && retval == 0; a = a->ai_next) {
850 a->ai_socktype = socktype_for_transport(transport);
851 retval = add_connection(conns, transport, TRUE, a, ind, realm,
852 entry->hostname, portbuf,
853 entry->uri_path, udpbufp);
854 }
855 }

Maybe also related to the timeout handling in k5_sendto().

What is somewhat confusing for me is that a non-OTP user works fine and
is using only one connection (Ah, IPA delivers an answer quite fast, 0.1
seconds):

Password for jkellner@EXAMPLE.ORG:
[712] 1492631696.492223: Preauth module encrypted_challenge (138) (real) returned: 0/Success
[712] 1492631696.492251: Produced preauth for next request: 133, 138
[712] 1492631696.492273: Encoding request body and padata into FAST request
[712] 1492631696.492449: Sending request (1177 bytes) to EXAMPLE.ORG
[712] 1492631696.492498: Resolving hostname freeipa1.example.org
[712] 1492631696.501412: TLS certificate name matched "freeipa1.example.org"
[712] 1492631696.504821: Sending HTTPS request to https fd23:e163:19f7:1234:5054:ff:fe85:ba0d:443
[712] 1492631696.607254: Received answer (1038 bytes) from https fd23:e163:19f7:1234:5054:ff:fe85:ba0d:443
[712] 1492631696.607289: Terminating TCP connection to https fd23:e163:19f7:1234:5054:ff:fe85:ba0d:443
[712] 1492631696.607520: Response was not from master KDC
[712] 1492631696.607581: Decoding FAST response
[712] 1492631696.607758: Processing preauth types: 19, 138
[712] 1492631696.607780: Selected etype info: etype aes256-cts, salt "EXAMPLE.ORGjkellner", params ""
[712] 1492631696.607920: Preauth module encrypted_challenge (138) (real) returned: 0/Success
[712] 1492631696.607933: Produced preauth for next request: (empty)
[712] 1492631696.607954: AS key determined by preauth: aes256-cts/B73C
[712] 1492631696.608031: FAST reply key: aes256-cts/239E
[712] 1492631696.608129: Decrypted AS reply; session key is: aes256-cts/DC1E
[712] 1492631696.608183: FAST negotiation: available
[712] 1492631696.608223: Initializing FILE:/home/jochen/.byobu/krb5cc_1004 with default princ jkellner@EXAMPLE.ORG
[712] 1492631696.608521: Storing jkellner@EXAMPLE.ORG -> krbtgt/EXAMPLE.ORG@EXAMPLE.ORG in FILE:/home/jochen/.byobu/krb5cc_1004
[712] 1492631696.608638: Storing config in FILE:/home/jochen/.byobu/krb5cc_1004 for krbtgt/EXAMPLE.ORG@EXAMPLE.ORG: fast_avail: yes
[712] 1492631696.608702: Storing jkellner@EXAMPLE.ORG -> krb5_ccache_conf_data/fast_avail/krbtgt\/EXAMPLE.ORG\@EXAMPLE.ORG@X-CACHECONF: in FILE:/home/jochen/.byobu/krb5cc_1004
[712] 1492631696.608769: Storing config in FILE:/home/jochen/.byobu/krb5cc_1004 for krbtgt/EXAMPLE.ORG@EXAMPLE.ORG: pa_type: 138
[712] 1492631696.608825: Storing jkellner@EXAMPLE.ORG -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.ORG\@EXAMPLE.ORG@X-CACHECONF: in FILE:/home/jochen/.byobu/krb5cc_1004
Authenticated to Kerberos v5

What do you think is the best way to handle it? For now I could go back
to IPv4 only for DynDNS, but that's only a band-aid.

Jochen

--
This space is intentionally left blank.
For TCP connections (without a proxy), if the KDC accepts the
connection, we wait ten seconds before falling back to a different
server. Our intent was that this logic should also apply to TCP
connections using a proxy, but it doesn't (because
sendto_kdc.c:get_endtime() ignores connection state objects where state-
Show quoted text
>addr.transport != TCP). We can't fix that.

(For UDP, we have to retry pretty quickly because, unlike TCP, we get no
indication that the KDC is alive and listening and got our request until
it generates a response. So UDP is incompatible with this kind of OTP
deployment and there isn't really a good way around it without extending
the protocol.)
From: Jochen Hein <jochen@jochen.org>
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #8580] kinit fails for OTP users when using KdcProxy with both IPv4&6 DNS
Date: Thu, 20 Apr 2017 15:46:24 +0200
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.1KiB

Hello Greg,

"Greg Hudson via RT" <rt-comment@krbdev.mit.edu> writes:

Show quoted text
> For TCP connections (without a proxy), if the KDC accepts the
> connection, we wait ten seconds before falling back to a different
> server. Our intent was that this logic should also apply to TCP
> connections using a proxy, but it doesn't (because
> sendto_kdc.c:get_endtime() ignores connection state objects where state-
>>addr.transport != TCP).

That was what I hoped for, but, unfortunatly:

Show quoted text
> We can't fix that.

I've seen that HTTPS seems somewhat bolted on to the TCP transport, so I
hoped to get something similar going.

Show quoted text
> (For UDP, we have to retry pretty quickly because, unlike TCP, we get no
> indication that the KDC is alive and listening and got our request until
> it generates a response. So UDP is incompatible with this kind of OTP
> deployment and there isn't really a good way around it without extending
> the protocol.)

Do you see some solution on the horizon? If not, feel free to close the
ticket with "CANTFIX" or "WONTFIX". I'll try to find a configuration to
work around the limitations for me.

Thanks for your quick response.

Jochen

--
This space is intentionally left blank.
Oops, sorry for the typo--I meant to write "We can fix that." In fact,
I think it's a pretty trivial fix. I will submit a PR for it soon.
From: Jochen Hein <jochen@jochen.org>
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #8580] kinit fails for OTP users when using KdcProxy with both IPv4&6 DNS
Date: Thu, 20 Apr 2017 18:44:45 +0200
RT-Send-Cc:
"Greg Hudson via RT" <rt-comment@krbdev.mit.edu> writes:

Show quoted text
> Oops, sorry for the typo--I meant to write "We can fix that." In fact,
> I think it's a pretty trivial fix. I will submit a PR for it soon.

That's even better! Thanks again

Jochen

--
This space is intentionally left blank.
If you are able to test code changes, please try the one at https://github.com/krb5/krb5/pull/643 and see if it helps.
From: Jochen Hein <jochen@jochen.org>
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #8580] kinit fails for OTP users when using KdcProxy with both IPv4&6 DNS
Date: Thu, 20 Apr 2017 22:33:31 +0200
RT-Send-Cc:
"Greg Hudson via RT" <rt-comment@krbdev.mit.edu> writes:

Show quoted text
> If you are able to test code changes, please try the one at https://github.com/krb5/krb5/pull/643 and see if it helps.

I'll give it a try, but it may take some time.

--
This space is intentionally left blank.
From: Jochen Hein <jochen@jochen.org>
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #8580] kinit fails for OTP users when using KdcProxy with both IPv4&6 DNS
Date: Thu, 20 Apr 2017 22:52:29 +0200
RT-Send-Cc:
"Greg Hudson via RT" <rt-comment@krbdev.mit.edu> writes:

Show quoted text
> If you are able to test code changes, please try the one at
> https://github.com/krb5/krb5/pull/643 and see if it helps.

It works for me:

[23430] 1492721387.270350: Resolving hostname freeipa1.example.org
[23430] 1492721387.278388: TLS certificate name matched "freeipa1.example.org"
[23430] 1492721387.281845: Sending HTTPS request to https fd23:e163:19f7:1234:5054:ff:fe85:ba0d:443
[23430] 1492721391.257027: Received answer (1001 bytes) from https fd23:e163:19f7:1234:5054:ff:fe85:ba0d:443
[23430] 1492721391.257069: Terminating TCP connection to https fd23:e163:19f7:1234:5054:ff:fe85:ba0d:443
[23430] 1492721391.257381: Response was not from master KDC
[23430] 1492721391.257466: Decoding FAST response

Thanks!

--
This space is intentionally left blank.
From: ghudson@mit.edu
Subject: git commit

Apply TCP timeouts to HTTPS (KKDCP) transport

We apply (as of ticket #7604) a ten-second minimum delay after a TCP
connection is accepted before creating new connections or sending UDP
packets. Apply this timeout to HTTPS connections as well, by removing
the transport check in get_endtime(). As the endtime field is only
set by service_tcp_connect(), it will always have the value 0 for UDP
connection state objects, so there is no need to check the transport
type.

https://github.com/krb5/krb5/commit/aace82e17ed0185faa3e9cda5437a3c6a7a40b10
Author: Greg Hudson <ghudson@mit.edu>
Commit: aace82e17ed0185faa3e9cda5437a3c6a7a40b10
Branch: master
src/lib/krb5/os/sendto_kdc.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
From: ghudson@mit.edu
Subject: git commit

Apply TCP timeouts to HTTPS (KKDCP) transport

We apply (as of ticket #7604) a ten-second minimum delay after a TCP
connection is accepted before creating new connections or sending UDP
packets. Apply this timeout to HTTPS connections as well, by removing
the transport check in get_endtime(). As the endtime field is only
set by service_tcp_connect(), it will always have the value 0 for UDP
connection state objects, so there is no need to check the transport
type.

(cherry picked from commit aace82e17ed0185faa3e9cda5437a3c6a7a40b10)

https://github.com/krb5/krb5/commit/9a844b3f7206864d390cc35fc0cb4977684d7de2
Author: Greg Hudson <ghudson@mit.edu>
Commit: 9a844b3f7206864d390cc35fc0cb4977684d7de2
Branch: krb5-1.14
src/lib/krb5/os/sendto_kdc.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
From: ghudson@mit.edu
Subject: git commit

Apply TCP timeouts to HTTPS (KKDCP) transport

We apply (as of ticket #7604) a ten-second minimum delay after a TCP
connection is accepted before creating new connections or sending UDP
packets. Apply this timeout to HTTPS connections as well, by removing
the transport check in get_endtime(). As the endtime field is only
set by service_tcp_connect(), it will always have the value 0 for UDP
connection state objects, so there is no need to check the transport
type.

(cherry picked from commit aace82e17ed0185faa3e9cda5437a3c6a7a40b10)

https://github.com/krb5/krb5/commit/79669b0a6b50f04e98682584e06ddb5d97466ebc
Author: Greg Hudson <ghudson@mit.edu>
Commit: 79669b0a6b50f04e98682584e06ddb5d97466ebc
Branch: krb5-1.15
src/lib/krb5/os/sendto_kdc.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)