Ops feedback notes 2014-05-06 - Revision history

TomYu at 22:27, 20 May 2014

2014-05-20T22:27:03Z

TomYu at 22:22, 20 May 2014

2014-05-20T22:22:09Z

TomYu: 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...

2014-05-15T23:01:15Z

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

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

← Older revision		Revision as of 22:27, 20 May 2014
Line 18:		Line 18:

	There is interest.		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.		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.

@@ Line 1: / Line 1: @@
 {{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 CryptoCard, also Yubikey.  Hoping plugin arch will help maintain local patches.
@@ Line 17: / Line 19: @@
 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.
+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.