[OpenAFS-devel] crypto backend and integration for rxgk

[Benjamin Kaduk]

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