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