Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley
        Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United
        Kingdom.
        Registered in England and Wales under Company Registration No. 3798903
From:   David Howells <dhowells@redhat.com>
To:     herbert@gondor.apana.org.au, davem@davemloft.net,
        trond.myklebust@hammerspace.com
cc:     dhowells@redhat.com, linux-crypto@vger.kernel.org,
        linux-nfs@vger.kernel.org, linux-afs@vger.kernel.org,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: gssapi, crypto and afs/rxrpc
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1444463.1602865106.1@warthog.procyon.org.uk>
Content-Transfer-Encoding: quoted-printable
Date:   Fri, 16 Oct 2020 17:18:26 +0100
Message-ID: <1444464.1602865106@warthog.procyon.org.uk>
Precedence: bulk

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=3Drxrpc-rxgk

I've borrowed some bits from net/sunrpc/auth_gss/ but there's a lot in the=
re
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 chang=
es
to the handling as AES with sha384 has a 24-byte checksum size and a 24-by=
te
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 mov=
e 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 communica=
te
     between the steps (though I'd prefer to change .data to be a void* ra=
ther
     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 A=
PI).

If I do this, should I create a "kerberos" crypto API for the data wrappin=
g
functions?  I'm not sure that it quite matches the existing APIs because t=
he
size of the input data will likely not match the size of the output data a=
nd
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 mi=
ght
not work for that.