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