> 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 >>>> forward. >> >> 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 bit. >> 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 >> can. What I had in mind was more like: require that option to do what you’re now doing. (I’m now convinced that the Microsoft/MIT behavior is the right one. It’s as close as Kerberos gets to PFS.) > 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 > productive. > > 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. I’ll start such a thread in a bit if nobody else does. > Nico > -- Personal email. hbh...@oxy.edu
