Difference between revisions of "Ops feedback notes 2014-05-06"
(New page: {{opsnotes|2014}} 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 C...) |
(No difference)
|
Revision as of 18:01, 15 May 2014
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.
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