From owner-freebsd-fs@freebsd.org Mon Jan 8 13:52:51 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 A5138E6DE56 for ; Mon, 8 Jan 2018 13:52:51 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0070.outbound.protection.outlook.com [104.47.37.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 510F67C499 for ; Mon, 8 Jan 2018 13:52:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM (52.132.46.161) by YTOPR0101MB2169.CANPRD01.PROD.OUTLOOK.COM (52.132.46.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Mon, 8 Jan 2018 13:52:48 +0000 Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::6d7a:1bb0:91b4:f3f7]) by YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::6d7a:1bb0:91b4:f3f7%13]) with mapi id 15.20.0386.009; Mon, 8 Jan 2018 13:52:48 +0000 From: Rick Macklem To: Garrett Wollman CC: Benjamin Kaduk , "freebsd-fs@freebsd.org" Subject: Re: Anyone managed to build a static gssd? Thread-Topic: Anyone managed to build a static gssd? Thread-Index: AQHTh+uZCGcGQRWzeUCLjeFj9rv2rKNo48OwgAAh1ICAAPam0w== Date: Mon, 8 Jan 2018 13:52:48 +0000 Message-ID: References: <23121.48634.348216.421634@hergotha.csail.mit.edu> <20180107190802.GD25484@kduck.kaduk.org> , <23122.42381.906072.663073@hergotha.csail.mit.edu> In-Reply-To: <23122.42381.906072.663073@hergotha.csail.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB2169; 7:rSV2cVflj+a1Fxq4357cp1/sX9wGGK2IwtIcRxB65wXWOJv+lh4yj4+knSCjO7hyVOKutqQ2QslI48H7TKX8cqYXez3g5pntEXL62tSi1avRCM/2Nhv3wlQ2Z/cFC8+dBF5Gv/tDSiwFqx8KBvW/+JzQ0ylkna87whJoXbGqfv6ejaU0Rtnp2XTPNOeHLbPCxZ0OPqOruwJ3ehUwR15HnUUgnZj1pJ7Fx8OUHPWbctDf1kqMCsqG+hXsgKGGwI1r x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f0176608-ff27-4dbb-2e3e-08d5569f1aa6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:YTOPR0101MB2169; x-ms-traffictypediagnostic: YTOPR0101MB2169: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3231023)(944501075)(3002001)(10201501046)(93006095)(93001095)(6041268)(20161123562045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:YTOPR0101MB2169; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:YTOPR0101MB2169; x-forefront-prvs: 054642504A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(39380400002)(39860400002)(366004)(24454002)(189003)(199004)(106356001)(105586002)(4326008)(93886005)(68736007)(55016002)(102836004)(316002)(786003)(25786009)(81166006)(5250100002)(2906002)(9686003)(97736004)(3280700002)(54906003)(3660700001)(305945005)(2900100001)(53936002)(6246003)(74482002)(33656002)(478600001)(74316002)(8676002)(7696005)(14454004)(6436002)(81156014)(86362001)(5660300001)(6916009)(2950100002)(76176011)(6506007)(8936002)(99286004)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB2169; H:YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: fDkp9f69yJ4Bxs81YbJ0cjB8mgWoAx4mIW/VyclwR0QJy17C1exREF7KYDCZXUHC/A1BU8zjQIx7gJaHEHix2g== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: f0176608-ff27-4dbb-2e3e-08d5569f1aa6 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2018 13:52:48.9211 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB2169 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: Mon, 08 Jan 2018 13:52:51 -0000 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 origina= l GSSAPI RFC?". 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? 3 - I have never seen any definition of what the QOPs are for better encryp= tion 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.". 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? rick=