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:
>>
>>> 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.
>>
>> 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.
>
> 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
>>
>> 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.
> 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.
>
> 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.
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
