gssapi, crypto and afs/rxrpc

gssapi, crypto and afs/rxrpc

[David Howells]

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.

Re: gssapi, crypto and afs/rxrpc

[Herbert Xu]

On Fri, Oct 16, 2020 at 05:18:26PM +0100, David Howells wrote:
>
> 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.

Generally it makes sense to create a Crypto API for an algorithm
if there are going to be at least two implementations of it.  In
particular, if there is hardware acceleration available then it'd
make sense.

Otherwise a library helper would be more appropriate.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: gssapi, crypto and afs/rxrpc

[J. Bruce Fields]

On Fri, Oct 16, 2020 at 05:18:26PM +0100, David Howells wrote:
> 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/.

I'd love to share whatever we can, though I'm not really sure what's
involved.  Certainly some careful testing at least.

It's been about 15 years since I really worked on that code.  I remember
struggling with struct xdr_buf.  The client and server support
zero-copy, so requests and replies are represented by a combination of a
couple of linear buffers plus an array of pages.  My memory is that the
(undocumented) meanings of the fields of the xdr_buf were different for
request and replies and for server and client, and getting them right
took some trial and error.

--b.