On Thu, 2 May 2013, Simon Wilkinson wrote:
On 2 May 2013, at 21:58, Benjamin Kaduk wrote:
On Wed, 1 May 2013, Simon Wilkinson wrote:
On 1 May 2013, at 17:24, Benjamin Kaduk wrote:
I think it's actually a little bit more complex than that - at least if
you want to be able to make full use of libkrb5.
You have something like (excuse the poor ASCII art):
It works great-- I almost asked for a picture, but decided not to ask
since that might be too much work.
rxgk
|
---------------------------
| | |
MIT-krb5 Heimdal-krb5 liboafs_rfc3961
|
|
----------------------------------
| | |
liboafs_hcrypto OpenSSL custom kernel shim
Now, because liboafs_rfc3961 and Heimdal's libkrb5 have identical APIs,
you only have to have this level of complexity if you want to be able to
use MIT's krb5 crypto routines - otherwise you can use a single API and
work with both our in tree library, and out of tree Heimdal.
Okay, that helps a lot -- it sounds like I want to keep my mic_in_key()
and friends and rename with an rxgk prefix; that will be the top of the
tree in the picture. The MIT/heimdal API could be done at the
preprocessor level within a single source file or as separate source
files. If using the heimdal API via liboafs_rfc3961, then whatever we
link to will know which backend to pull in.
Hmm, using a different crypto backend for libafsrfc3961 in the kernel
and in userland could be annoying with the current build system; I'm
not sure how that would work.
I don't see why - all of our kernel objects are built completely
separately from the userspace ones.
Do we already build separate libraries that get linked into the kernel
module? I thought it was just a bunch of objects all linked together --
the annoying part would be unwrapping the library build into separate
object files.
In my dev work, I went with something intended to be minimally invasive to the rest of
the tree (to make a future API change easier), namely define an "rxgk rfc3961 crypto
api" with things like mic_in_key(), encrypt_in_key(), etc.. Those are obviously not
final names, but one reason I started this thread is to decide whether they should be
renamed to rxgk_mic_in_key() or calls to them should be replaced by something else, such
as this purpoted rfc3961 library.
Well, we already have such a rfc3961 library - there's nothing purported
about it. It's the only one we're going to get in kernel, so I think
using it (or something similar) in userspace makes sense. It also means
that we're not reinventing the wheel. This library is part of Heimdal -
and as Heimdal updates its implementation, we can easily incorporate
those changes.
It's purpoted because it doesn't actually appear as a real library (.so or
.a) that I can link to a userland application :) I'd be happy to see it
become more real in that sense, of course.
per-fileserver key
Custom location, private to the fileserver
I'm not sure this is best; we already have the KeyFileExt infrastructure for
storing general key types, and it would seem to make sense to reuse it if we
can.
It's also worth considering that an implementation may decide to make
its fileserver keys completely ephemeral, and register a new one with
the vlserver each time the fileserver restarts.
Sure -- but we're talking about an implementation, now. Do we think it's
a good idea for OpenAFS to do this or offer it as an option? Regular
periodic rekeying should probably be a best practice, though this may not
necessarily be the best way to make it so.
My thinking was that a given server would either be a "departmental"
fileserver with its own key (or a per-department key), or it would be a
central fileserver running on the same machine as the dbservers.
(Centrally managed fileservers without colocated dbservers are also
possible, of course.) In that framework, we could have the fileserver
always look in the KeyFileExt for its key -- for a departmental
fileserver, the departmental key would be in the KeyFileExt; on a
centrally managed server, it would just reuse the cell-wide key that's
already in the KeyFileExt.
Doing this transparently doesn't work - the fileserver needs to know
whether it is departmental or not, otherwise it can't take the correct
action when asked to do things like VolForward.
The knowledge of whether a fileserver is departmental could of course be
stored in a separate flag or configuration setting, independent of where
the server stores its key material.
Private to the fileserver. If you're serialising callback state to
disk, then you also need to serialise these keys to disk.
Yup. There is again the argument for reusing the KeyFileExt
infrastructure, but the way to do so is less clear to me here.
You're going to be storing a key per client that you have outstanding
callbacks for - I can't see any way of doing this with KeyFileExt.
It would have to be some hack like overloading kvno to be the rx cid ...
probably not worth it.
-Ben
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
