Ops feedback notes 2014-05-06

Preauth and multifactor

DOD sites primarily use DOD CAC with PKINIT. MIT implementation expects principal name in cert; need patches for MIT KDC to handle this. Non-CAC includes SecurID and CryptoCard, also Yubikey. Hoping plugin arch will help maintain local patches.

Tom

Is there a use case for using an existing long-term password (without OTP) and adding OTP without changing the password?

There seems to be some desire for this. There are some concerns about weak passwords.

Greg

Does it need to be difficult to attack the factors independently?

It depends on the strength of AS-REP encryption. With SecurID and SAM2, it's password-only. CryptoCard uses mixed key. Lots of hosts don't have a host key. In some deployments, some hosts can require 2-factor auth, and some not.

Key verifying vs key generating -- Yubikey has key generating capability, but for some reason requires root access on the (Yubikey) client (the KDC).

Tom

Is there interest in using PAKE to make OTP more deployable?

There is interest.

Preventing dictionary attacks

Some discussion about requires_preauth and its role in preventing passive dictionary attacks. It's necessary to also turn off allow_svr to achieve desired effect. There is interest in kadmind support for automatically setting some policy parameters on principals when they change their key to a password-derived one, possibly configurable.

The requires_preauth flag is ambiguous; it controls ticket issuance for both client and service principals. There is interest in splitting the flag somehow, as well as the related requires_hwauth. There are sites using existing dual meaning to require preauth'ed tickets for gaining access to some high-value services.

The conservative change would be to split each requires_preauth flag into two new flags, which would add four new flags. Some sites might be OK with a change to existing behavior, which means only two new flags, as long as the behavior change is well documented and clearly announced in advance.

General usability comments

Error messages are difficult for novices. Some errors mean multiple things; other times errors with distinct meanings have confusingly similar wordings, e.g., "cannot contact" vs "can't find". Principal mismatches can be difficult to debug.

Greg

Upcoming changes (1.13 release) should have more specific errors for rd_req, making it easier to debug these situations.

Tom

How do people feel about printing numeric codes in addition to textual error messages? It can be useful to help desks (e.g., users are more likely to accurately copy/report a number). There's a possible tradeoff against intimidating users.

There's some interest. Maybe make it optional? Also some opinions that it can be better to obfuscate to end-user, but include more details in logs.

Something about kpropd in single iteration mode kills its child early on 1.11.

Want reporting capabilities from LDAP, e.g., password change dates, specific policies used when existing passwords were set, "which principals are DES?".

Documentation

Tom

What do people wish were better documented?

• Naming -- how it fits into Kerberos -- high level intro
• Realm referrals, e.g., how to set up DNS-based referrals
• Plugin dev
• Encryption and enctypes, e.g., how does KDC decide which to use?
• Compatibility issues, e.g., Java. Maybe have some wiki entries?
• MIT vs Heimdal compat. e.g., kx509 needs short-lived tickets with renewable lifetimes. Heimdal client apparently doesn't request renewable?
• What do attributes mean, e.g., postdated?
• S4U stuff, maybe with example use cases.
• LDAP back end

Potential future topics

• Database dumps/locks (excessive duration of locks)
• Reporting for auditors
• Some problems with JGSS
• One-way delegation of credentials to remote realm that's behind a firewall (needed to make patches to MIT Kerberos)