| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20201112183717.GH9243@fieldses.org>
Date: Thu, 12 Nov 2020 13:37:17 -0500
From: "J. Bruce Fields" <bfields@...ldses.org>
To: David Howells <dhowells@...hat.com>
Cc: herbert@...dor.apana.org.au, trond.myklebust@...merspace.com,
linux-crypto@...r.kernel.org, linux-afs@...ts.infradead.org,
linux-cifs@...r.kernel.org, linux-nfs@...r.kernel.org,
linux-fsdevel@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
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
>
Powered by blists - more mailing lists