[17377] in Kerberos_V5_Development
Re: GSSAPI Proxy initiative
daemon@ATHENA.MIT.EDU (Tom Yu)
Thu Nov 3 17:58:20 2011
To: Trond Myklebust <Trond.Myklebust@netapp.com>
From: Tom Yu <tlyu@mit.edu>
Date: Thu, 03 Nov 2011 17:58:12 -0400
In-Reply-To: <1320352784.18396.109.camel@lade.trondhjem.org> (Trond
Myklebust's message of "Thu, 03 Nov 2011 16:39:44 -0400")
Message-ID: <ldvsjm4kgwb.fsf@cathode-dark-space.mit.edu>
MIME-Version: 1.0
Cc: dhowells <dhowells@redhat.com>, Nico Williams <nico@cryptonector.com>,
linux-nfs@vger.kernel.org, krbdev <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Trond Myklebust <Trond.Myklebust@netapp.com> writes:
> Linux already has per-user, per-process and per-thread keyrings which
> offer a high security storage solution for keys. The problem with those
> is that they are difficult to use in an asynchronous context when the
> original user's process/thread context is no longer available to us.
>
> Ideally, though, that's what we'd like to see used.
Perhaps I misunderstand what you're proposing to use the keyring for,
but I would like to clarify a few things.
Opaque key storage is probably not the right abstraction level to
represent the kind of privilege separation we want here. It's clearly
already possible to use the Linux keyring, TPM, smart cards, etc. to
achieve opaque key storage.
One of the original goals is privilege separation. The GSS proxy can
allow an unprivileged process to perform specific restricted
operations with key material such as a host key, instead of the mostly
unrestricted encryption, decryption, etc. access that you would get
with an opaque or unextractable key model. The proxy could limit the
client's use of the key to gss_accept_sec_context(), without allowing
the sort of generalized cryptographic operations that would allow the
client to, say, forge a PAC signature.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
