> On Jun 29, 2017, at 12:45 PM, Nico Williams <n...@cryptonector.com> wrote:
> On Thu, Jun 29, 2017 at 11:41:41AM -0700, Henry B (Hank) Hotz, CISSP wrote:
>>> On Jun 28, 2017, at 8:11 AM, Nico Williams <n...@cryptonector.com> wrote:
>>> On Wed, Jun 28, 2017 at 07:28:59AM +0200, Lars-Johan Liman wrote:
>>>> Please fix this, either by changing the name "all" to "most" (or
>>>> preferrably to somthing better), or by changing the behaviour to be
>>>> *ALL*. Either is fine, but having "all" not mean *ALL* is not a good way
>> I absolutely agree with everything you said. I think it very to make
>> unwise to make a backwards-incompatible change in order to turn the
>> permissions description from plain english into a Heimdal-unique code.
> We want get-keys to go away. When it does, "all" will mean "all”.
If we’re really only arguing about a transient situation, then I can relax a
>> I’ll repeat my recommendation that we do what Love suggested.
> Link? Quote?
It’s from the year-ago discussion that someone (you?) provided a link for. I
think it’s the only thing he’s said on the subject.
>>> It is true
>>> that switching to "ext_keytab -r", which is what we want sites to do, is
>>> more difficult and requires careful consideration by them, but again,
>>> you can get the old "all" by granting your admins "all" + "get-keys", so
>>> you're not forced to use "ext_keytab -r”.
>> How about putting the recommended change (to ...-r) in the permissions
>> error for ext_keytab?
> I've said I'm amenable to that. I do want admins to understand what
> that means though. Doing that on a cluster could cause an outage. So
> such an error message improvement will need to be crafted carefully.
>> The point is that you have made the pain, or at least the confusion,
>> permanent by making the language mean something other than what it
>> says. That does not seem well considered, and I think the amount of
>> flack you’re getting reflects that.
> It's one-time on upgrade per-site.
> It was security vs backwards-compatibility. Security won.
>> If you’re really going to be that hard-nosed about it, then you had
>> better put a hell of a lot of warning messages and explanations all
>> over the place. Better yet, just do away with any ability to extract
>> (current) keys altogether. Make the -r option the only thing possible
>> unless you build with some configure option like
>> --enable-insecure-key-extraction. Then you can phase it out over a
>> couple of revisions, like we did with single-DES.
> That wouldn't allow you to narrow key extraction permission slowly until
> you no longer need it.
>> Honestly, is it really that big a deal to change “all” to e.g.
>> “admin”? If you’re going to make a fundamental semantic change, you
>> shouldn’t hide the fact. You should make it as obvious as you possibly
What I had in mind was more like require that option do what you’re now doing.
(Now that I’m convinced the Microsoft/MIT behavior is the right one.) Without it
> That would not have had the desired effect of confronting sites with the
> insecurity of extracting keys. We can't force them to stop depending on
> that in one fell swoop.
If you create, then require, then eventually eliminate the option, you can
announce that plan as part of the release notes/announcements. Everyone is
confronted with it at build time, and everyone is told what to expect, and when
you will do it.
> You're over-thinking this and making a mountain out of a molehill. My
> advice is to accept the change that took place -- we don't have a time
> machine and we will not call this a bug -- and move on to something more
> I'm thinking about what the UI should look like for automatic key
> expunge, for example. I'm thinking about how to integrate krb5_admin/
> krb5_keytab into Heimdal, or some of their functionality into kadmin/
> kadmind/libkadm5. Thoughts on that? Please use a new thread.
Yes, it seems everyone agrees that better handling of service key rotation
would be good.
Personal email. hbh...@oxy.edu