Re: iprop: Problem forcing complete database sync
On October 6, 2017 5:56:22 AM EDT, Harald Barth wrote: > >Removing that without putting something else in place (and I would say >not only s->version == 0 but even current_version == 0 should trigger >a send_complete) was probably a bad idea. It shouldn't be needed. First, a full dump is automatically triggered if the master doesn't have enough log entries to bring the slave from its current version to the master version. so if a slave us at version 0, you either get a complete log replay out a full dump, either of which is sufficient. In practice, it should always be a full dump, because the log should never contain an entry for version 1. It's also not necessary and in fact potentially harmful to check the master's version for 0. A real database can never be at version 0, so if you see that, something is wrong, and copying that database wholesale to another server is probably a bad idea. Remember that truncation does not zero the version. It throws away the existing log entries and writes a new log containing a single transaction with a newer version than the existing log. This forces a full update for any slave that was not already up to date. >I think the log can be at version 0 (which means "invalid, please >recover") but the database should not be able to be at version 0. only an empty, never-initialized log can be at version 0. databases don't have versions; they're entirely an artifact of the log >> Unless I am missing something this would mean that if something like >the code >> above was added back, truncating the log to version 0 would make all >slaves >> fetch the complete database over and over again until a modification >bumps the >> version at the master. > >That would be unfortunate ;-) it would, but truncating the log doesn't set the version to 0. >Harald.
Re: kinit error message (Heimdal 7.4.0)
On October 5, 2017 12:06:51 PM EDT, Greg Hudson wrote:
>On 10/05/2017 07:52 AM, Harald Barth wrote:
>> And because the return code ret is the same as the error_code in the
>> context, krb5_get_error_message() just copies the string from the
>> context. However, if krb5_get_error_message() does its own lookup of
>> -1765328383 it gets "Client's entry in database has expired" which is
>> more like it. But where does "No ENC-TS found" come from and why is
>it
>> "better" than the own lookup?
>
>I didn't find anything like "No ENC-TS found" in the Heimdal source
>code, so my best guess is that this is coming from
>rd_error.c:krb5_error_from_rd_error() which does:
>
>ret = error->error_code;
>if (error->e_text != NULL) {
>krb5_set_error_message(context, ret, "%s", *error->e_text);
>} ...
>
>If my theory is correct, the KDC is sending unhelpful e_text and/or
>Heimdal is too trusting in using the e_text in preference to the string
>corresponding to the error code.
Both, I think. kinit (and other clients) ought to report something like
"error_message (e_text)", unless the e_text is empty or the same as the message
for the error code. of course, more complex variations are possible, what with
both locally- and KDC-generated error codes and additional messages. but just
blindly using the e_text and nothing else is clearly wrong.
That said, the KDC should not be sending this particular e_text in this
situation. I'll bet there's a loop that looks for suitable PA data, and that
message gets produced if it finishes without finding any, even though the
problem is something else entirely.
-- Jeff
In this case, concatenating the error
>code string with the e_text would produce a better result but not an
>ideal one, as "No ENC-TS found" shouldn't appear in the error message
>at
>all.
Re: Weird cross-realm behaviour after upgrade to Heimdal 7.3
On July 10, 2017 8:16:05 AM EDT, Andreas Haupt wrote: >... it "succeeds" in the CERN.CH case: > >Jul 10 13:27:36 fred-vm1 kdc[12044]: TGS-REQ aha...@ifh.de from >IPv4:141.34.15.17 for host/lxplus040.cern...@ifh.de [canonicalize, >renewable, forwardable] >Jul 10 13:27:36 fred-vm1 kdc[12044]: Searching referral for >lxplus040.cern.ch >Jul 10 13:27:36 fred-vm1 kdc[12044]: Server not found in database: >krbtgt/cern...@ifh.de: Success > >"Server not found" == "Success"? Is this really the expected answer? I >would >guess, no - but not really sure ... This is a bug in the kdc, or possibly two bugs. First, the database lookup failed and no entry was returned, but the error code was not set and so remained zero, which com_err translates as "Success". Second, the kdc is not sending any response at all. That causes the client to eventually time out and try another kdc. When it runs out of kdcs, it reports an error (unable to contact any kdc in realm). you can confirm this by watching traffic between your client and kdc on port 88, using your favorite packet-capture tool. -- Jeff
Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"
> > 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. No, only people who build Heimdal are confronted with it at build time. Most people will use packaged versions, not build their own.
Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"
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: Can ipropd-master service not do reverse DNS lookups?
On Fri, 2017-04-07 at 13:41 -0700, Adam Lewenberg wrote: > It would be nice if I could start ipropd-slave with an option to set > the iprop principal to something other than `hostname`. I agree, that would seem to be a useful feature. As would the ability to set the ipropd-master service principal name, for similar reasons. -- Jeff
Re: Can ipropd-master service not do reverse DNS lookups?
On Fri, 2017-04-07 at 12:31 -0700, Adam Lewenberg wrote: > I am trying to set up iprop replication for a slave KDC running on a > container in an EC2 instance in Amazon Web Services (AWS). We are > running Heimdal 1.5.2. > > When the slave ipropd-slave connects to the master, it looks like > the > master is doing a reverse DNS lookup on the slave's IP address and > getting one of those long Amazon addresses (e.g., > ec2-52-45-91-42.us-west-2.compute.amazonaws.com). It then looks for > the > principal "iprop/ec2-52-45-91-42.us-west-2.compute.amazonaws.com" in > its > database. Are you sure that's what's happening? ipropd connections are made by the slave to the master, and the authentication runs in that direction. The master can't just make up a principal name; it has to use the one in the ticket actually presented by the slave. Looking at (fairly old) code, what appears to be the case is that ipropd-slave constructs its own client principal name by calling krb5_sname_to_principal with a NULL hostname (which means to use the local hostname). Unfortunately, the library persists in taking that as license to perform forward and reverse DNS name lookups in deriving the Kerberos principal name, despite over a decade of advice to the contrary, including RFC4120 which states "Implementations of Kerberos and protocols based on Kerberos MUST NOT use insecure DNS quereies to canonicalize the hostname components of service principal names."* So no, there's no way to avoid using a hostname. However, I believe you should be able to suppress the reverse DNS resolution step by setting "rdns=false" in the libdefaults section of krb5.conf. After that, it should use whatever `hostname` returns (at least, if that's fully qualified). -- Jeff (*) No, I'm not even slightly bitter over this failure of every major Kerberos implementation to avoid what I consider to be a significant security issue. After all, it's not like they were all there when RFC4120 was written...
Re: How to quickly get a snapshot of the Heimdal DB file
On Sat, 2017-04-01 at 16:59 -0700, Adam Lewenberg wrote: > I am looking for a quick way to get a snapshot of the Kerberos > database > file. > > The most obvious way to do this would be to shutdown the kerberos > service, copy the file, and restart the service. This could be done > on > one of the replicas, perhaps one that does not get actual > authentication > requests. > > Is there a faster way? For example, some database systems (e.g., MS > SQL) > have the ability to go into and out of a "quiescent" state faster > than a > full service stop/start to facilitate this sort of thing. Does > Heimdal > have something like this? Or is the full service restart the > only/best > option? hprop --stdout will produce a database dump that you can reload later if needed. kadmin -l list -l '*' will produce a verbose human-readable list of all the principals in the database and their attributes. Note that this is not particularly machine-readable and does not include keys, so it's not a backup. -- Jeff
Re: Re-encrypt on change of master key
On March 14, 2017 6:32:13 PM EDT, Nico Williams wrote: >On Tue, Mar 14, 2017 at 03:26:57PM -0700, Henry B (Hank) Hotz, CISSP >wrote: >> Probably, but encrypting the key material separately doesn’t seem >like a bad thing. > >It's a waste of CPU cycles. It adds no real protection _by itself_ >unless you're keying in the master key on daemon startup. it provides some additional protection against disclosure of the keys while in transit (i.e. during propagation). it doesn't protect against copy/paste attacks or do much of anything for a database at rest
Re: Kerberos authentication to load-balanced services in AWS and reverse DNS
On January 6, 2017 10:21:18 AM EST, Adam Lewenberg wrote: >1. One option is to require all of customers to use Kerberos with the >reverse DNS lookup disabled. How much extra risk do we take on by not >using the reverse DNS check? Security-wise, none at all. The reverse DNS lookup is not a feature of the Kerberos protocol, and in fact is expressly prohibited, because it allows an attacker to substitute a different Kerberos service principal name than the one you were expecting, potentially causing you to trust an a service operated by the attacker. In practice, most Kerberos and GSSAPI implementations do the reverse lookup anyway, because it makes it more convenient when a service runs on a host with multiple aliases. It's only been relatively recently that it's become possible to reliably turn it off. Fortunately, the attack is mostly theoretical -- it doesn't work if you're authenticating the server some other way (for example, by verifying its X.509 certificate or ssh host key), and it doesn't matter unless the client is trusting the server in some way (for example, by sending it a password or relying on it to make some authorization decision). The problem you may be more likely to run into is that the server might not actually be able to accept tickets for more than one service principal at a time. That is, it can be configured to accept the server's own principal name or the shared one, but not both. Cyrus SASL had this problem for a long time, and I'm not sure it ever got fixed. If you're willing to patch, the fix for that problem is actually pretty simple -- instead of acquiring GSSAPI acceptor credentials, the server's call to gss_accept_sec_context() should simply pass GSS_C_NO_CRED in place of the credential argument. Then the server will accept tickets for any principal in its keytab. -- Jeff
Re: Heimdal 7.1 and the sqlite backend
On December 22, 2016 8:25:08 AM EST, Harald Barth wrote:
>
>I have "limited" (read "so far no") success in running heimdal with
>the sqlite db backend.
>
>I'm trying to get the sqlite backend to work lik this in
>/etc/krb5.conf and /var/heimdal/kdc.conf:
>
>[kadmin]
> database = {
>dbname = sqlite:/var/heimdal/heimdal.sqlite
>realm = TEST
> }
> require_preauth = true
>[kdc]
> database = {
>dbname = sqlite:/var/heimdal/heimdal.sqlite
>realm = TEST
> }
> require_preauth = true
>
>Which resulted in a file named /var/heimdal/heimdal.sqlite that looks
>like an sqlite database and an error when doing the init with kadmin
>-l:
>
># kadmin -l
>kadmin> init TEST
>kadmin: hdb_open: dbopen (/var/heimdal/heimdal): Inappropriate file
>type or format
>kadmin>
>
>So somethiung I'm missing here, help or pointers to documentation how
>to set this up appreciated.
>
>Or what alternate backend do think is solid and stable and why? ;-)
>I am not planning to use ldap =;-)
>
>Harald.
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
Re: 7.1 compile errors when using libintl at non standard location (Was: Heimdal 7.1 release announcement)
On December 22, 2016 7:39:24 AM EST, Harald Barth wrote: >My configure says --with-libintl-include=/usr/local/include but the >compile line to array.c does not include a -I/usr/local/include, thus: What happens if instead you use --with-libintl=/usr/local ?
Re: Heimdal 7 Release candidate 1 (7.0.1) available
On Wed, 2016-11-30 at 11:38 -0800, Henry B (Hank) Hotz, CISSP wrote: > Yay! > > Did I miss a 7.0 release? Also why does 7.0.1rcX automatically become > 7.1? No. Apparently the next real release will be 7.1, and they're spelling "7.1 release candidate 1" as "7.0.1". I'm not sure what the thinking is behind this odd numbering scheme. It would be a whole lot easier to understand if the first RC were 7.0rc1 and the first real release were 7.0. > While I’m asking, why are we renaming 1.7 as 7.x? Good question. I look forward to hearing the answer. -- Jeff
Re: Preparing for the Heimdal 7 Release
On Wed, 2016-10-19 at 13:02 -0700, Russ Allbery wrote: > January 5th is the soft freeze, beyond which new packages cannot be > introduced into Debian stretch. This is probably the last possible date > for Heimdal 7 making it into the next Debian stable release. If there is > no stable release of Heimdal (with security support) by this point, and > more realistically several weeks prior to this for people to package it > (assuming the Heimdal packaging team in Debian is still willing to package > Heimdal), Debian stable will ship without Heimdal. I'd really like to avoid that happening. Last I checked, Heimdal was being maintained in Debian by Brian May. If he's no longer interested in doing so, and assuming we can get a stable release in a timely fashion, I can probably scare up some cycles to get the packaging in shape. Someone else will have to do the uploads, though... -- Jeff
