Re: kadmin: failing dump/load

[Henry B (Hank) Hotz, CISSP]

+1

> On Nov 7, 2017, at 1:55 AM, Patrik Lundin  wrote:
> 
> This means that you can not inspect the database
> (short of dumping it with kadmin -l dump) without possibly altering it
> which might not be expected (though I do see the helpful side of being
> able to easily prune keys on demand).

Personal email.  hbh...@oxy.edu

Re: iprop: Problem forcing complete database sync

[Henry B (Hank) Hotz, CISSP]

On thing that’s conspicuously missing from this discussion is any historical 
context for how the version numbers are *supposed* to be handled. It seems like 
most of these problems are recent, or at least recent-ish.

IIUC the deal is (should be? used to be? Please correct!):

1) On initial creation, the log contains a version 0 no-op, making the db 
version 1.

2) On connection, the slave tells the master what version it has. If it doesn’t 
match what the master has then the master sends updates to bring them in sync.
2a) If the master’s change log is insufficient, (or the difference is “too 
big), then it sends the whole DB.
2b) If the difference is small enough, then the master just replays the change 
log from where the slave is.

3) Seems to me that the handling of the heartbeat messages ought to mirror the 
initial connection logic, or else make no attempt to do anything to the DB at 
all. Anything else is clearly risky and unnecessarily complex. (I never worried 
about them because I had already implemented external processes to deal with 
the issue. Somebody else should write this bullet.)

A new DB (on a slave) is guaranteed to have a smaller version number than the 
master (if the master is actually populated), so will always get a complete 
download.

Truncation, preserving the version number is safe and periodically necessary. 

I do not remember the --reset option, but it’s clearly dangerous. How can it be 
used safely, knowing only the above?

(Where is Love when you need him?)

Personal email.  hbh...@oxy.edu

Tangent from: [kitten] Checking the transited list . . .

[Henry B (Hank) Hotz, CISSP]

> On Aug 21, 2017, at 7:05 AM, Greg Hudson  wrote:
> 
> I'm not sure about "any KDC in the trust chain trusts the next hop."
> RFC 4120 doesn't think about cross-realm relationships in terms of
> trust.  Simply having cross-realm keys with another realm doesn't
> necessarily imply that the other realm is trustworthy.

That’s always been a slippery distinction in practice. Trust depends on “local 
policy” which may be determined by many things that are orthogonal to what the 
crypto can actually provide. Unless you’re writing the code yourself, I would 
presume that anything with an exchanged set of keys is trusted for 
authentication. Authorization is, of course, outside the scope of Kerberos.

Personal email.  hbh...@oxy.edu

Re: How to disable DNS lookups?

[Henry B (Hank) Hotz, CISSP]

> On Jul 26, 2017, at 4:12 PM, Viktor Dukhovni  
> wrote:
> 
>> The RR is guaranteed to return a name which has an A/ record.
> 
> It is not.  SRV RRs can and sometimes do reference names that don't exist.
> Ditto with MX records, ...  Even when the name exists a lookup can
> time out.

Per RFC 2782:

   Target
