Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
From:   David Howells <dhowells@redhat.com>
To:     herbert@gondor.apana.org.au, bfields@fieldses.org
Cc:     dhowells@redhat.com, trond.myklebust@hammerspace.com,
        linux-crypto@vger.kernel.org, linux-afs@lists.infradead.org,
        linux-cifs@vger.kernel.org, linux-nfs@vger.kernel.org,
        linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Date:   Thu, 12 Nov 2020 12:57:45 +0000
Message-ID: <160518586534.2277919.14475638653680231924.stgit@warthog.procyon.org.uk>
User-Agent: StGit/0.23
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Precedence: bulk


Hi Herbert, Bruce,

Here's my first cut at a generic Kerberos crypto library in the kernel so
that I can share code between rxrpc and sunrpc (and cifs?).

I derived some of the parts from the sunrpc gss library and added more
advanced AES and Camellia crypto.  I haven't ported across the DES-based
crypto yet - I figure that can wait a bit till the interface is sorted.

Whilst I have put it into a directory under crypto/, I haven't made an
interface that goes and loads it (analogous to crypto_alloc_skcipher,
say).  Instead, you call:

        const struct krb5_enctype *crypto_krb5_find_enctype(u32 enctype);

to go and get a handler table and then use a bunch of accessor functions to
jump through the hoops.  This is basically the way the sunrpc gsslib does
things.  It might be worth making it so you do something like:

	struct crypto_mech *ctx = crypto_mech_alloc("krb5(18)");

to get enctype 18, but I'm not sure if it's worth the effort.  Also, I'm
not sure if there are any alternatives to kerberos we will need to support.

There are three main interfaces to it:

 (*) I/O crypto: encrypt, decrypt, get_mic and verify_mic.

     These all do in-place crypto, using an sglist to define the buffer
     with the data in it.  Is it necessary to make it able to take separate
     input and output buffers?

 (*) PRF+ calculation for key derivation.
 (*) Kc, Ke, Ki derivation.

     These use krb5_buffer structs to pass objects around.  This is akin to
     the xdr_netobj, but has a void* instead of a u8* data pointer.

In terms of rxrpc's rxgk, there's another step in key derivation that isn't
part of the kerberos standard, but uses the PRF+ function to generate a key
that is then used to generate Kc, Ke and Ki.  Is it worth putting this into
the directory or maybe having a callout to insert an intermediate step in
key derivation?

Note that, for purposes of illustration, I've included some rxrpc patches
that use this interface to implement the rxgk Rx security class.  The
branch also is based on some rxrpc patches that are a prerequisite for
this, but the crypto patches don't need it.

---
The patches can be found here also:

	http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=crypto-krb5

David
---
David Howells (18):
      crypto/krb5: Implement Kerberos crypto core
      crypto/krb5: Add some constants out of sunrpc headers
      crypto/krb5: Provide infrastructure and key derivation
      crypto/krb5: Implement the Kerberos5 rfc3961 key derivation
      crypto/krb5: Implement the Kerberos5 rfc3961 encrypt and decrypt functions
      crypto/krb5: Implement the Kerberos5 rfc3961 get_mic and verify_mic
      crypto/krb5: Implement the AES enctypes from rfc3962
      crypto/krb5: Implement crypto self-testing
      crypto/krb5: Implement the AES enctypes from rfc8009
      crypto/krb5: Implement the AES encrypt/decrypt from rfc8009
      crypto/krb5: Add the AES self-testing data from rfc8009
      crypto/krb5: Implement the Camellia enctypes from rfc6803
      rxrpc: Add the security index for yfs-rxgk
      rxrpc: Add YFS RxGK (GSSAPI) security class
      rxrpc: rxgk: Provide infrastructure and key derivation
      rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)
      rxrpc: rxgk: Implement connection rekeying
      rxgk: Support OpenAFS's rxgk implementation


 crypto/krb5/Kconfig              |    9 +
 crypto/krb5/Makefile             |   11 +-
 crypto/krb5/internal.h           |  101 +++
 crypto/krb5/kdf.c                |  223 ++++++
 crypto/krb5/main.c               |  190 +++++
 crypto/krb5/rfc3961_simplified.c |  732 ++++++++++++++++++
 crypto/krb5/rfc3962_aes.c        |  140 ++++
 crypto/krb5/rfc6803_camellia.c   |  249 ++++++
 crypto/krb5/rfc8009_aes2.c       |  440 +++++++++++
 crypto/krb5/selftest.c           |  543 +++++++++++++
 crypto/krb5/selftest_data.c      |  289 +++++++
 fs/afs/misc.c                    |   13 +
 include/crypto/krb5.h            |  100 +++
 include/keys/rxrpc-type.h        |   17 +
 include/trace/events/rxrpc.h     |    4 +
 include/uapi/linux/rxrpc.h       |   17 +
 net/rxrpc/Kconfig                |   10 +
 net/rxrpc/Makefile               |    5 +
 net/rxrpc/ar-internal.h          |   20 +
 net/rxrpc/conn_object.c          |    2 +
 net/rxrpc/key.c                  |  319 ++++++++
 net/rxrpc/rxgk.c                 | 1232 ++++++++++++++++++++++++++++++
 net/rxrpc/rxgk_app.c             |  424 ++++++++++
 net/rxrpc/rxgk_common.h          |  164 ++++
 net/rxrpc/rxgk_kdf.c             |  271 +++++++
 net/rxrpc/security.c             |    6 +
 26 files changed, 5530 insertions(+), 1 deletion(-)
 create mode 100644 crypto/krb5/kdf.c
 create mode 100644 crypto/krb5/rfc3961_simplified.c
 create mode 100644 crypto/krb5/rfc3962_aes.c
 create mode 100644 crypto/krb5/rfc6803_camellia.c
 create mode 100644 crypto/krb5/rfc8009_aes2.c
 create mode 100644 crypto/krb5/selftest.c
 create mode 100644 crypto/krb5/selftest_data.c
 create mode 100644 net/rxrpc/rxgk.c
 create mode 100644 net/rxrpc/rxgk_app.c
 create mode 100644 net/rxrpc/rxgk_common.h
 create mode 100644 net/rxrpc/rxgk_kdf.c