[OpenAFS-devel] crypto backend and integration for rxgk

[Benjamin Kaduk]

Hi all,

It seems like the core rxgk specification is reaching completion, so it is 
probably time to start thinking about how to integrate it into OpenAFS. 
rxgk adds a number of additional cryptographic keys and encryption types 
that are not present for rxkad, and this is an issue that has come to the 
forefront for me.  The below is mostly thoughts and not explicit 
questions, so replies of "yes, that makes sense" would be helpful, as well 
as criticisms/disagreement.

While doing development work for rxgk, I have just been using dummy 
userspace applications as client and server, backending to libkrb5 for the 
RFC3961 crypto operations.  Obviously this is not a general solution for 
the crypto, as libkrb5 is not available in the kernel, and I am given to 
understand that the team working on the Windows client would really like 
to avoid having to link libkrb5 everywhere.  (I didn't get an 
understanding of why, but that seems off-topic for this discussion.) 
Furthermore, it seems like we have been going down the path of importing 
such bits of hcrypto as we need for functionality, and the expectation is 
that we will import more of hcrypto for rxgk support.  On the other hand, 
things which already link against libkrb5 should perhaps not also link 
against the in-tree hcrypto, and could use libkrb5 for their rxgk crypto 
as well.  (An external libkrb5 with an enctype that is not available in 
our in-tree hcrypto seems possible, but unlikely to be a compelling use.)
The incompatibility between heimdal's libkrb5 and MIT's libkrb5 also comes 
into play.

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.

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.)  The client will 
eventually end up with a ~raw rfc3961 key, and we can use those internally 
without GSS.  Printed tokens can use the raw key, and have an empty 
identity list which avoids the need for gss_display_name()/etc, so they 
should be able to avoid a GSS dependency.  I haven't fully worked through 
how the acceptor setup will work, though.


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
cell-wide shared key (need not be the vlserver acceptor creds)
per-fileserver key
[key for securing extended callbacks, which may or may not be able to 
just live in memory]
[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.  He's already added support for a KeyFileExt, which knows 
about keys with key type "afsconf_rxgk" and has enough version/type 
stamping to hold a kvno and encryption type.  However, there is no way to 
differentiate between a cell-wide shared key or a per-fileserver key 
within a single KeyFileExt, if both keys have the type afsconf_rxgk.  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.  It does seem like it 
would make using unique keys for non-fileserver, non-dbserver services 
harder, though.

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.

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.

-Ben