From owner-freebsd-fs@freebsd.org Sun Jan 7 21:03:03 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 ADE84E5D2D6 for ; Sun, 7 Jan 2018 21:03:03 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0089.outbound.protection.outlook.com [104.47.34.89]) (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 544DF78E65 for ; Sun, 7 Jan 2018 21:03:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM (52.132.46.161) by YTOPR0101MB2170.CANPRD01.PROD.OUTLOOK.COM (52.132.46.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Sun, 7 Jan 2018 21:03:01 +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; Sun, 7 Jan 2018 21:03:01 +0000 From: Rick Macklem To: Benjamin Kaduk , Garrett Wollman CC: "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+uZCGcGQRWzeUCLjeFj9rv2rKNo48Ow Date: Sun, 7 Jan 2018 21:03:01 +0000 Message-ID: References: <23121.48634.348216.421634@hergotha.csail.mit.edu>, <20180107190802.GD25484@kduck.kaduk.org> In-Reply-To: <20180107190802.GD25484@kduck.kaduk.org> 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; YTOPR0101MB2170; 7:aM5dL2/0n67eDQTKA7nXCoI813c4TEocG9pCbgv8Q57VK7ze5UgJWeOPRu7bz9nkzXVXXGfTPa9FAazYqS84MBMO0JAwULtmRGoRBPg6GkldKBR9rTVEEcNbOj0rB9Ynd76El1YlF9kJrmKZ6LNMylOROMYc7rxr/xVBgIF6g/Jqm5OnmEQBn8ajSr2siVKBHfy6AXZJCm0HVUpH0cvH3+b51moZEATP4V9gC+IipU1FF05H4Oju9xheUNRQygqQ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 75256016-4c12-4bfd-0417-08d5561209f2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:YTOPR0101MB2170; x-ms-traffictypediagnostic: YTOPR0101MB2170: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231023)(944501075)(6041268)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:YTOPR0101MB2170; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:YTOPR0101MB2170; x-forefront-prvs: 0545EFAC9A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(376002)(39380400002)(396003)(39850400004)(346002)(366004)(24454002)(199004)(189003)(2171002)(6246003)(59450400001)(6506007)(97736004)(3280700002)(478600001)(55016002)(2906002)(5250100002)(7696005)(3660700001)(81156014)(81166006)(316002)(9686003)(786003)(8676002)(8936002)(53936002)(2950100002)(110136005)(102836004)(74482002)(99286004)(5660300001)(68736007)(33656002)(4326008)(305945005)(25786009)(229853002)(2900100001)(106356001)(74316002)(105586002)(76176011)(6436002)(86362001)(14454004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB2170; H:YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: iNyfaOG3FYTsVXPWsKVLvDemJBcsgKwPMP5fMbxIwKhEgdaZUE0PzhBhf0aLyB3Io0A9/w2sZhcFZxXhY3UCtg== 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: 75256016-4c12-4bfd-0417-08d5561209f2 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2018 21:03:01.8424 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB2170 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: Sun, 07 Jan 2018 21:03:03 -0000 Benjamin Kaduk wrote: >On Sun, Jan 07, 2018 at 01:28:10AM -0500, Garrett Wollman wrote: >> I'm interesting in experimenting with GSSAPI security for NFS mounts, >> but we run MIT Kerberos, not Heimdal. AIUI, the kernel code has to >> have the same data structures as the userland code in gssd, which >> implies that gssd has to be built against Heimdal libraries, not MIT. > >I think you might want to test that hypothesis experimentally -- >both Heimdal and MIT have gss_export_lucid_sec_context() that >generate the gss_krb5_lucid_context_v1_t data type, which seems >to be defined identically between them. AIUI, this "lucid" (i.e., >non-opaque) type is what is used for sending the GSS information >into the kernel. I haven't worked with this for a long time, but I vaguely recall that the kernel RPCSEC_GSS code uses a relatively small subset to the KGSSAPI upcalls to userland. If you grep around in sys/rpc/rpcsec_gss you should be able to find which ones they are (and see if they happen to be the same for Heimdal/MIT)= . I think the client side uses more than the server side, but beware that the server becomes a client for callbacks for NFSv4. Also, just fyi, RPCSEC_GSS Version 1 (the only one supported by FreeBSD) uses good old DES and uses the session key created by the Kerberos libraries via a TGT or keytab entry for this. --> As such, your TGT encryption choice must result in a 56/64 bit session = key. (I never went beyond using DES for TGT encryption, but I suspect MIT doesn't like that idea;-) Good luck with it, rick