All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Bruce Fields <bfields@fieldses.org>,
	Trond Myklebust <trond.myklebust@hammerspace.com>,
	linux-crypto@vger.kernel.org, linux-afs@lists.infradead.org,
	CIFS <linux-cifs@vger.kernel.org>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
Date: Thu, 12 Nov 2020 09:36:32 -0500	[thread overview]
Message-ID: <2F96670A-58DC-43A6-A20E-696803F0BFBA@oracle.com> (raw)
In-Reply-To: <160518586534.2277919.14475638653680231924.stgit@warthog.procyon.org.uk>



> On Nov 12, 2020, at 7:57 AM, David Howells <dhowells@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




  parent reply	other threads:[~2020-11-12 14:36 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-12 12:57 [RFC][PATCH 00/18] crypto: Add generic Kerberos library David Howells
2020-11-12 12:57 ` [PATCH 01/18] crypto/krb5: Implement Kerberos crypto core David Howells
2020-11-12 12:58 ` [PATCH 02/18] crypto/krb5: Add some constants out of sunrpc headers David Howells
2020-11-12 12:58 ` [PATCH 03/18] crypto/krb5: Provide infrastructure and key derivation David Howells
2020-11-12 12:58 ` [PATCH 04/18] crypto/krb5: Implement the Kerberos5 rfc3961 " David Howells
2020-11-12 12:58 ` [PATCH 05/18] crypto/krb5: Implement the Kerberos5 rfc3961 encrypt and decrypt functions David Howells
2020-11-12 12:58 ` [PATCH 06/18] crypto/krb5: Implement the Kerberos5 rfc3961 get_mic and verify_mic David Howells
2020-11-12 12:58 ` [PATCH 07/18] crypto/krb5: Implement the AES enctypes from rfc3962 David Howells
2020-11-12 12:58 ` [PATCH 08/18] crypto/krb5: Implement crypto self-testing David Howells
2020-11-12 12:58 ` [PATCH 09/18] crypto/krb5: Implement the AES enctypes from rfc8009 David Howells
2020-11-12 12:59 ` [PATCH 10/18] crypto/krb5: Implement the AES encrypt/decrypt " David Howells
2020-11-12 12:59 ` [PATCH 11/18] crypto/krb5: Add the AES self-testing data " David Howells
2020-11-12 12:59 ` [PATCH 12/18] crypto/krb5: Implement the Camellia enctypes from rfc6803 David Howells
2020-11-12 12:59 ` [PATCH 13/18] rxrpc: Add the security index for yfs-rxgk David Howells
2020-11-12 12:59 ` [PATCH 14/18] rxrpc: Add YFS RxGK (GSSAPI) security class David Howells
2020-11-12 12:59 ` [PATCH 15/18] rxrpc: rxgk: Provide infrastructure and key derivation David Howells
2020-11-12 12:59 ` [PATCH 16/18] rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI) David Howells
2020-11-12 13:00 ` [PATCH 17/18] rxrpc: rxgk: Implement connection rekeying David Howells
2020-11-12 13:00 ` [PATCH 18/18] rxgk: Support OpenAFS's rxgk implementation David Howells
2020-11-12 13:44 ` [RFC][PATCH 00/18] crypto: Add generic Kerberos library David Howells
2020-11-12 14:36 ` Chuck Lever [this message]
2020-11-12 15:42 ` David Howells
2020-11-12 15:49   ` Chuck Lever
2020-11-12 16:54   ` David Howells
2020-11-12 21:07     ` Bruce Fields
2020-11-12 21:09       ` Chuck Lever
2020-11-12 18:37 ` J. Bruce Fields
2020-11-12 18:39   ` Chuck Lever
2020-11-26  6:33 ` Herbert Xu
2020-11-26  8:19 ` David Howells
2020-11-27  5:07   ` Herbert Xu
2020-12-01  8:44   ` David Howells
2020-12-01  8:46     ` Herbert Xu
2020-12-01  9:12     ` David Howells
2020-12-01 10:36       ` Herbert Xu
2020-12-04 14:59 ` Why the auxiliary cipher in gss_krb5_crypto.c? David Howells
2020-12-04 15:46   ` Bruce Fields
2020-12-04 16:05     ` Chuck Lever
2020-12-04 16:14     ` Bruce Fields
2020-12-04 16:01   ` David Howells
2020-12-04 16:03     ` Bruce Fields
2020-12-04 16:50     ` David Howells
2020-12-04 17:06       ` Ard Biesheuvel
2020-12-04 17:19       ` David Howells
2020-12-04 17:35         ` Ard Biesheuvel
2020-12-04 21:08           ` Herbert Xu
2020-12-07  8:24           ` David Howells
2020-12-07 12:01         ` David Howells
2020-12-07 13:08           ` Ard Biesheuvel
2020-12-07 14:15           ` David Howells
2020-12-08  8:27             ` Ard Biesheuvel
2020-12-08  9:18             ` David Howells
2020-12-04 18:13   ` Theodore Y. Ts'o
2020-12-08 13:25 ` David Howells
2020-12-08 14:04   ` Ard Biesheuvel
2020-12-08 14:13   ` David Howells
2020-12-08 14:02 ` David Howells

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2F96670A-58DC-43A6-A20E-696803F0BFBA@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=bfields@fieldses.org \
    --cc=dhowells@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-afs@lists.infradead.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=trond.myklebust@hammerspace.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.