• 2FA with krb5

    From Dan Mahoney (Gushi)@21:1/5 to All on Wed Oct 6 14:01:04 2021
    All,

    We use Kerberos but NOT LDAP at the day job.

    We'd like to be able to leverage 2fa for some services (admins) and some services (ssh logins) but not have to pump a 2fa code into, say, our mail applications. Is there a way to make the acquisition of a TGT (for GSSAPI authentication) vs Password Authentication require 2fa?

    That's complication number one.

    Complication number 2 is something like "SecurID is *expensive* for a
    fairly small (<10) admin team."

    Is there any reasonable support for off-the-shelf TOTP or HOTP
    authenticators, i.e. google authenticator or whatnot? If so, is there
    support to have a user have *multiple* available authenticators, such that
    one can be expired and others not?

    Googling this all gets me a bunch of (some older, some newer articles
    about the varying states of SPAKE and the like), and...a whole bunch of
    ads now being shown for startups that want to do it differently but I'm
    SURE no way to integrate with this.

    The final problem, of course, is that if I make all my KDC's 2fa-aware on
    their own, there's no communication of double-use of a token, unless I centralize things, which breaks the purpose of having geo-diverse KDC's.
    I don't suppose the kerberos db replication mechanism has anything that
    can also share this state?

    This is all pie-in-the-sky stuff, but practical answers "just an FAQ" are
    hard to find.

    -Dan

    --

    --------Dan Mahoney--------
    Techie, Sysadmin, WebGeek
    Gushi on efnet/undernet IRC
    FB: fb.com/DanielMahoneyIV
    LI: linkedin.com/in/gushi
    Site: http://www.gushi.org
    ---------------------------

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ken Hornstein@21:1/5 to Dan Mahoney (Gushi) on Wed Oct 6 21:27:04 2021
    Copy: kerberos@mit.edu

    We'd like to be able to leverage 2fa for some services (admins) and some >services (ssh logins) but not have to pump a 2fa code into, say, our mail >applications. Is there a way to make the acquisition of a TGT (for GSSAPI >authentication) vs Password Authentication require 2fa?

    Yes (I'll explain more below).

    That's complication number one.

    Complication number 2 is something like "SecurID is *expensive* for a
    fairly small (<10) admin team."

    Yeah, tell me about it.

    Is there any reasonable support for off-the-shelf TOTP or HOTP >authenticators, i.e. google authenticator or whatnot? If so, is there >support to have a user have *multiple* available authenticators, such that >one can be expired and others not?

    There is not such a thing yet, AFAIK. It's something on my list to
    implement TOTP support (but, it's kinda far down). It's complicated
    (again, see below).

    Googling this all gets me a bunch of (some older, some newer articles
    about the varying states of SPAKE and the like), and...a whole bunch of
    ads now being shown for startups that want to do it differently but I'm
    SURE no way to integrate with this.

    The final problem, of course, is that if I make all my KDC's 2fa-aware on >their own, there's no communication of double-use of a token, unless I >centralize things, which breaks the purpose of having geo-diverse KDC's.
    I don't suppose the kerberos db replication mechanism has anything that
    can also share this state?

    This is all pie-in-the-sky stuff, but practical answers "just an FAQ" are >hard to find.

    So, I think I speak with some authority on this subject; I've been involved with some kind of 2FA with Kerberos for a ... couple of decades? Yikes,
    I feel old. Anyway, the super short summary is:

    - You can do it, but depending on exactly WHAT you want to do may
    involve writing some code. You've heard the expression, "With a big
    enough engine, you can make a barn door fly"? That applies here.
    - There are some architectural issues that makes this all complicated
    to deploy. I'll try to touch on those.

    The first question you need to answer is: what are your clients? This
    is important because which specific 2FA protocol you use depends on
    what clients you have. The 3 main protocols I am aware of are

    - SAM2 - this is the old protocol that we originally used waay back
    when we started (and we still use today for some factors). You can
    pretty much use any factor with it; we used SecurID, CryptoCARD,
    and today use YubiKey. The major disadvantage is it is only supported
    by MIT-based Kerberos clients. I did a small amount of the protocol
    work on SAM2 but for various complicated reasons it never resulted
    in a published RFC.

    - FAST. This is a newer protocol that provides a generic encrypted
    tunnel to send preauthentication messages over (these are called "FAST
    factors"). It's a more complicated protocol, but superior to SAM2;
    if it was around when we started we would have used it. It is supported
    by MIT and Heimdal; it may be supported by Windows, I am not sure.
    There is already a FAST factor defined for One-Time Passwords, called
    "OTP". I am not sure of the client coverage of the OTP FAST
    factor, though. I will admit that I do not know as much about FAST as
    the other mechanisms, so if people chime in and correct me you should
    believe them over me.

    - PKINIT. This uses an existing PKI to completely replace a password. I
    mention this as 2FA since in our deployment we use client certificates
    on smartcards which require PINs to unlock, hence the two factors.
    This is supported by all 3 major Kerberos implementations (well, maybe
    not the smartcard piece, but MIT Kerberos does, except on Windows).
    If you can leverage an existing PKI then it's not a bad choice, but
    it is a complicated mess to get going; there are SO MANY ways for
    it to go wrong.

    So, which protocol should you use? Well, even though I hold a soft spot
    for SAM2, I can't really recommend using it for new implementations;
    ours is really just due to legacy code. So that's either FAST OTP or
    PKINIT. However ... FAST does require a special "FAST armour key"
    (which is typically a host key) or support for anonymous PKINIT.
    Either of those requires a bit of magic at kinit time, which I haven't completely sussed out all yet. I'm not actually sure if FAST OTP has
    been deployed anywhere; it may be! If so, no one talks about it.
    One advantage of SAM2 is that it "just works" when you enable it
    (assuming everything else is set up correctly).

    There is an existing FAST OTP implementation for MIT Kerberos; the documentation is here:

    https://web.mit.edu/kerberos/www/krb5-latest/doc/admin/otp.html

    The implementation requires you to verify the token using a RADIUS
    server. If you do not like that, you'd have to write your own
    implementation (and, sadly, that requires Kerberos internals; sigh, I
    wish that interface was better defined).

    In terms of using it for access to certain hosts, you have a couple
    of options. The preauth mechanism can set what are known as "authentication indicators" in the ticket; you can either configure a host principal
    to only allow the acquisition of a service ticket if it has a particular indicator, or you can modify the server software so it checks for
    a particular indicator. We used a variation of the second approach;
    there is a Kerberos ticket flag called HW_AUTH, and our application server
    code checks for that on the subset of hosts that require it (this was
    before authentication indicators were developed as a protocol extension).

    Now, in terms of "challenges" ... here's my understanding of the
    practical issues you will face:

    - As you note, talking to an external server kills the KDC redundancy.
    And a lot of OTP mechanisms require this. In the larger deployment
    I have worked on, we supported three OTP hardware tokens: SecurID,
    CRYPTOCard, and YubiKey. With CRYPTOCard, I wrote that mechanism and
    put the "secret" directly in the KDC. That worked, but it had an
    unfortunate wart that if you talked to a replica KDC there was no way
    of propagating the "used" token back to the primary (since 99% of the
    requests went to the primary KDC, it never ended up being a problem in
    practice, but I knew it was an issue and never figured out a reasonable
    solution). With SecurID and YubiKey, the KDC ends up talking to external
    verification servers. For various dumb reasons the SecurID server
    implementation never worked well, but the YubiKey one seems to work
    pretty well. It does have the obvious problem that if the YubiKey
    server goes down then you can't kinit if you're using YubiKey (and
    that has happened to us).

    - There's not a way to OPTIONALLY say, "I'd like to use OTP now". You can
    set it on a per-user basis, but kinit (and the underlying API) doesn't
    have the ability to say, "Please let me use OTP for this request".
    We have some local hacks to enable this functionality. In discussions
    on krbdev I believe MIT was open to this functionality, but the
    actual WORK hasn't been done. I was the obvious one to do this work,
    but I just submitted a pullup request for a very simple change that I
    said I'd do back in May, so ... I'm behind. Discussion on this is
    here:

    http://mailman.mit.edu/pipermail/krbdev/2021-April/013448.html

    Now, strangely enough, even though PKINIT is a giant pain in the ass
    it solves a lot of these issues (admittedly, by foisting them off onto
    a PKI, but hey ...). So if you want to use PKINIT, that might be a
    way to go. In terms of second factors, have you looked at the YubiKey
    tokens? The latest ones can act as a PIV token, and you should be able
    to get PKINIT working with them (I will admit I've played around with
    a YubiKey token and I see it shows up as a PIV token, but I didn't get
    a chance to go farther). In theory you could implement the YubiKey verification directly in the KDC, but that has all of the issues with
    the CRYPTOCard support I mentioned.

    I hope it doesn't sound like I'm crapping on people here; a lot of
    very smart people did a lot of very good work in terms of the protocol
    and the code framework for implementing multi-factor authentication in Kerberos. It is not an easy problem! But the documentation on it all
    is a bit ... diffused.

    Anyway, I hope that helps.

    --Ken

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From J.Witvliet@mindef.nl@21:1/5 to All on Thu Oct 7 05:05:33 2021
    To: kerberos@mit.edu

    What do you regard as “expensive”?
    Strong 2FA with world-wide acceptable PKI can be obtained for €70 a piece.
    If you can afford the time, and willing to do your own CA, you can lower it to €15 a piece.

    The first can be obtained when applying for Estonian E-resident, https://learn.e-resident.gov.ee/hc/en-us/articles/360000625098-Why-become-an-e-resident

    second one by buying smart cards at aventra.fi https://aventra.fi/webshop/index.php?route=product/product&product_id=87



    From: "Dan Mahoney (Gushi)" <danm@prime.gushi.org<mailto:danm@prime.gushi.org>> Date: Wednesday, 6 October 2021 at 23:18:51
    To: "kerberos@mit.edu" <kerberos@mit.edu<mailto:kerberos@mit.edu>>
    Subject: 2FA with krb5

    All,

    We use Kerberos but NOT LDAP at the day job.

    We'd like to be able to leverage 2fa for some services (admins) and some services (ssh logins) but not have to pump a 2fa code into, say, our mail applications. Is there a way to make the acquisition of a TGT (for GSSAPI authentication) vs Password Authentication require 2fa?

    That's complication number one.

    Complication number 2 is something like "SecurID is *expensive* for a
    fairly small (<10) admin team."

    Is there any reasonable support for off-the-shelf TOTP or HOTP
    authenticators, i.e. google authenticator or whatnot? If so, is there
    support to have a user have *multiple* available authenticators, such that
    one can be expired and others not?

    Googling this all gets me a bunch of (some older, some newer articles
    about the varying states of SPAKE and the like), and...a whole bunch of
    ads now being shown for startups that want to do it differently but I'm
    SURE no way to integrate with this.

    The final problem, of course, is that if I make all my KDC's 2fa-aware on
    their own, there's no communication of double-use of a token, unless I centralize things, which breaks the purpose of having geo-diverse KDC's.
    I don't suppose the kerberos db replication mechanism has anything that
    can also share this state?

    This is all pie-in-the-sky stuff, but practical answers "just an FAQ" are
    hard to find.

    -Dan

    --

    --------Dan Mahoney--------
    Techie, Sysadmin, WebGeek
    Gushi on efnet/undernet IRC
    FB: fb.com/DanielMahoneyIV
    LI: linkedin.com/in/gushi
    Site: http://www.gushi.org
    ---------------------------

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos

    Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen
    aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

    This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any
    kind resulting from the risks inherent in the electronic transmission of messages.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jochen Kellner@21:1/5 to Ken Hornstein on Thu Oct 7 19:35:59 2021
    Copy: kerberos@mit.edu

    Hi,

    [I'm running Kerberos inside FreeIPA, so plain Kerberos might be
    different...]

    Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:

    We'd like to be able to leverage 2fa for some services (admins) and some >>services (ssh logins) but not have to pump a 2fa code into, say, our mail >>applications. Is there a way to make the acquisition of a TGT (for GSSAPI >>authentication) vs Password Authentication require 2fa?

    Yes (I'll explain more below).

    That's complication number one.

    Complication number 2 is something like "SecurID is *expensive* for a >>fairly small (<10) admin team."

    Yeah, tell me about it.

    I've been running Privacyidea (https://www.privacyidea.org/) for some
    time to manage the tokens. Exposed the Application with RADIUS and told
    FreeIPA to authenticate against RADIUS. Had some rough edges, but was
    usable for me and is able to manage many kinds of tokens.

    Will it work for you? Maybe...

    Jochen

    --
    This space is intentionally left blank.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ken Hornstein@21:1/5 to Jochen Kellner on Thu Oct 7 14:35:35 2021
    Copy: kerberos@mit.edu

    I've been running Privacyidea (https://www.privacyidea.org/) for some
    time to manage the tokens. Exposed the Application with RADIUS and told >FreeIPA to authenticate against RADIUS. Had some rough edges, but was
    usable for me and is able to manage many kinds of tokens.

    So what's the _client_ look like? Specifically, are you doing FAST-OTP?
    If so, what client software are you using? Does this only work on
    systems with host keys, or do you do anonymous PKINIT?

    --Ken

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Ken Hornstein on Thu Oct 7 11:50:37 2021
    Copy: kerberos@mit.edu

    Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:

    I am not sure of the client coverage of the OTP FAST factor, though.

    For what it's worth, although my pam-krb5 module implements FAST including
    both keyed and anonymous FAST, it does not implement FAST OTP. This is
    because (a) I didn't find any documentation of what I was supposed to do
    as a client (it's been years since I looked so this quite possibly has changed), and (b) attempting to set up a reasonable test environment
    looked painful. In particular, there was (at the time, again haven't
    checked recently) a lot of hand-waving about exactly to set up the RADIUS
    part, since MIT Kerberos just treats it as an oracle.

    I haven't checked if sssd supports FAST OTP. That seems much more likely
    given that they probably have enterprise use cases that would warrant implementing it.

    I'd be happy to take pull requests since I try to make pam-krb5 reasonably completionist as a hobby (although be aware that it's a purely hobby
    project at this point), but they would need to include changes to the ci directory to set up the KDC and RADIUS server appropriately so that the
    test suite could do a proper end-to-end integration test.

    --
    Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simo Sorce@21:1/5 to Russ Allbery on Thu Oct 7 15:06:14 2021
    To: kenh@cmf.nrl.navy.mil (Ken Hornstein)
    Copy: kerberos@mit.edu

    On Thu, 2021-10-07 at 11:50 -0700, Russ Allbery wrote:
    Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:

    I am not sure of the client coverage of the OTP FAST factor, though.

    For what it's worth, although my pam-krb5 module implements FAST including both keyed and anonymous FAST, it does not implement FAST OTP. This is because (a) I didn't find any documentation of what I was supposed to do
    as a client (it's been years since I looked so this quite possibly has changed), and (b) attempting to set up a reasonable test environment
    looked painful. In particular, there was (at the time, again haven't
    checked recently) a lot of hand-waving about exactly to set up the RADIUS part, since MIT Kerberos just treats it as an oracle.

    It is somewhat documented, but see below.

    I haven't checked if sssd supports FAST OTP. That seems much more likely given that they probably have enterprise use cases that would warrant implementing it.

    It does, and FreeIPA implements the server part, so you can look there
    for examples and testing capabilities if you are so inclined.

    I'd be happy to take pull requests since I try to make pam-krb5 reasonably completionist as a hobby (although be aware that it's a purely hobby
    project at this point), but they would need to include changes to the ci directory to set up the KDC and RADIUS server appropriately so that the
    test suite could do a proper end-to-end integration test.

    HTH,
    Simo.

    --
    Simo Sorce
    RHEL Crypto Team
    Red Hat, Inc

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Simo Sorce on Thu Oct 7 12:55:20 2021
    Copy: kenh@cmf.nrl.navy.mil (Ken Hornstein)
    Copy: kerberos@mit.edu

    Simo Sorce <simo@redhat.com> writes:

    Starting an ad-hoc kdc is pretty easy, I have it done in the make check
    phase in many small projects, including starting an ldap server, I
    haven't tried radius, but hopefully starting a freeradius server is not exceedingly hard either.

    Yeah, for the record it was just the RADIUS bit that I didn't already have working. If anyone is curious:

    https://github.com/rra/pam-krb5/tree/master/ci

    contains scripts that will set up either an MIT Kerberos KDC or a Heimdal
    KDC with PKINIT configured and a variety of keytabs and whatnot premade.
    They are used via GitHub Actions here:

    https://github.com/rra/pam-krb5/blob/master/.github/workflows/build.yaml

    --
    Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Ken Hornstein on Thu Oct 7 12:16:29 2021
    Copy: kerberos@mit.edu

    Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:

    Huh, I _kinda_ thought that if you had FAST going, you got FAST OTP (on
    the client at least) for free! Which shows what I know. Maybe it works already and you never tested it?

    The bit that I suspect doesn't work is all the interactions between the prompting and the prompt control options like use_first_pass.

    --
    Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ken Hornstein@21:1/5 to Russ Allbery on Thu Oct 7 15:14:33 2021
    Copy: kerberos@mit.edu

    Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:

    I am not sure of the client coverage of the OTP FAST factor, though.

    For what it's worth, although my pam-krb5 module implements FAST including >both keyed and anonymous FAST, it does not implement FAST OTP. This is >because (a) I didn't find any documentation of what I was supposed to do
    as a client (it's been years since I looked so this quite possibly has >changed),

    Huh, I _kinda_ thought that if you had FAST going, you got FAST OTP (on
    the client at least) for free! Which shows what I know. Maybe it works already and you never tested it?

    and (b) attempting to set up a reasonable test environment
    looked painful. In particular, there was (at the time, again haven't
    checked recently) a lot of hand-waving about exactly to set up the RADIUS >part, since MIT Kerberos just treats it as an oracle.

    Right, THIS is actually a huge problem. Like having to set up a RADIUS
    server? Ugh. It's also a problem for development! Like the only
    way I have found to effectively test preauth mechanisms is to do
    testing on one of our replica KDCs.

    --Ken

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simo Sorce@21:1/5 to Ken Hornstein on Thu Oct 7 15:35:41 2021
    To: eagle@eyrie.org (Russ Allbery)
    Copy: kerberos@mit.edu

    On Thu, 2021-10-07 at 15:14 -0400, Ken Hornstein wrote:
    Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:

    I am not sure of the client coverage of the OTP FAST factor,
    though.

    For what it's worth, although my pam-krb5 module implements FAST
    including
    both keyed and anonymous FAST, it does not implement FAST OTP.
    This is
    because (a) I didn't find any documentation of what I was supposed
    to do
    as a client (it's been years since I looked so this quite possibly
    has
    changed),

    Huh, I _kinda_ thought that if you had FAST going, you got FAST OTP
    (on
    the client at least) for free! Which shows what I know. Maybe it
    works
    already and you never tested it?

    and (b) attempting to set up a reasonable test environment
    looked painful. In particular, there was (at the time, again
    haven't
    checked recently) a lot of hand-waving about exactly to set up the
    RADIUS
    part, since MIT Kerberos just treats it as an oracle.

    Right, THIS is actually a huge problem. Like having to set up a
    RADIUS
    server? Ugh. It's also a problem for development! Like the only
    way I have found to effectively test preauth mechanisms is to do
    testing on one of our replica KDCs.

    Starting an ad-hoc kdc is pretty easy, I have it done in the make check
    phase in many small projects, including starting an ldap server, I
    haven't tried radius, but hopefully starting a freeradius server is not exceedingly hard either.

    Simo.

    --
    Simo Sorce
    RHEL Crypto Team
    Red Hat, Inc

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jochen Kellner@21:1/5 to Ken Hornstein on Thu Oct 7 21:29:57 2021
    Copy: kerberos@mit.edu

    Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:

    I've been running Privacyidea (https://www.privacyidea.org/) for some
    time to manage the tokens. Exposed the Application with RADIUS and told >>FreeIPA to authenticate against RADIUS. Had some rough edges, but was >>usable for me and is able to manage many kinds of tokens.

    So what's the _client_ look like? Specifically, are you doing FAST-OTP?
    If so, what client software are you using? Does this only work on
    systems with host keys, or do you do anonymous PKINIT?

    I mostly use sssd and kinit. I'm not sure what sssd uses, but I remember
    traces from kinit using PKINIT. These two clients worked well for me.

    Other clients (java applications) had problems with OTP. See https://lists.jboss.org/pipermail/keycloak-user/2018-January/012759.html
    for the analysis we did there.

    As you said - with the "right" clients it might work. Otherwise you
    might be stuck.

    Jochen

    --
    This space is intentionally left blank.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Mahoney@21:1/5 to Russ Allbery on Thu Oct 7 20:54:26 2021
    Copy: kenh@cmf.nrl.navy.mil (Ken Hornstein)
    Copy: simo@redhat.com (Simo Sorce)
    Copy: kerberos@mit.edu

    So, there’a an assumption here: all the kerberos 2fa stuff is really only used when you kinit. And that extra protcol is the one where the three differing protocols come in. Just like sshd’s Password Authentication vs Challenge Response
    Authentication, the client has to be *able* to ask for more info.

    Here’s my use case.

    I ssh in to things. Sometimes from MacOS, sometimes from iPadOS. Some of our things require a kerberos ticket *or* some other 2fa, typically used in cases where you can’t kinit.

    If you’re using kerberos in some other way (say, normal HTTP basic auth via mod_auth_kerb), you don’t have the benefit of the 2fa. (You can tell apache not to let that work, and simply have your users forced to use ticket auth, but that doesn’t
    work on Android, iOS, iPadOS, etc).

    HTTP Basic Auth has no support for asking for additional factors — you can, depending on the application, ask for a 2fa code, or use the “put your 2fa token at the end of the password, but I don’t know if keberos knows how to split this off — and
    continue allowing it when the 2fa value continues changing.

    Same goes for GSSAPI Auth with sshd — if you’re using either the builtin KerberosAuthentication or the alternative, pam with pam_krb5, you can fall back to password authentication and then use something like pam-whatever-other-2fa provider to get the
    same net effect. I don’t know what the KDC says in those cases, if it refuses to work at all because no 2fa was presented, or if it Just Works.

    And Radius, I get it but...I know for example with SecurID, one of the things you can do is talk to the SecurID server over RADIUS, and I’m pretty sure other 2fa servers (mypw, cryptocard, etc) do the same thing. Radius isn’t an unreasonable
    protocol, but there’s no RADIUS server for, say, Google Authenticator, or OPIE.

    You could have your KDC talk ta a RADIUS server that’s talking to a PAM service that calls some sort of 2fa server. That feels…duct-tapey.

    I mean, this might be dumb, but why not have the kdc able to speak to pam modules directly?

    -Dan

    On Oct 7, 2021, at 12:55 PM, Russ Allbery <eagle@eyrie.org> wrote:

    Simo Sorce <simo@redhat.com> writes:

    Starting an ad-hoc kdc is pretty easy, I have it done in the make check
    phase in many small projects, including starting an ldap server, I
    haven't tried radius, but hopefully starting a freeradius server is not
    exceedingly hard either.

    Yeah, for the record it was just the RADIUS bit that I didn't already have working. If anyone is curious:

    https://github.com/rra/pam-krb5/tree/master/ci

    contains scripts that will set up either an MIT Kerberos KDC or a Heimdal
    KDC with PKINIT configured and a variety of keytabs and whatnot premade.
    They are used via GitHub Actions here:

    https://github.com/rra/pam-krb5/blob/master/.github/workflows/build.yaml

    --
    Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/> ________________________________________________
    Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ken Hornstein@21:1/5 to Dan Mahoney on Fri Oct 8 07:45:06 2021
    Copy: kerberos@mit.edu

    I mean, this might be dumb, but why not have the kdc able to speak to
    pam modules directly?

    All of those things are "send me a 2FA token and I will verify it".
    (Also, the pam API really really wants to talk to a person, that's
    the whole point of the "pam conversation" functions; I don't see how
    you could make that work with a KDC).

    Kerberos is "I am going to take your password which I already know,
    convert it into an encryption key, and use it to verify your Kerberos
    request". Kerberos needs to know the password/factor to make that
    happen, where the typical 2FA API only tells you "is this token good
    or not?".

    I am aware of one site that a long, long time ago had developed code
    that you used the 2FA code as the Kerberos password directly; I never
    thought that was a good idea myself as the 2FA code never had a lot
    of entropy to serve as a good encryption key, but it worked for them.

    If you want to use something like TOTP, then I think you're probably
    going to have to write your own FAST OTP preauth module. Which is
    doable! Although in practice it seems like any preauth module requires
    access to the MIT Kerberos ASN.1 decoder/encoder API, which means
    an internal dependency. Sigh.

    Sadly, at this stage right now if you want to effectively use 2FA with
    Kerberos you're going to be stuck at the very minimum reading a lot of
    source code and protocol documents to see if you have the application
    coverage you need.

    --Ken

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Hudson@21:1/5 to Ken Hornstein on Fri Oct 8 11:45:51 2021
    To: danm@prime.gushi.org (Dan Mahoney)
    Copy: kerberos@mit.edu

    On 10/8/21 7:45 AM, Ken Hornstein wrote:
    I mean, this might be dumb, but why not have the kdc able to speak to
    pam modules directly?

    Kerberos is "I am going to take your password which I already know,
    convert it into an encryption key, and use it to verify your Kerberos request". Kerberos needs to know the password/factor to make that
    happen, where the typical 2FA API only tells you "is this token good
    or not?".

    I think Dan was assuming one of the cases where the KDC received a 2FA
    value and needs an oracle, such as FAST OTP.

    One concern is that PAM modules must operate synchronously (unless I'm
    badly mistaken), so the KDC process would be blocked if the module has
    to talk to a remote server. You can get away with that if your
    population of 2FA users is small and the oracle is fast, but OTP oracles
    are often deliberately slow to answer. We developed an async kdcpreauth interface and async RADIUS code to address that problem for FAST OTP.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Charles Hedrick@21:1/5 to Russ Allbery on Fri Oct 15 16:52:56 2021
    Copy: kenh@cmf.nrl.navy.mil (Ken Hornstein)
    Copy: kerberos@mit.edu

    We use TOTP. That allows us to tack the token on the end of the password. That makes it easy to fix programs that expect a simple password prompt.

    In fact I have a wrapper that can be interposed around pretty much anything use LD_PRELOAD.

    https://github.com/clhedrick/kerberos/blob/master/radius-wrap/radius-wrap.c

    On Oct 7, 2021, at 3:16 PM, Russ Allbery <eagle@eyrie.org> wrote:

    Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:

    Huh, I _kinda_ thought that if you had FAST going, you got FAST OTP (on
    the client at least) for free! Which shows what I know. Maybe it works
    already and you never tested it?

    The bit that I suspect doesn't work is all the interactions between the prompting and the prompt control options like use_first_pass.

    --
    Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/> ________________________________________________
    Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ken Hornstein@21:1/5 to Charles Hedrick on Fri Oct 15 17:49:42 2021
    Copy: kerberos@mit.edu

    We use TOTP. That allows us to tack the token on the end of the
    password. That makes it easy to fix programs that expect a simple
    password prompt.

    In fact I have a wrapper that can be interposed around pretty much
    anything use LD_PRELOAD.
    [...]

    Well, that answers PART of my question. And I am guessing based on
    the README for that you use k5start to generate the FAST armor cache
    using the host key in the keytab? But this seems kind of RADIUS
    specific; do you use TOTP for people who just use kinit?

    --Ken

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Charles Hedrick@21:1/5 to Ken Hornstein on Sat Oct 16 00:22:11 2021
    Copy: kerberos@mit.edu (kerberos@mit.edu)

    I’m not using that code now. When using it for real I would generate a special key tab with a user that had no permissions to do anything or use the host key tab depending upon the application.

    Our staff and a few users have TOTP set for their account, so it has to work for everything. Logins use sssd, with its pam. We have a service with source in the same repo that keeps credentials renewed and kills them when the users last session is gone.
    In case we need to kinit I have a script that gets an anonymous credential and passes it to kinit -T. I get the credential,from a service on the Kerberos server. It’s the same service that generates credentials for cron jobs . I could use kinit -n,
    but that creates a problem of distributing cents to all clients. The service is easier.

    I don’t like key tabs for users because if someone manages to get a copy you have no way of knowing, and it can be used anywhere in the system. So if a user wants to use cron jobs that need credentials, they register with the service. At that point a
    Pam module used by cron can get a credential,for them. It’s not forwardsble, and is locked to that hosts IP. The primary use is so cron jobs can access files, since all our file systems are kerberized.

    We are fully kerberized. But one implementation constraint was that it should be invisible to users, except if they run cron jobs. That requires more work than it ought to.

    On Oct 15, 2021, at 5:50 PM, Ken Hornstein <kenh@cmf.nrl.navy.mil> wrote:

    

    We use TOTP. That allows us to tack the token on the end of the
    password. That makes it easy to fix programs that expect a simple
    password prompt.

    In fact I have a wrapper that can be interposed around pretty much
    anything use LD_PRELOAD.
    [...]

    Well, that answers PART of my question. And I am guessing based on
    the README for that you use k5start to generate the FAST armor cache
    using the host key in the keytab? But this seems kind of RADIUS
    specific; do you use TOTP for people who just use kinit?

    --Ken

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)