From Newsgroup: comp.protocols.kerberos

On 7/31/24 14:22, Charles Hedrick via Kerberos wrote:

The comments suggest that with TCP if there isn't an answer within 10 sec, it then tries all servers.

This comment is outdated; I missed it when making the behavior changes. Starting in release 1.22, once a KDC accepts a connection, the client
will not initiate communications with other KDCs; it will wait
indefinitely or until the total request timeout for that KDC (and any previously contacted KDCs) to answer.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

We're looking at one time password integration (DUO). A while ago
changes were made to allow a longer timeout, since users may take a
while to respond to DUO requests. Since this isn't in a release yet, and
it takes years for new versions to show up on all of our systems, we
can't depend upon the changes now. But I'd like it to work in the long
run.

There's another issue beyond the timeout, and it's not clear to me that
the change takes it into account. Traditionally the client will talk to
all servers at the same time if it can't get to the initial kdc fairly >quickly. It's not obvious to me that this behavior changes with the new
code. The comments suggest that with TCP if there isn't an answer within
10 sec, it then tries all servers.

This could produce the effect of having several servers simultaneously
asking for DUO authentication, if the user doesn't respond within 10
sec. This is not a desirable result. I'm not entirely sure how this
should work, but my first inclination is to say that if a TCP connection >opens to the server, no other connection should be opened until the
timeout. At the timeout another server should be tried.

I want to preface this by saying I have no direct experience with Duo,
but we have used a number of OTP solutions with Kerberos over the years.
And out of curiousity I just took a look at the Duo API since it has
been brought up as a possible solution over the years.

I think the answer is going to be "it depends".

The normal way 2-factor works in Kerberos is that it's implemented
as a preauthentication mechanism. The KDC says, "preauth is required", provides a list of preauth mechanisms, the client picks one, and at
THAT point the second factor code is captured by the client and sent
to the KDC for verification. There is a general assumption that the
second factor verification happens quickly.

If you are using Duo with the "passcode" factor then this should be straightforward. However, if you are using Duo with a factor of "push"
or "phone", as you say it may take someone a bit to respond to that and
that may exceed the Kerberos message timeout and cause a fallover to
another KDC. We use to have this issue back when we used SecurID; the
old ACE server would hold onto a request for a second, which would cause
a failover, but a SECOND request for the same token sent by a replica
KDC to the ACE server would immediately return a "reject" code while
holding onto the first request for a second, so this caused us no end
of problems.

So, solutions? Well, one thing that pops out (but might be a fair
amount of code) is to write your own verification server that the
KDC talks to that sends the Duo requests, talks to the Duo servers
for you, and keeps tracks of requests and prevents multiple requests
from being sent to Duo if retries are encountered. I'm not sure
if there are better ideas but I would be interested in hearing
about them if there are.

I also see that Greg just said that as of 1.22 the client has much
better behavior for TCP connections, but that only helps if you ensure
that TCP is used for that connection. Is there a knob that says
you are only going to use TCP for preauth? If so, that would solve
that problem.

--Ken
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

One surprise in doing all of this is that there seems to be no standard >utility to let us see the auth indicator for the user's credentials. I'm >probably doing to use one of the test programs (adata). It seems to be >complicated by having the auth indicator in the encrypted part of the
ticket.

If you are using the GSSAPI to authenticate, there's a way (it's kind
of complicated and weird, like the rest of the GSSAPI). There's not a
native way to do that with the Kerberos API; on my list is to submit a
patch to MIT to expose the necessary API (there's a lot of things on
that list, so don't wait for me). However, if you're interested in
looking at authentication indicators in TGTs, I'm not sure there's a
way to verify the AD-CAMMAC container in a TGT; you'd need to look at
a service ticket (which I suppose you would already have if you were
verifying a Kerberos password).

--Ken
--- Synchronet 3.21d-Linux NewsLink 1.2