linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: David Howells <dhowells@redhat.com>
Cc: herbert@gondor.apana.org.au, 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
Subject: Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
Date: Thu, 12 Nov 2020 13:37:17 -0500	[thread overview]
Message-ID: <20201112183717.GH9243@fieldses.org> (raw)
In-Reply-To: <160518586534.2277919.14475638653680231924.stgit@warthog.procyon.org.uk>

On Thu, Nov 12, 2020 at 12:57:45PM +0000, David Howells 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.

We did have code for a non-krb5 mechanism at some point, but it was torn
out.  So I don't think that's a priority.

(Chuck, will RPC-over-SSL need a new non-krb5 mechanism?)

> 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?

I don't know.  My memory is that the buffer management in the existing
rpcsec_gss code is complex and fragile.  See e.g. the long comment in
gss_krb5_remove_padding.

--b.

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

  parent reply	other threads:[~2020-11-12 18:37 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
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 [this message]
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=20201112183717.GH9243@fieldses.org \
    --to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).