Ops feedback notes 2014-05-06

From K5Wiki
Revision as of 18:01, 15 May 2014 by TomYu (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.

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.

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).

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

There is interest.

Some discussion requires_preauth and relationship to preventing passive dictionary attacks. It's necessary to turn off allow_svr as well. 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.

to be continued

Personal tools