Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege" (Corrected)

[Henry B (Hank) Hotz, CISSP]

> On Jun 29, 2017, at 12:45 PM, Nico Williams  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  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

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

[Henry B (Hank) Hotz, CISSP]

> On Jun 29, 2017, at 12:45 PM, Nico Williams  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  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 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
> 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.

> Nico
> -- 

Personal email.  hbh...@oxy.edu

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

[Chaskiel Grundman]

I have a toolset deployed at Carnegie Mellon that attempts to address some
of these problems (automatic rekeying of services and purging of old keys
from keytabs).
https://github.com/cg2v/krb-rekey

The protocol is probably too cute and non-standard for people to want to
use, and there isn't nearly enough documentation, but if there's interest,
I might be able to work on changes to make it more useful.

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

[Jeffrey Altman]

On 6/28/2017 1:17 AM, Russ Allbery wrote:
> Nico Williams  writes:
> 
>> We do need better key mgmt support though.  It'd nice to have automatic
>> rekeying and expunging of keys too old to be needed for decrypting
>> extant live tickets.
> 
> Yes, please, or I will inflict my hideous shell script on you that does
> this (using wallet).

I would be interested in hearing from the participants of this list
whether or not it would be appropriate to ship some of the Secure
Endpoints open source kerberos tooling as part of Heimdal:

 http://oskt.secure-endpoints.com/

In particular, Roland's krb5_admin, krb5_keytab, and the C variant of KNC.

Jeffrey Altman






smime.p7s
Description: S/MIME Cryptographic Signature

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

[Jeffrey Hutzelman]

On Tue, 2017-06-27 at 16:42 -0700, Henry B (Hank) Hotz, CISSP wrote:
> > 
> > On Jun 27, 2017, at 4:23 PM, Nico Williams 
> > wrote:
> > 
> > We decided that it was never a good idea for "all" to have meant
> > "extract keys", because in general that's not desirable.
> How is extracting keys different from extracting a keytab (with the
> keys inside it)?


ext_keytab is poorly-named. In MIT Kerberos, it doesn't actually
extract anything; it generates a new key with a new kvno and stores it
in both the keytab and the kdb. MIT kadmind, going back as far as krb4,
didn't even have an operation to fetch existing keys from the database;
that was considered an exceptionally dangerous ability and not really
necessary.

Heimdal initially took a different approach, which is still what
ext_keytab does by default, for backward compatibility and to avoid
unpleasantly-surprising results. With -r, it randomizes the key
instead, which is safer. Note that ext_keytab without -r will not work
if you don't have the get-keys privilege.

I have patches going back as far as Heimdal 0.6 which make get-keys a
separate privilege not included in 'all'. I didn't write the change
that eventually made it into Heimdal, but I certainly agree with it.


-- Jeff

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

[Henry B (Hank) Hotz, CISSP]

> On Jun 27, 2017, at 4:23 PM, Nico Williams  wrote:
> 
> We decided that it was never a good idea for "all" to have meant
> "extract keys", because in general that's not desirable.

How is extracting keys different from extracting a keytab (with the keys inside 
it)?

Personal email.  hbh...@oxy.edu

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

[Nico Williams]

On Mon, Jun 26, 2017 at 11:18:28AM +0200, Andreas Haupt wrote:
> Heimdal 7.3 seems to suffer from a bug in privilege checking. A prinicipal
> having all rights on the database is unable to extract keytabs:

This is on purpose.

We decided that it was never a good idea for "all" to have meant
"extract keys", because in general that's not desirable.

Instead you should either use ext_keytab -r, or add the get-keys
privilege to whoever needs it.

> That does not change even when explicitly listing all rights:
> 
> [kdc1] /root # cat /var/heimdal/kadmind.acl 
> /admin@ cpw list delete modify add get get-keys

That would be a bug.  I'll see if I can reproduce it.

Nico
--