DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A98C620660
MIME-Version: 1.0
References: <20181126194611.10321.71714.stgit@manet.1015granger.net>
 <20181126200717.10321.8819.stgit@manet.1015granger.net> <952872188dd26c5469f4bafe5689a5b2b377803f.camel@gmail.com>
 <F9AC1596-B0F1-4F52-B798-3D94550D4560@oracle.com>
In-Reply-To: <F9AC1596-B0F1-4F52-B798-3D94550D4560@oracle.com>
From:   Olga Kornievskaia <aglo@umich.edu>
Date:   Fri, 30 Nov 2018 16:57:48 -0500
Message-ID: <CAN-5tyFGwmTxoxj=UMLZf_UcCc6CSfaZeowo9e4iFRBCgozOQg@mail.gmail.com>
Subject: Re: [PATCH v2 17/20] SUNRPC: Remove support for kerberos_v1
To:     Chuck Lever <chuck.lever@oracle.com>
Cc:     Anna Schumaker <schumaker.anna@gmail.com>,
        linux-rdma <linux-rdma@vger.kernel.org>,
        linux-nfs <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

On Fri, Nov 30, 2018 at 4:26 PM Chuck Lever <chuck.lever@oracle.com> wrote:
>
>
>
> > On Nov 30, 2018, at 4:19 PM, Anna Schumaker <schumaker.anna@gmail.com> wrote:
> >
> > Hi Chuck,
> >
> > On Mon, 2018-11-26 at 15:07 -0500, Chuck Lever wrote:
> >> Kerberos v1 allows the selection of encryption types that are known
> >> to be insecure and are no longer widely deployed. Also there is no
> >> convenient facility for testing v1 or these enctypes, so essentially
> >> this code has been untested for some time.
> >>
> >> Note that RFC 6649 deprecates DES and Arcfour_56 in Kerberos, and
> >> RFC 8429 (October 2018) deprecates DES3 and Arcfour.
> >>
> >> Support for DES_CBC_RAW, DES_CBC_CRC, DES_CBC_MD4, DES_CBC_MD5,
> >> DES3_CBC_RAW, and ARCFOUR_HMAC encryption in the Linux kernel
> >> RPCSEC_GSS implementation is removed by this patch.
> >
> > I guess my biggest question is if any servers in the wild might still be using
> > Kerberos v1 encryption that we need to worry about?
>
> What we want to do here is remove encryption types that the upstream
> community can no longer support, and that the IETF says are insecure
> and thus should not be used (even if we could support them). IMO this
> is not a matter of continuing to support old servers: they need to
> update.

I'm not arguing for not removing it .. but.. also to consider not
necessarily the server implementations but the fact that prior to
Window 2008 AD there is no support for AES encryption types.

>
>
> > And does the rpc.gssd daemon need to be updated as well?
>
> If the kernel doesn't ask for these encryption types, gssd won't use
> them. It might do with some clean up, though, but I haven't looked
> closely at it.
>
>
> --
> Chuck Lever
>
>
>