[39441] in Kerberos
Re: one time password integration
daemon@ATHENA.MIT.EDU (Ken Hornstein via Kerberos)
Wed Jul 31 15:45:23 2024
Message-Id: <202407311944.46VJi3YK030487@hedwig.cmf.nrl.navy.mil>
To: Charles Hedrick <hedrick@rutgers.edu>
cc: "kerberos@mit.edu" <kerberos@mit.edu>
In-Reply-To: <PH0PR14MB5493673E648D14F5CEE0B7DFAAB12@PH0PR14MB5493.namprd14.prod.outlook.com>
MIME-Version: 1.0
Date: Wed, 31 Jul 2024 15:44:02 -0400
From: Ken Hornstein via Kerberos <kerberos@mit.edu>
Reply-To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
>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
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
