gssapi, crypto and afs/rxrpc

[David Howells <dhowells@redhat.com>]

Hi Herbert, Dave, Trond,

I've written basic gssapi-derived security support for AF_RXRPC:

	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-rxgk

I've borrowed some bits from net/sunrpc/auth_gss/ but there's a lot in there
that is quite specific to the sunrpc module that makes it hard to use for
rxrpc (dprintk, struct xdr_buf).

Further, I've implemented some more enctypes that aren't supported yet by
gssapi (AES with sha256/sha384 and Camellia), and that requires some changes
to the handling as AES with sha384 has a 24-byte checksum size and a 24-byte
calculated key size for Kc and Ki but a 32-byte Ke.

Should I pull the core out and try to make it common?  If so, should I move it
to crypto/ or lib/, or perhaps put it in net/gssapi/?

There are two components to it:

 (1) Key derivation steps.

     My thought is to use xdr_netobj or something similar for to communicate
     between the steps (though I'd prefer to change .data to be a void* rather
     than u8*).

 (2) Encryption/checksumming.

     My thought is to make this interface use scattergather lists[*] since
     that's what the crypto encryption API requires (though not the hash API).

If I do this, should I create a "kerberos" crypto API for the data wrapping
functions?  I'm not sure that it quite matches the existing APIs because the
size of the input data will likely not match the size of the output data and
it's "one shot" as it needs to deal with a checksum.

Or I can just keep my implementation separate inside net/rxrpc/.

David

[*] That said, I'm not exactly sure how the sunrpc stuff works, so this might
not work for that.