From owner-freebsd-fs@freebsd.org Tue Jan 9 00:45:04 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A896DE6FA9F for ; Tue, 9 Jan 2018 00:45:04 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 41BC77DF0B for ; Tue, 9 Jan 2018 00:45:03 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074424-679ff70000005c98-7a-5a5410810d3c Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 90.73.23704.180145A5; Mon, 8 Jan 2018 19:44:50 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w090imNS025220; Mon, 8 Jan 2018 19:44:48 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w090ihxc025100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Jan 2018 19:44:46 -0500 Date: Mon, 8 Jan 2018 18:44:43 -0600 From: Benjamin Kaduk To: Rick Macklem Cc: Garrett Wollman , "freebsd-fs@freebsd.org" Subject: Re: Anyone managed to build a static gssd? Message-ID: <20180109004443.GK25484@kduck.kaduk.org> References: <23121.48634.348216.421634@hergotha.csail.mit.edu> <20180107190802.GD25484@kduck.kaduk.org> <23122.42381.906072.663073@hergotha.csail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42IR4hTV1m0SCIkyeDaZ2+LY459sFg+XXWOy 2PHpLrsDs8elqbdZPWZ8ms/i8XvzXqYA5igum5TUnMyy1CJ9uwSujG1bv7EVPBKueH/zAWsD 42b+LkZODgkBE4nLHz4xdTFycQgJLGaSmPJwFjOEs4FRouHcdDYI5wqTxJVnfxlBWlgEVCRW T97EBmKzAdkN3ZeZQWwRAXWJzav7wWxmgQyJS7cOAdVwcAgLGEs8uyIDEuYF2nZjRR87xMwz TBK/br5mhUgISpyc+YQFoldL4sa/l0wgvcwC0hLL/3GAhDkFEiUO/Z4MViIqoCyxt+8Q+wRG gVlIumch6Z6F0L2AkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrrlebmaJXmpK6SZGUOiyu6js YOzu8T7EKMDBqMTDW9AeHCXEmlhWXJl7iFGSg0lJlFfUOSBKiC8pP6UyI7E4I76oNCe1+BCj BAezkgiv73ygct6UxMqq1KJ8mJQ0B4uSOK+HiXaUkEB6YklqdmpqQWoRTFaGg0NJgvcsf0iU kGBRanpqRVpmTglCmomDE2Q4D9Dw+SA1vMUFibnFmekQ+VOMxhxzzl/+w8TxbObrBmYhlrz8 vFQpcd5zfEClAiClGaV5cNNA6Ucie3/NK0ZxoOeEeTVABvIAUxfcvFdAq5iAVr3bFwiyqiQR ISXVwCgVNbO82fHIn886mQ2TNsacmnDDu/i5ardn0aZnX7767e3Jn9q2LTT/78OCYysXmpvf 8nxoafRa6qKti9vOiJbW14mKc5ZsX3btkXDqkquRVr9dFh3qFvxa+YVLY0I+r3rog4WP5qqL Lgh7eXr57j121bG24uGVonNybISNw8/lCO/1CRFfdUmJpTgj0VCLuag4EQA0iiC+GgMAAA== X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 00:45:04 -0000 On Mon, Jan 08, 2018 at 01:52:48PM +0000, Rick Macklem wrote: > Garrett Wollman wrote: > [good stuff snipped] > > What would it take to get AES support? > Good question. Unfortunately I don't know the answer. > (I shouldn't have blamed RPCSEC_GSS Version 1, since it isn't this spec > that is the problem, from what I know.) > > 1 - The kernel RPCSEC_GSS code does upcalls to the userland library for > the initialization phase (ie. GSS_Init() calls using the tokens). > --> So question #1 becomes "Does the Heimdal GSSAPI library know how > to do better checksum/encryption than was specified in the original > GSSAPI RFC?". Heavens; yes! Per RFC 6649, you shouldn't be using single-DES for anything you actually care about the confidentiality of. > 2 - The kernel RPCSEC_GSS code uses the session key from the GSS_Init() > handling of the tokens to do checksums/encryption. (Basically in kernel > versions of GSS_GetMIC(), GSS_VerifyMIC(), GSS_Wrap, GSS_Unwrap().) > If the answer to #1 is yes, then it might not be that much work? sys/kgssapi/krb5 has bits for aes/RC4/etc. > 3 - I have never seen any definition of what the QOPs are for better encryption > types in the GSSAPI. (Numbers that define the better checksum/encryption > algorithms.) > --> I have no idea if the NFS implementors have done anything about this. > I haven't seen discussions of it on nfsv4@ietf.org, but it may have happened. > Without this, you'd end up with a FreeBSD specific hack that didn't > interoperate with other NFS implementation.s > In practice these days "If Linux supports it, others will too.". The GSS QOP should be considered deprecated as of GSS-API version2, and GSS_C_QOP_DEFAULT is the only thing I ever see used. The session key output by the GSS security context negotiation will be of an encryption type supported by both peers, so there "ought not" be any code changes needed to the GSS-API consumer code. > If you can answer all of the above, then you probably know the answer. > It could range from some fairly minor changes to the kernel RPCSEC_GSS > code to a whole lot of work. > > Maybe some Kerberos conversant folk can shed light on this? The above all adds up to a situation where the last time I tried to look at this (a few years ago), I had managed to convince myself that non-single-DES should "just work" as-is. But I didn't actually spin up a test server to verify that. -Ben