The domain name of the target host.  There MUST be one or more
address records for this name, the name MUST NOT be an alias (in
the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
not required, to return the address record(s) in the Additional
Data section.  Unless and until permitted by future standards
action, name compression is not to be used for this field.

My interpretation of this matches what I said. Nit picking aside, obviously 
Heimdal should be robustto incorrect DNS configuration where possible. 
However, if it winds up having to do a search because DNS is incorrectly 
configured, that strikes me as better than failing outright.

I guess I’m back to not understanding what the problem is. If the SRV RR is 
right, then it’s moot. If the record is wrong, then we’re off the reservation 
and it’s just a question of whether there is anything plausible we can do that 
will address the most likely failures.

Personal email.  hbh...@oxy.edu

Re: How to disable DNS lookups?

[Henry B (Hank) Hotz, CISSP]

I disagree. 

While you are technically correct, in my experience most SAs know very well 
what services are provided and where, but don’t know enough about DNS to know 
what a RR is. For that level of knowledge, having /etc/hosts take precedence is 
exactly the “least surprise” behavior.

> On Jul 26, 2017, at 11:25 AM, Thor Lancelot Simon  wrote:
> 
> On Wed, Jul 26, 2017 at 08:45:17AM -0700, Russ Allbery wrote:
>> 
>> Right, the point is not that you can't override with /etc/krb5.conf, the
>> point is that /etc/hosts normally overrides everything without having to
>> hunt down software-specific configuration files.
> 
> But in this case /etc/hosts clearly *can't* "override everything".  It
> cannot override the SRV records that are used to find the KDC via DNS,
> because there is no syntax to express a SRV record in /etc/hosts; and
> because of that, it is *a priori impossible* to know what hostname
> you would have to "override" in /etc/hosts (were that supported) to
> redirect Kerberos queries for a given realm to a particular IP address.
> 
> You can't even know whether DNS is used to look up the KDC or not without
> looking at krb5.conf.
> 
> Despite the expectation which seems reasonable at first glance that
> /etc/hosts could correctly be used to override a KDC in this way, in
> fact it works only in a few special cases - the ones where DNS is
> in use to find the KDC via SRV record *and* you can be 100% certain
> that SRV record won't change.  Not so useful.
> 
> Rather than relying on this, if you want to hardcode your KDC address,
> far better to turn off DNS lookup of the KDC, use krb5.conf, and be
> entirely manual and predictable, instead of half-manual, half-predictable,
> and half...donkeyed.
> 
> Thor

Personal email.  hbh...@oxy.edu

Re: How to disable DNS lookups?

[Henry B (Hank) Hotz, CISSP]

> On Jul 26, 2017, at 10:29 AM, u-hd-p...@aetey.se wrote:
> 
> On Wed, Jul 26, 2017 at 08:45:17AM -0700, Russ Allbery wrote:
>> Viktor Dukhovni  writes:
>>> 2. Look up same name in DNS, return address(es) if found
>> 
>>> instead, in step 2, we may get undesirable, incorrect and/or costly
>>> interactions with the stub resolver's domain search list.  The name in
>>> the SRV record is an FQDN and MUST NOT be subject to RES_DEFNAMES or
>>> RES_DNSRCH.  The getaddrinfo(3) API provides no means to signal that a
>>> name should not be subjected to the DNS search list.
>> 
>> Ah!  Thank you.  That helps me understand the problem you're trying to
>> solve.
> 
> +1
> 
> Then the explicit trailing dots in /etc/hosts look indeed
> like a reasonable trade-off.
> 
> Rune

Actually, isn’t the trailing dot just a red herring?

The RR is guaranteed to return a name which has an A/ record, therefore no 
search list will be exercised. period! The first lookup must 
succeed, by design.

Personal email.  hbh...@oxy.edu

Re: How to disable DNS lookups?

[Henry B (Hank) Hotz, CISSP]

> On Jul 25, 2017, at 6:30 PM, Roland C. Dowdeswell 
>  wrote:
> 
> And there are no KDCs configured in /etc/krb5.conf for the realm that
> you are querying, you will use DNS SRV RRs.  And, we think that once you
> have retrieved hostnames from DNS SRV RRs that they should be looked up
> only in DNS and not subjected to search lists and the like.

I’ll grant that this is a level of detail which standards don’t address, and 
where consensus may legitimately be impossible. FWIW my opinion is that an SA 
responsible for deploying/testing a machine may know nothing about krb5 config 
files, but need to point at a different infrastructure. 

For the scenario you describe where RRs are necessary, the poor SA will be very 
surprised if his entries in /etc/hosts are ignored. He will be especially 
surprised if the OS has an nsswitch.conf and he has put hosts before DNS.  (I 
might even have run into a scenario like that on Solaris 9, but I never 
completely debugged it so I’m not sure.)



I assume you at least have code in there to sort the RR entries by 
priority/weight before using the optimistically-provided A/ records.

Personal email.  hbh...@oxy.edu

Re: How to disable DNS lookups?

[Henry B (Hank) Hotz, CISSP]

I’m with Russ on this one, too. I’ve done /etc/hosts based deployments for 
robustness against DNS-failure scenarios.

POXIX getaddrinfo() does not require DNS. It’s an interface to the system and 
whatever it uses. The system should be configurable to use whatever name 
resolution is appropriate with as little surprise as possible.

> On Jul 25, 2017, at 11:58 AM, Roland C. Dowdeswell 
>  wrote:
> 
> On Tue, Jul 25, 2017 at 08:45:44AM -0700, Russ Allbery wrote:
>> "Roland C. Dowdeswell"  writes:
>> 
>>> In the longer term, we should likely stop using getaddrinfo(3) for names
>>> obtained from DNS SRV RRs and directly query DNS for them as this matches
>>> expectations.  That is: you wouldn't expect that if you find
>> 
>>> _kerberos._udp.my.realm IN SRV 0 0 88 foo.my.realm
>> 
>>> that an entry for foo.my.realm in /etc/hosts would then override the
>>> DNS for it.
>> 
>> Eh?  I *absolutely* would expect that and would consider it a bug if it
>> did not.  It is incredibly useful for testing to be able to temporarily
>> override the IP address of a host in /etc/hosts, and I expect all software
>> to honor that.
> 
> SRV RRs are essentially a generalisation of CNAMEs or perhaps MX records.
> It is counter-intuitive to expect that /etc/hosts will interpose in the
> middle of a lookup.

. . .


Personal email.  hbh...@oxy.edu

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

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

[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: Re-encrypt on change of master key

[Henry B (Hank) Hotz, CISSP]

https://www.mail-archive.com/heimdal-discuss@sics.se/msg00334.html

There’s also a long, historically-interesting, thread on migrating from MIT 
that includes an example.

> On Mar 14, 2017, at 11:51 AM, Henry B (Hank) Hotz, CISSP <hbh...@oxy.edu> 
> wrote:
> 
>> On Mar 14, 2017, at 9:43 AM, Adam Lewenberg <ada...@stanford.edu> wrote:
>> 
>> How do I re-encrypt the entries of the Heimdal KDC database if I want to 
>> change its master key?
> 
> Shut down all daemons on the master.
> 
> hprop --decrypt --stdout | hpropd --stdin
> 
> Restart all daemons.
> 
> That’s from memory. I think some other options may be needed, like keytab 
> files. I published this once in a presentation at one of the AFS best 
> practices workshops, but I don’t remember the year.
> 
> Personal email.  hbh...@oxy.edu

Personal email.  hbh...@oxy.edu

Re: Re-encrypt on change of master key

[Henry B (Hank) Hotz, CISSP]

How’s the contract coming?

> On Mar 14, 2017, at 9:43 AM, Adam Lewenberg  wrote:
> 
> How do I re-encrypt the entries of the Heimdal KDC database if I want to 
> change its master key?

Shut down all daemons on the master.

hprop --decrypt --stdout | hpropd --stdin

Restart all daemons.

That’s from memory. I think some other options may be needed, like keytab 
files. I published this once in a presentations at one of the AFS best 
practices workshops, but I don’t remember the year.

Personal email.  hbh...@oxy.edu

Re: Documentation of principal attributes

[Henry B (Hank) Hotz, CISSP]

AFAIK no. Most are obvious-ish: disallow all, the client and server ones. The 
hardware preauth one is just a placeholder for unimplemented functionality. JPL 
never made much use of them.

The ok as delegate one could be important for AD interoperability if you do a 
HTTP-Negotiate with web servers.

That’s just off the top of my head.

> On Feb 17, 2017, at 3:30 PM, Adam Lewenberg  wrote:
> 
> I am looking for documentation on the attributes that can be set on a 
> principal. The only thing I could find is page 233 of Jason Garman's 
> "Kerberos: The Definitive Guide" from 2003.
> 
> The kadmin page *lists* the attributes, but is there a man page or Heimdal 
> document page that *describes* what each attribute does and how it affects 
> the principal?
> 
> Thanks, Adam Lewenberg
> 

Personal email.  hbh...@oxy.edu

Re: Heimdal 7.1 and the sqlite backend

[Henry B (Hank) Hotz, CISSP]

> On Dec 22, 2016, at 8:53 AM, Jeffrey Hutzelman  wrote:

[. . .]

> kadmin -l is not a kdc and probably does not read kdc.conf.  I've not looked 
> at the current code to see how much of this was resolved, but we used to have 
> to patch a bunch of places to get kadmin -l and a bunch of the servers to 
> read kdc.conf.
> 
> — Jeff

+1  I recall the issue. Consistency would be nice.

Personal email.  hbh...@oxy.edu

Re: Heimdal 7 Release candidate 1 (7.0.1) available

[Henry B (Hank) Hotz, CISSP]

So it’s no longer possible to have non-numeric version numbers?

Please understand, I don’t really care. The new system is logical enough, even 
if unconventional. Just wondering what the actual reason was.

> On Nov 30, 2016, at 12:02 PM, Quanah Gibson-Mount  wrote:
> 
> --On Wednesday, November 30, 2016 2:56 PM -0500 Jeffrey Hutzelman 
>  wrote:
>> Good question.  I look forward to hearing the answer.
> 
> All of this was already discussed in the 10/19/2016 email from Roland 
> Dowdeswell email with the subject "Preparing for the Heimdal 7 Release".
> 
> 
> 
> --Quanah
> 
> 
> --
> 
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 
> 

Personal email.  hbh...@oxy.edu

Re: Heimdal 7 Release candidate 1 (7.0.1) available

[Henry B (Hank) Hotz, CISSP]

+1

> On Nov 30, 2016, at 12:09 PM, Harald Barth  wrote:
> 
> 
>>> While I’m asking, why are we renaming 1.7 as 7.x?
> 
> I am more exited that there is work going on on a new release than I
> am worried about the numbering now being 7.X instead of 1.7.X. As long
> as the new number is bigger than the old one everything should be fine.
> ;-)
> 
> Harald.

Personal email.  hbh...@oxy.edu

Re: Heimdal 7 Release candidate 1 (7.0.1) available

[Henry B (Hank) Hotz, CISSP]

Yay!

Did I miss a 7.0 release? Also why does 7.0.1rcX automatically become 7.1?

While I’m asking, why are we renaming 1.7 as 7.x?

> On Nov 29, 2016, at 8:02 PM, Viktor Dukhovni  
> wrote:
> 
> Dear Heimdal Community,
> 
> As promised in:
> 
>  
> http://kerberos.996246.n3.nabble.com/Preparing-for-the-Heimdal-7-Release-td46250.html
> 
> we are pleased to announce the availability of Heimdal 7 release candidate 1 
> (i.e. 7.0.1).
> 
> The release download page is:
> 
>   https://github.com/heimdal/heimdal/releases/tag/heimdal-7.0.1
> 
> The source tarball can be downloaded from:
> 
>   
> https://github.com/heimdal/heimdal/releases/download/heimdal-7.0.1/heimdal-7.0.1.tar.gz
>   
> https://github.com/heimdal/heimdal/releases/download/heimdal-7.0.1/heimdal-7.0.1.tar.gz.sig
> 
>   SHA256(heimdal-7.0.1.tar.gz)= 
> 85971537cd439082437234172ec2da11f6601730233b204724d9d8c0a3b42af7
>   SHA1(heimdal-7.0.1.tar.gz)= b33e2172cb7f77dc884afd4246905dab3bb62911
> 
> The signature key fingerprint is: E659 41B7 1CF3 C459 A34F  A89C 45E7 572A 
> 28CD 8CC8
> 
> Please test this release.  If no significant issues are found, this will 
> become
> Heimdal 7.1 in ~14 days time.
> 
> -- 
>   The Heimdal Release Team.

Personal email.  hbh...@oxy.edu