[16397] in Kerberos_V5_Development
Re: random to key from password
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Mon Sep 27 17:35:20 2010
Date: Mon, 27 Sep 2010 16:34:49 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Russ Allbery <rra@stanford.edu>
Message-ID: <20100927213448.GS9501@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <87k4m6swqr.fsf@windlord.stanford.edu>
Cc: lha@h5l.org, Sam Hartman <hartmans@mit.edu>, krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Mon, Sep 27, 2010 at 02:27:24PM -0700, Russ Allbery wrote:
> Nicolas Williams <Nicolas.Williams@oracle.com> writes:
> > And lacking that, make service princs require pre-auth.
>
> Making service principals require pre-auth is hard if you haven't done
> that uniformly from the start of your realm, since once they require
> pre-auth, you can't authenticate to them with a non-pre-auth ticket. That
> means you have to build a dependency order by starting with the service
> principals that never authenticate to other service principals and work
> through the list in dependency order, and that's a tricky migration.
> We looked at doing that and then gave up.
*sigh*
All this one-knob-controls-two-things stuff is annoying. Yes, often
that leads to fewer knobs, and fewer knobs is almost always better. But
some times conflating of related-but-different things does create
problems. Here we have a couple of instances: a) list of long-term
enctypes implies {enctypes supported for session keys, enctypes allowed
when acting as a client}, b) requires-preauth implies {must be pre-
authenticated when acting as a client, clients of this princ must be
pre-authenticated}.
At least nowadays all clients should support PA-ENC-TIMESTAMP, so you
could revisit your decision. But really, it'd be better to have more
knobs here.
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
