netdev - Re: [PATCH net 00/17] rxrpc: Prelude to gssapi support

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20201124120859.10037dd6@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Tue, 24 Nov 2020 12:08:59 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     David Howells <dhowells@...hat.com>
Cc:     netdev@...r.kernel.org, linux-afs@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net 00/17] rxrpc: Prelude to gssapi support

On Mon, 23 Nov 2020 20:10:04 +0000 David Howells wrote:
> Here are some patches that do some reorganisation of the security class
> handling in rxrpc to allow implementation of the RxGK security class that
> will allow AF_RXRPC to use GSSAPI-negotiated tokens and better crypto.  The
> RxGK security class is not included in this patchset.
> 
> It does the following things:
> 
>  (1) Add a keyrings patch to provide the original key description, as
>      provided to add_key(), to the payload preparser so that it can
>      interpret the content on that basis.  Unfortunately, the rxrpc_s key
>      type wasn't written to interpret its payload as anything other than a
>      string of bytes comprising a key, but for RxGK, more information is
>      required as multiple Kerberos enctypes are supported.
> 
>  (2) Remove the rxk5 security class key parsing.  The rxk5 class never got
>      rolled out in OpenAFS and got replaced with rxgk.
> 
>  (3) Support the creation of rxrpc keys with multiple tokens of different
>      types.  If some types are not supported, the ENOPKG error is
>      suppressed if at least one other token's type is supported.
> 
>  (4) Punt the handling of server keys (rxrpc_s type) to the appropriate
>      security class.
> 
>  (5) Organise the security bits in the rxrpc_connection struct into a
>      union to make it easier to override for other classes.
> 
>  (6) Move some bits from core code into rxkad that won't be appropriate to
>      rxgk.

Pulled into net-next, thank you!