U2F/FIDO

[riastradh]

Is your feature request related to a problem? Please describe.
Heimdal authentication currently relies on the secrecy of a password shared between user and KDC. Passwords chosen with low-entropy processes reduce the security available to Kerberos, e.g. exposing users to dictionary attacks in the event of spoofed KDCs, and passwords accidentally pasted into the wrong place -- such as a phishing web site -- destroy the security altogether.

Of course, kinit itself isn't exactly vulnerable to phishing, but passwords are still a weak point, and password-fallback for web login absolutely is vulnerable to phishing. (Plus lots of government agencies and corporate security policies like things that have 2FA pasted on them.)

Heimdal should be able to take advantage of U2F/FIDO when getting initial tickets, so that for an adversary to compromise a principal, they must guess the user's password and compromise one of the user's U2F/FIDO keys.

Describe the solution you'd like

1. KDC database sprouts a place to store a list of enrolled U2F/FIDO devices, each one identified by a nickname.

2. kpasswd or something allows showing/updating the list, to enroll and unenroll U2F/FIDO devices by nickname.

3. kinit prompts for both password and tapping a U2F/FIDO key to acquire tickets from the KDC.

   (Ideally, web applications using WWW-Authenticate with Negotiate for SPNEGO/krb5 plus Basic fallback or similar could also use webauthn for the same purpose.)

Once U2F/FIDO devices are enrolled by a principal (perhaps with a minimum of two devices so losing a device doesn't lock you out), the KDC will refuse to grant a tgt without both password and an assertion from one of the enrolled U2F/FIDO devices.

Describe alternatives you've considered
U2F/FIDO is the only serious widely deployable phishing-resistant user crypto token system and 2FA system today.

• TOTP and other one-time-code systems like RSA SecurID are vulnerable to phishing.

• Push notifications on proprietary networks like Microsoft Authenticator are proprietary, introduce new network failure modes beyond the KDC, require installing sketchy apps on your phone, and are vulnerable to phishing.

• The old CCID/PKCS#11/PKCS#15 stack is a nightmare of:

  • software compatibility issues,
  • hardware compatibility issues,
  • abysmal user experience,
  • state stored on device,
  • privacy leaks,

  and so on, and is generally unusable by anyone who doesn't have a severe case of crypto nerdery, unless corporate's IT department has already wired up all the toothpicks and duct tape of pcscd and libpcsc and pcsc drivers and PKCS#11 modules and hardware card initialization and so on, on a carefully controlled managed laptop, and you don't sneeze.

Additional context
Red Hat has created a preauth protocol involving U2F/FIDO called PA-REDHAT-PASSKEY. I haven't looked into the details yet, and as far as I'm aware, only the client side (kinit or equivalent) is publicly implemented so far. As I read the protocol details I may add an assessment here of whether it is a good protocol.

[nicowilliams]

Is there a way to do this w/o extending the Kerberos AS protocol? (Not that I mind extending it, but getting interop will take time.)

[lhoward]

Azure AD does this by having a distinct web service return a RODC TGT [1] which can then be presented to the real KDC.

[1] RODC stands for Read Only Domain Controller, in this case it's sufficient to think of it as a KDC that shares the TGS name but not the master TGS key. RODCs are disambiguated by the high bits of the key version number.

[nicowilliams]

I think Luke meant to link https://syfuhs.net/hybrid-authentication-with-fido