[38493] in Kerberos

home help back first fref pref prev next nref lref last post

Re: Data privacy in KDC

daemon@ATHENA.MIT.EDU (Yegui Cai)
Mon Mar 4 12:38:16 2019

MIME-Version: 1.0
In-Reply-To: <2116f97d-5a7a-4e78-f5e1-e0d68165ce3e@mit.edu>
From: Yegui Cai <caiyegui@gmail.com>
Date: Mon, 4 Mar 2019 12:37:37 -0500
Message-ID: <CAJYMFR76_NNBrZB4mFBD=o9Rm_DZYoWYHTV=866nUtT6Ccx64A@mail.gmail.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu

Hi Greg.
Thanks a lot for your reply.

A further question regarding 3. The database files (principle,
principal.kadm5) are not encrypted, am I right?

Best,
Yegui

On Mon, Mar 4, 2019 at 12:16 PM Greg Hudson <ghudson@mit.edu> wrote:

> On 3/4/19 11:45 AM, Yegui Cai wrote:
> > 1. If I have multiple tenants sharing the same KDC (say, a tenant is
> mapped
> > into a realm), how KDC make sure that the data is segregated between
> realms?
>
> The best option is probably to run separate KDC processes for each
> realm, with each process listening to a different port.
>
> It is possible for a single KDC process to serve multiple realms, but it
> is not a common configuration, and kadmind doesn't have the same
> facility.  In this configuration, each realm still has its own separate
> database, and the KDC will only access the database for the request that
> is currently processing (based on the realm field of the KDC-REQ-BODY).
>
> > 2. Similar questions regarding logs. Is there any way to segregate logs
> > between different realms?
>
> With separate KDC processes, each can have its own kdc.conf file with
> different [logging] directives.
>
> With one KDC process serving multiple realms, I don't believe there is
> any way to keep the logs separate.
>
> > 3. If I use the default data storage (Berkeley DB if my understanding is
> > correct), how data is encrypted at rest?
>
> Principal long-term keys are encrypted in a master key; the master key
> is typically located in a stash file separate from the KDB so that it
> can be backed up more securely (or not at all).  Other principal
> metadata is not encrypted.
>
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

home help back first fref pref prev next nref lref last post