[nfsv4] Re: Feedback on user ID for any bis work
Chris Inacio <inacio@cert.org> Fri, 16 August 2024 21:07 UTC
Return-Path: <inacio@cert.org>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8CA8C14F70A for <nfsv4@ietfa.amsl.com>; Fri, 16 Aug 2024 14:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXZulndfi9N8 for <nfsv4@ietfa.amsl.com>; Fri, 16 Aug 2024 14:07:10 -0700 (PDT)
Received: from USG02-BN3-obe.outbound.protection.office365.us (mail-bn3usg02on0045.outbound.protection.office365.us [23.103.208.45]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2697C1CAE9B for <nfsv4@ietf.org>; Fri, 16 Aug 2024 14:07:10 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=uDnI4z/NLmz9MjR+XhIjcxr4imfc4rWt2BWVHlMo2qQdd15okYfGjncz9TqPu+aXhQgalBVVroCMu8BAFKHT2gGeUWdedeFJNzAE7EGHee6CH6SosWG+W7bkxjigsSf+ANyH4H+4raPTxhnND+j6+dpo/f5ky2GwdshkhnEhSZX/9k1xK4UNnEXpSui1iB6l/b1ytpk1uKIFMw++uHi2eGyrdLwQY3i3Csz5m+TvpYsIOFQpW1/KRCa5vGPvwDN0GkL9mitr5uKupP2zVFReFF5Pp7zzt4y070BpnrnU8HeVlTCaVKeJQnsJ3XU3GYpT9KNVP68oQK/69o/AOh1Gqw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zzwhQsWE8Jg9S/IMc7AVU7pEcbTSRoFa+5TAqTCpQWc=; b=X9A4GMCoHnHe0d8EPXVeQUM9ssz76uvHbe8LO8mWtOTlFDVMZWqs64C3141TW3cLPsOWOOOW9HO75mIcwzpu053Wt67ZtlOMSpphQEcWnzvMb4Eqk+KmYXsWUOfmwcn03TejgWmjbG0Zpc6hF3IDQy6m/wMIY/QCnNwSWsZQB8OSD7aZWwJJPNihf/b2d/PTQ3kW3nfDBZV3IECRspSxmnYzgleKYDrNWCCja/6BpCsxnUgJMhElI64yMsuKlzo4F52M0kBPWrR8GTxxLO3tmjtTRddSGBUKf50PYk/rDANbR9VqkGN7Mbj6Nu7CUvRYN8K3clZA7pyQ3WDDVIapdA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cert.org; dmarc=pass action=none header.from=cert.org; dkim=pass header.d=cert.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zzwhQsWE8Jg9S/IMc7AVU7pEcbTSRoFa+5TAqTCpQWc=; b=qp3ikRFr6LbvKPBdfgz6nK68NRZT9ujpCx1UVS0MpCSuyu0xQHvZRqFuvvQzij4NiRXcv4928HgVh9jpmvMKCsWRC4uwBOctFECiCpa5xBTZ8ZCMW/DcoeRPpFtaHcPve4iAeIR6v9C62/ojsRvDU/goHNPeH7DA0H8uhnarw/0=
Received: from SA1P110MB0975.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:172::5) by SA1P110MB1864.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:1ab::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7828.33; Fri, 16 Aug 2024 21:07:08 +0000
Received: from SA1P110MB0975.NAMP110.PROD.OUTLOOK.COM ([fe80::8aff:57ad:83e3:4567]) by SA1P110MB0975.NAMP110.PROD.OUTLOOK.COM ([fe80::8aff:57ad:83e3:4567%7]) with mapi id 15.20.7828.031; Fri, 16 Aug 2024 21:07:08 +0000
From: Chris Inacio <inacio@cert.org>
To: Chuck Lever III <chuck.lever@oracle.com>
Thread-Topic: [nfsv4] Feedback on user ID for any bis work
Thread-Index: AQHa8BWkquOZ8G2ZEE+JkBu2ia0yN7IqWYSAgAAGxAA=
Date: Fri, 16 Aug 2024 21:07:08 +0000
Message-ID: <EFD2C35A-9FC4-4381-82F2-475957CEE07B@cert.org>
References: <88CFBD80-2BAA-43AE-8AA5-C032C2761266@cert.org> <DCD380BF-74D5-4FED-94EA-EC995A9DB164@oracle.com> <CAM5tNy7ELwEbE5z_VMC0ghePcMzkHAcEJDs4skvnxH4XJpeWLA@mail.gmail.com> <B0F6BCDA-CAE6-4985-AC0D-9DCAAEF68241@cert.org> <8CAD9D90-489B-45AC-A52E-6800E6AA0EAE@oracle.com>
In-Reply-To: <8CAD9D90-489B-45AC-A52E-6800E6AA0EAE@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3776.700.51)
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cert.org;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SA1P110MB0975:EE_|SA1P110MB1864:EE_
x-ms-office365-filtering-correlation-id: df3fa873-41f9-4e63-78cc-08dcbe3763bf
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|38070700018;
x-microsoft-antispam-message-info: oBJeyOc4BgUjK9CAx2QjU+rg0tUfEqeleraSZ35CfDgJzNJophk0i00EPGnEzOxK6wfImik5wkCTqhNl/5qkJJJMyjfkjoZseDp+soeKczkLNqCNbBqsCib4aGF1f1F7vlkItvSaAAjubCplBpd4m7vZFLsp+ohIXpURBLHUmGnv5tYjz7+6LNP55NTc3VQZ6p15M4gjR+3db5904O/m2VlpW72BoSgy45kG16ZOybHJWu2ndOeH2weh0N4xI13ok1RqklHmnc7GMN/UKn7vESXY/+2mQq6QB4Nr/FnE693QE9UxnNAnECBm9Ncgz34awkDwlXuX6mQggRxiuw/C4L1yOHWKOg68P9wCh9hdp1tv7bF3wodgc5oeokLLN7zAEFijQnK+qAM0hqVSoiKGCX+rTAqWjw39UYvd6+VjWtFzYYLFZlMy9ejHcztVla0q22n3ubi5dnriLRNBb5QH08G1dwVWoyqjXh+UlVZ/bcqYfO+yqwoMUCDGcIqGjr4ffydoZy41P2Y9os4G/xX9l5rH6Yus4/+LdkGa34SRIzWr+UMY0ECFgrO9SOu4FfBX8RbbeldXJUrZy0AU/FYqPeVOLq2g+x0pWIGjkteaU43VycyCjgKEeLr1Wt6r1CP59k87KzcRz4SRpNpq2ZtCqWG5GYJBeOAyCi8Z3yTckLoJd3S6iD3aW2E7P704t7DO8lK0+se5hDrh27ujPIxgMY5b/Kfz3YdhQ+PfbUFthWKMLscYiAXRH32pb5T7J9HShfbGODLgTiatoB+TF4Etnaq9lYYqfpxfVV0qRH0lnJX1JYfPXhB+4H4Dj4fz+qN7xKeaPOjbSJ/VLnUO8Yz8aFRph0pvIwMY/3TY53ACpoG+tmLyYg9mdLL0E1GcUxbhFPMFs3lrgeW2c5I7Ks8JLjYgOzu7xJj0fhSgGqBLsKCueAfh7reXP+GM1idKCobxefPrtA2Y6tKcEcPZctzkHBHZoC/RQ3Gi3N7Dvv22hcvlnjJ9OdecDhzWRLZw6XQy8LfkCDBh4S0ktyJ1hA+np7tubg22nNRqUTIkg1QNBUk/rqrhTlMvpI2H0cNEFovi9e0EZpXH6o3i5hz40kuuuF+ukDgaabby8LfbMM1kEyjhzKVQc4qKvVm7OVsQTtK8uO5hAOP6707VFrz9ktQSWVuvSbRH7u9MnIjnEq8VjKJMuFSnb7l0/29WHHUxWsyfw8P0FPcOTMphI+wYflKyOpUHOPF6ag2QH+OYUf2YwWY4sjIktbsNSVVAuDv5mxUbhvAAG0yJESf7WO3HjocnRy/8smrduahciyta03cMoZfONceypQ0k/oV/1ySRQuZHbwI/1c9ZPPUewdcrGH9o53b7NG8iApfuTIb1pqnB7NPI9ijwitjELOBGV9Qe3L8XxMK5Eoiz1BXKYov39ug9xQ==
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA1P110MB0975.NAMP110.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: SIBEvFqAWoTO9He/IsByhwI6GTTHxHQMprm8K93JqUx/cv1Td/QPkQpUcjpbUSNcp79GXoNuMIGRw49Rs6PJIHh48ceDvAyWlygIPdd1RRFJntHQpGmtn8wk1pVMHNWGLciDw3jKHL9sDppH/dFF3wKwo4pA9zzss0PAKiuGSKFdZiaZbSDH/vS8wVo9JNyjbl0+9M+nar0jtLjlUtSasgXmPxHpyB90zpPuYf7bFDedeHtZhUCKZja9X0WUozUqYiwl5QP1hFM9U8k4JEfATiYH8S9+LyAqetsCTSM45QNZBIpM4l3XuCmOsYw9jiaPc8LsXRJWDtglOWEBFNtJDibzfs3v2oe15QfqO/PUQh2VH9uExjEgd75O7Q6q6HD31oA/MzuXuzuKs8UYOyiFpPmsVgnYfocJ5BYy+KM/MzPRvooYGZuUB2hSdX6gfFRyEbxMHsGDGCN0cyvw9m/OQpWlUiIuHl2x+0ePs2uExVipTJvB0E5U/mFGt3tPraKkocyK31v496cB2YowV3Yr01yYJxSBm0+ny5D/1SabWXgeHcKbS3qkybA3Btjqf0QWntRHeeG+lCl7ZoYZ2v5btuK9WKzbUVL3I21WP4YdAC9O/uvzsEQ3mDfZB2L7C65r2MsP1Def9RkXWV0uV0hnaa9cr3D/HVybfg63voYSVGoeOaC2PdP3n2l/8Mg/AvW5Hs8UlL3iQ7i3gGnrgqdy/Vj48xBwsQ1A/e0BxYFXYmDVxNia8sQfs5SvG1niydNZ2idqfCQSpLQ+HOJG7p2z+roa3HzxBYSmZ897pqDtOoGf49DQGuTw9agVFp+vTn/Sma9GuxL5wNIxFvTh1CCaSlJsBKCGcgNNIUO3FM5NidcHW53TmHngI00blAK+bHhDW9aWrlfYzXHFur2rcilkf0uUroVZl01YMr3B2IZdzqgLFDFy5WcbJD1b8tTO0SlZpFte6EQo4r7JWQZVNGzwzWBeszUc8wM1hUwhudxWPLiub6jVu04EaSymgFp2zRdVT82nTlFuFS9+wq7HYJlsGeovT+mnNvKAQJKFwDwsnhuKUWTyMWY0p5OiufWLCkV1Ma8L3GK39gZ3nsk64ztlIc6IpW1M46rJpTEyWZnpdm/31s1rFr8uYQXKX0lk0zBFKpK8W86x+mSCXBKB+zAw0ZOjKC8Wx8VxcI+9IwRZJ7xjEDwS2EcoO1pTnBF8OgLDar9xVOsmHrfAQnRLxAJgmiKQls5PKROROmpww1vHmuVKnHlFA9PPTDALlsyJTmocsVAaPhzDaOdAQ2q5bfPe31SmIUovfkt7dxjHgFTJL5HyyditbEM2QoHyqTDwzosZwbntwaxwigWMaH0crM8qvjT+NyNaZyqpdHY9T3Xcvw4PJx7ZgpAD886+bJhh83m3ZjZaRAEA1U7y58Ctq8K1c7tcM0w1a0Bgcx2GN7mIq6riMgsF3T/U3jttU7/aG6s7QqX3wOsxBg+N8ugplubuQD/eHSMwZxQSDW+L/5+A75K7Bj6dyJjgvs31a4xCrAMw
Content-Type: text/plain; charset="utf-8"
Content-ID: <C8586D75D8DC2D459C8FED0B6814A0F5@NAMP110.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cert.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA1P110MB0975.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: df3fa873-41f9-4e63-78cc-08dcbe3763bf
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2024 21:07:08.5128 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 95a9dce2-04f2-4043-995d-1ec3861911c6
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1P110MB1864
Message-ID-Hash: RL4J35B32VXK4DEXBPTVTZ62SBXI3B35
X-Message-ID-Hash: RL4J35B32VXK4DEXBPTVTZ62SBXI3B35
X-MailFrom: inacio@cert.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-nfsv4.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: NFSv4 <nfsv4@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [nfsv4] Re: Feedback on user ID for any bis work
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/qaBJwdsRInal8qCdJwnOY3Ly1qA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Owner: <mailto:nfsv4-owner@ietf.org>
List-Post: <mailto:nfsv4@ietf.org>
List-Subscribe: <mailto:nfsv4-join@ietf.org>
List-Unsubscribe: <mailto:nfsv4-leave@ietf.org>
> On Aug 16, 2024, at 4:42 PM, Chuck Lever III <chuck.lever@oracle.com> wrote: > > Warning: External Sender - do not click links or open attachments unless you recognize the sender and know the content is safe. > > >> On Aug 16, 2024, at 3:51 PM, Chris Inacio <inacio@cert.org> wrote: >> >> >> >>> On Aug 16, 2024, at 3:17 PM, Rick Macklem <rick.macklem@gmail.com> wrote: >>> >>> Warning: External Sender - do not click links or open attachments unless you recognize the sender and know the content is safe. >>> >>> >>>> On Fri, Aug 16, 2024 at 9:26 AM Chuck Lever III <chuck.lever=40oracle.com@dmarc.ietf.org> wrote: >>>> >>>> >>>>> On Aug 16, 2024, at 11:39 AM, Chris Inacio <inacio@cert.org> wrote: >>>>> >>>>> Dave, All, >>>>> >>>>> INDIVIDUAL CONTRIBUTOR HAT ON - NOT CHAIR >>>>> >>>>> We need this super brief conversation in one of the interim meetings about how user identity is communicated across NFSv4, and there are 2 options, UID/GID ‘integer's and then loosely defined ‘string’. So I’ve been digging into this and I would say, most definitely, do NOT remove the string. So what I can see so far, is that UID/GID numbers are used when auth ‘sys’ is the selected mechanism, where current the string is used when auth is tied to GSS-API. As far as I can tell, the kerberos principal name should be the string in the field. I certainly don’t yet have a full understanding about how everything is connected together. (Just sending the principal is nice and everything, but you want to be able to verify it, and HOLY RAT HOLE ROBIN is that confusing in practice.) >>>>> >>>>> So, the thing I’m trying to make sense of, how hard would it be to support TLS identities (X.509 certs really) instead of Kerberos. >>>> >>>> A perhaps subtle distinction here: >>>> >>>> The current RPC-with-TLS protocol uses x.509 explicitly only for authenticating >>>> network peers (ie, hosts). RFC 9289 even says "not for user authentication". So >>>> I think the term "TLS" here is probably misplaced. >>>> >>>> You instead want to invent a new RPC security flavor or flavors that authenticates >>>> users (or, dare I say it, to extend GSSAPI to handle this for us) via an x.509 >>>> certificate, or OAuth, or such like. Nothing to do with transport layer security, >>>> which doesn't know from users. >>> There is the specific case Chuck named "TLS identity squashing", where >>> the client's X.509 cert. identifies a single user for all RPCs done >>> via the TLS session. >>> >>> This works ok for cases where the client is just a single user, such >>> as a mobile device. >>> >> >> [ci] That’s really interesting. I’ll have to look deeper at that. First order is that the tighter binding of user to host that allows that to work more easily? > > Rick implemented this for FreeBSD, and I have a plan to implement > this in Linux NFSD in a way that is hopefully compatible with his > implementation. It is merely a convention of adding a user identity > to the client certificate's SAN field; the receiving server then > squashes all RPC traffic from peers using that certificate to that > user ID. > > But I didn't mention it before because I assumed you were interested > in the more general multi-user case. > [ci] You’re right in that I’m primarily interested in the more general use case. And I get some of the possible limitations / hiccups of the version you’re describing. (Mount at boot before user auth, etc.) If you add a field to the certificate, who and when is the signer? [ci] It might be more interesting about the “squashes all RPC traffic” part. It seems a bit like a protocol hack, at first blush, to me. But then I don’t understand NFS that deeply, so I could be /really/ off base on that point. But even if it is, does that provide an avenue to think about how new/different auth might be achieved. [ci] Although back to your first point, to my current understanding of NFSv4, the "right way”* is most likely API extensions in GSS. My thinking (at the moment) is that I would want to enable where auth is at today, especially if I think enterprise and things like hybrid clouds. I guess that means things like OAUTH, SCIM(?), and still kerberos (and I guess add JWT/CWT). What would make a seamless transition to accessing storage in the enterprise, being able to share to possibly local cloud compute, push up the cloud provider, extend to multi-cloud, and move back down allowing a client end point to have strong authentication and authorization across that. And for bonus points, it would be /really/ nice to be able to smoothly grow up from 3 people in a “garage” to 1000 as an enterprise, and beyond. [ci] Free dinner on me if you and Rick have a prototype doing AA for that. [ci] I don’t know of any pain free strong AA solutions that I would want to run in my house. I wish I could say that would be in scope - but I doubt my house compute / network is reasonable in 99% of the world's opinion. [ci] * - for some definition of right. > > -- > Chuck Lever
- [nfsv4] Feedback on user ID for any bis work Chris Inacio
- [nfsv4] Re: Feedback on user ID for any bis work Chuck Lever III
- [nfsv4] Re: Feedback on user ID for any bis work Chuck Lever III
- [nfsv4] Re: Feedback on user ID for any bis work Pali Rohár
- [nfsv4] Re: Feedback on user ID for any bis work Chris Inacio
- [nfsv4] Re: Feedback on user ID for any bis work Rick Macklem
- [nfsv4] Re: Feedback on user ID for any bis work Chris Inacio
- [nfsv4] Re: Feedback on user ID for any bis work Chuck Lever III
- [nfsv4] Re: Feedback on user ID for any bis work Mkrtchyan, Tigran
- [nfsv4] Re: Feedback on user ID for any bis work Chris Inacio
- [nfsv4] Re: Feedback on user ID for any bis work David Noveck
- [nfsv4] Re: Feedback on user ID for any bis work Rick Macklem
- [nfsv4] Re: Feedback on user ID for any bis work Chris Inacio
- [nfsv4] Re: Feedback on user ID for any bis work Rick Macklem
- [nfsv4] Re: Feedback on user ID for any bis work Chris Inacio
- [nfsv4] Re: Feedback on user ID for any bis work Mkrtchyan, Tigran
- [nfsv4] Re: Feedback on user ID for any bis work Chuck Lever III
- [nfsv4] Re: Feedback on user ID for any bis work Chris Inacio
- [nfsv4] Re: Feedback on user ID for any bis work Mkrtchyan, Tigran
- [nfsv4] Re: Feedback on user ID for any bis work Mark Liam Brown
- [nfsv4] Re: Feedback on user ID for any bis work Chuck Lever III
- [nfsv4] Fwd: Re: Feedback on user ID for any bis … David Noveck