> On Nov 12, 2020, at 7:57 AM, David Howells <dhowe...@redhat.com> wrote:
> 
> 
> 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?

Hi David, Wondering if these "I/O" APIs use synchronous or async
crypto under the covers. For small data items like MICs, synchronous
might be a better choice, especially if asynchronous crypto could
result in incoming requests getting re-ordered and falling out of
the GSS sequence number window.

What say ye?


> (*) 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
> 
> 

--
Chuck Lever



Reply via email to