[OpenAFS-devel] crypto backend and integration for rxgk

[Simon Wilkinson]

On 2 May 2013, at 21:58, Benjamin Kaduk wrote:

> On Wed, 1 May 2013, Simon Wilkinson wrote:
>=20
>>=20
>> On 1 May 2013, at 17:24, Benjamin Kaduk wrote:
>>=20
>>> As such, it seems like we should have the ability for an rxgk-using =
tool/utility/etc. to use either hcrypto or libkrb5 for its crypto =
backend. This would also leave open the possibility of using an OS =
kernel's crypto implementation instead of hcrypto, though that would =
require per-OS work and is not needed for an initial implementation.
>>=20
>> I think you actually need to split things up more than this. You've =
got the library that provides the RFC3961 functionality, and then the =
library that provides the raw crypto operations. I think it's really =
important to consider the non-krb5 use cases. People will want to link =
against non-krb5 GSSAPI libraries, and we have to make that possible =
without requiring that they bring in a large amount of krb5 baggage with =
them.
>=20
> Let me check that I'm reading this correctly: the idea is that OpenAFS =
has an interal "rfc3961 library" which exposes an API for the RFC 3961 =
crypto operations (and this API happens to look like the heimdal API for =
historical reasons).  rxgk would link against libafsrfc3961, but what =
libafsrfc3961 uses as a backend is configurable, and could be the =
in-tree hcrypto, an out-of-tree krb5 solution, the kernel's crypto =
layer, etc.

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):

            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.

> 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.

> 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.

>>> per-fileserver key
>>=20
>> Custom location, private to the fileserver
>=20
> 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.

> 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.

>> Private to the fileserver. If you're serialising callback state to =
disk, then you also need to serialise these keys to disk.
>=20
> 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.

Cheers,

Simon.