one time password integration

[Charles Hedrick]

Since it will take years for all of our systems to get the new kerberos, we're going to add duo explicitly. We use ansible, so we can update the pam configuration of all our systems pretty easily. We'll just add a pam call to our own code after the normal authentication. To avoid having to set up every system to talk to DUO, we'll have a simple service (probably running on the KDCs) that does it.

The script that calls this can decide whether or not to use DUO, which would be harder for KDC, since it doesn't have the data. E.g. We may not use DUO for connections that come from within our department, and we certainly won't use them if the user has already done an OTP authentication. (Staff will use that rather than DUO, so avoid having systems work depend upon an Internet service.)

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.

To be honest, after looking at the details, I'm not sure how useful doing DUO in the KDC would be. We don't want the user to have to do DUO for screen locks, and there are a number of other situations like that. The RADIUS callout is still useful, e.g. for using a University LDAP server for passwords so we don't have to give most users a separate password.

________________________________
From: Ken Hornstein <kenh at cmf.nrl.navy.mil>
Sent: Wednesday, July 31, 2024 3:44 PM
To: Charles Hedrick <hedrick at rutgers.edu>
Cc: kerberos at mit.edu <kerberos at mit.edu>
Subject: Re: one time password integration

>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