Subject: [kitten] Any Interest in a Key Delivery Service?

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Tue, 12 Sep 2017 17:10:05 -0700

I have run into a couple of cases where I wanted the kdc to provide -- not a service ticket -- but an actual encryption key for some data at rest. (Specifically an encrypted disk or a database.)

There are obvious problems to be addressed, or at least agreed to. But just generally is it worth talking about or should we leave this space to the HSM folk?

Personal email.  [email-masked]

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 12 Sep 2017 21:30:56 -0400

>I have run into a couple of cases where I wanted the kdc to provide --
>not a service ticket -- but an actual encryption key for some data at
>rest. (Specifically an encrypted disk or a database.)

It seems like a lot of people use KMIP for that.  I think it would make
sense to be able to use Kerberos to authenticate to KMIP, but in my brief
interaction with some people who claimed to be KMIP people, they did
not understand why I would want that (there is a super brief mention
of Kerberos in the protocol document, but if you read it closely clearly
they weren't serious about doing Kerberos authentication for real; the
protocol would need a lot more specification to be something you could
implement).

--Ken

---

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Tue, 12 Sep 2017 22:11:50 -0700

> On Sep 12, 2017, at 6:30 PM, Ken Hornstein <[email-masked]> wrote:
> 
> not understand why I would want that

Bashes head against wall. . .

> (there is a super brief mention
> —Ken

OK, so should we produce a spec that tells them how to do it, or would that just trigger NIH (not invented here)?

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 13 Sep 2017 09:31:54 -0400

>OK, so should we produce a spec that tells them how to do it, or would
>that just trigger NIH (not invented here)?

Good question!  In my experience the issues are a) lack of specification,
and b) getting people to implement the specification.

I do think it would be .... not worth the effort to go through the IETF
process to produce something for KMIP.  You need to work in their space
(OASIS).

--Ken

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 13 Sep 2017 20:17:25 -0500

> sense to be able to use Kerberos to authenticate to KMIP, but in my brief

I don't know much about KMIP, but it does seem like there is not very
much that would tie such a service to be part of and/or colocated with
a Kerberos KDC.  This functionality ought to be providable by a
"generic kerberized service", i.e., something running elsewhere than the
KDC that authenticates via kerberos.  It could require initial tickets
(e.g., via kinit -S kmip/hostname) without needing to be the KDC, and
there's probably a lot of advantage in decoupling the protocol and
implementation of the key-management service and the KDC.

-Ben

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 13 Sep 2017 22:02:31 -0400

>KDC that authenticates via kerberos.

Right, that was what I was suggesting.  You can find the KMIP specification
here:

	httb:/docs.oasis-open.org/kmip/spec/v1.2/kmip-spec-v1.2.html

If you look at section 2.1.2, they have a BRIEF mention of Kerberos
where it talks about the Credential structure.  But it's not clear to me
at first glance if there is a spot in the protocol for an AP-REP, much
less a potentially-unlimited series of round trips that you could get
via GSSAPI.  I only mentioned KMIP because that is a protocol designed
to generate, store, and retrieve keys for use in EXACTLY the situation
originally mentioned (it is big in the data at rest world).  It might be
more fruitful to try to adapt KMIP to your needs rather than shoehorn
the KDC into that role.

--Ken

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 14 Sep 2017 09:03:36 -0400

On 9/13/2017 10:02 PM, Ken Hornstein wrote:
> 	http:/docs.oasis-open.org/kmip/spec/v1.2/kmip-spec-v1.2.html
> 

As far as I can tell, before GSS-API or Kerberos could be used to
authenticate to a KMIP service, TLS would need to be updated to support
Kerberos authentication.  At the moment, KMIP requires TLS 1.2.  See

http://docs.oasis-open.org/kmip/profiles/v1.2/os/kmip-profiles-v1.2-os.html

Alternatively, a new GSS-API protected network protocol could be
developed as a front-end to the KMIP store.  For example, an RXGK
protected RX RPC service would be interesting.

Jeffrey Altman

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 14 Sep 2017 12:15:04 -0400

>http://docs.oasis-open.org/kmip/profiles/v1.2/os/kmip-profiles-v1.2-os.html

My reading of the spec is that you would have to create a new profile
(my dumb reading is that TLS is required for the "basic" authentication
suite, and you'd define your own authentication suite).  That's that
part that I suspect would be a giant, awful slog through the OASIS
standardization process, which would probably one of those fruitless,
soul-draining exercises.  It might NOT be, but I'm pretty sure it would
be an uphill battle.

--Ken