[OpenAFS-devel] crypto backend and integration for rxgk

[Simon Wilkinson]

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

My original goal, which is partially implemented in the OpenAFS tree was =
to provide hcrypto as a general purpose crypto library, which could be =
replaced by anything which provides a compatible interface (OpenSSL is =
the obvious candidate here, although I believe that there are also shims =
which would allow NSS to be used to). We then layer on top of this a =
rfc3961 krb5_crypto library, which at the moment is only used in kernel =
space. The way the code is structured, you can also swap this out for a =
compatible (Heimdal) libkrb5 if you so wish.

I didn't really consider the MIT code because at that point the MIT =
crypto code was an unholy mess, and my main priority was to have =
something that could be loaded into the kernel with as little bother as =
possible. So the whole implementation, both kernel and userspace was =
built around the Heimdal krb5_crypto API. I still think this makes sense =
- base your implementation around the kernel API, and support userspace =
MIT through a shim layer if required.

Kernel crypto implementations are sadly not available to us at all on =
Linux - all of the kernel crypto APIs are hidden behind the =
license-wall. Being able to use them on other platforms was always part =
of the goal - but I think it should be possible to do so by plugging in =
at the hcrypto layer.

> There is also the question of GSS integration for key negotiation.  I =
have the impression that, just as we currently try to limit the exposure =
of libkrb5 to aklog and asetkey and similar, we will want to limit the =
exposure of the GSS-API library in the tree.  (That is, we don't want to =
link every executable we build against a gssapi library.)

That would be the ideal, yes. Whether it is practical or not, with our =
current library structure, is another matter. We don't really have any =
separation between client libraries and server libraries, so it is very =
easy for something that is required on the server to end up also being =
required on the client just through library dependencies. This is more =
of an issue for things like extended authentication names, and support =
in the UserList, and so on, than for core rxgk.

> The question of which keys go where is a pretty big one.
> At a glance, keys to worry about include:
> GSS acceptor creds for the vlserver
> GSS acceptor creds for bosserver
> GSS acceptor creds for other non-dbserver, non-fileserver bits

These all live in the default gss acceptor location. Doing anything else =
makes your binary mechanism dependent, which it would be best to avoid.

> cell-wide shared key (need not be the vlserver acceptor creds)
KeyFileExt

> per-fileserver key

Custom location, private to the fileserver

> [key for securing extended callbacks, which may or may not be able to =
just live in memory]

Private to the fileserver. If you're serialising callback state to disk, =
then you also need to serialise these keys to disk.

> [client keys, which I won't talk about further here]
>=20
> Simon had some thoughts on Jabber a couple weeks ago (2013-04-18.txt); =
in particular the idea that the GSS acceptor creds (e.g., the =
afs-rxgk/_afs.cellname krb5 keytab) can be different than the cell-wide =
shared key.

This is really important. You need this in order to be able to support =
non-krb5 GSS mechanisms. Bear in mind that for some mechanisms (GSI, for =
example), the acceptor credential does not contain a symmetric =
encryption key - so you have to provide a mechanism through which such a =
key can be obtained.

> This is probably fine, it just solidifies the implementation detail =
that the per-server key for a fileserver located on the same machine as =
a dbserver will be the same key as the cell-wide shared key.

There's no reason why such a fileserver should use the cell-wide shared =
key, so I'm not sure where this implementation detail has come from. The =
location of a fileserver is immaterial when it comes to the keys that it =
uses.

> The KeyFileExt format has 32 bits of integer for the key type; I =
wonder if we want to get more specific than "afsconf_rxgk" and go to =
"afsconf_rxgk_cellwide", "afsconf_rxgk_fileserver", etc., it could end =
up simplifying some things.

I would rather not store these within KeyFileEx. My intent had always =
been that KeyFileEx would be used in a similar way to the way in which =
KeyFile is used today - so it would get copied around machines with =
equal privilege. Fileserver keys are private to the fileserver - they =
should be stored somewhere that only the fileserver (and volserver, but =
that really is an implementation detail) can gain access to them.

> There's also the question of where to put the GSS acceptor =
credentials. I'm not sure that I like the idea of using the mechanism =
default (for kerberos, the system's krb5.keytab, but we are not limited =
to the krb5 mechanism); if we did stay with that, I would want to have =
each acceptor specify which name it is accepting as.  My preference =
would be to have a separate credentials store for each service/acceptor, =
but not specify a name within that credentials store.  This does have =
the drawback of using mechanism-specific functionality (e.g., =
krb5_gss_register_acceptor_identity) which would need to be =
conditionalized somehow, probably at build time.

I think we want to be able to use the same binaries with different GSS =
mechanisms - so I think you need to use the mechanism default. I also =
can't see any reason for not specifying the acceptor name - what to use =
is clearly defined, in particular for the AFS-3 acceptor, so I can't see =
any value at all in blindy accepting anything that's in a particular =
keytab.

Cheers,

Simon