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.
