Return-Path: 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 1B960C14F696; Sat, 17 Aug 2024 03:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eD9NDDQ3DX1y; Sat, 17 Aug 2024 03:50:29 -0700 (PDT) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61787C14F6AA; Sat, 17 Aug 2024 03:50:29 -0700 (PDT) Received: by mail-qv1-xf33.google.com with SMTP id 6a1803df08f44-6bf790944f1so12033096d6.2; Sat, 17 Aug 2024 03:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723891828; x=1724496628; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UDAo+I4wIQ7n+Q28y0XlAQbrpYznCPejRDxZBSW6C14=; b=hCjNqwbsG9a4ofqQYWJZJVxYv7bpfvPCLROZjKb7a8oxBpuOYzP/iCJk/3FW2ey9zX mgSg4jLshhb86imKzAJkBiG1oxCFT7NG6I8BDBm3UKCiZ5L0Hn9BhgNyzynRMSynu/wx wimuJ27RhhBhtDTc2VIKgXjd5rVX4XBaZ7ViVb628/G+g2y3DrDKrHLv/gOSNtQU6EX8 7OIoIAzlPByf4X2empfn8Jq9s7ceOoPxXNujAirFly7g3Ehn+R6n/hWGM/7XD8N3WBC4 Kc3zrN/8zB/HO5wYqUurFPfrzrIxWJt6TknGFIHYblis3pizV5szu805q43RuPgvEr/A XJaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723891828; x=1724496628; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UDAo+I4wIQ7n+Q28y0XlAQbrpYznCPejRDxZBSW6C14=; b=fqjNh2Aqj41sclzP52m2goT8UoBoQqdqqcUosE9+UNmOOC2S1MAU7KNdWx/MjIdE23 DGG159a484FbJr+UxFIipGHhHicbpWH14b9y6SFMhhY5fBm8VuSSHKtpL35d554kDYuw PHvFsovxNf88QYGf7f9ZtGD0Wn13LJ+EldQwyyyWs4qlsJGEhq7Xn3zAbZr0ptJx9tOi 9h7x15QHnpawHWAeXMBvAzjBLjUxaE9bl6ZhjzGwgEQOJXLccSzcgKL4lK3KnpJOgA1V XtB64KoMFdmbUgS5jXIVDnnKXe93r5xtvYEMmAYgT8iqCc1K7NfFXwCI9c7l5yucxFcR vMDw== X-Forwarded-Encrypted: i=1; AJvYcCVyUUbeD3pTUd2Y1BlMOIGEg/NugxfpwKmcr7jDBmTTkurb8/6OgNrcbMZMlgCDNTV2VHLaCK+1ofaVvz+8TiH3gMpbLkM= X-Gm-Message-State: AOJu0YyaeSH1C+RBgagzqNtHRW6zuB5fmKQApxH0KflXX1mLiurbbKvf PI9tUpl0BZ+4WN/zorIRn/nzjkPFxz0+nu6qi1jLHx2d8noiyCdy8Epp9BuTHiXmTlADZsycZUd Oz+1D5k6A4uwyZgaGyO3DMBcMO48LbQ== X-Google-Smtp-Source: AGHT+IHolwwfWai7cp62o2amSWIhzp365Ta8MAj24oU8kLXsjLNrJkjvCWPXxojaO2P5zs/NDqCdfGUq4c3g5JfWuA0= X-Received: by 2002:a05:6214:2e47:b0:6bf:6d79:a216 with SMTP id 6a1803df08f44-6bf7ce10637mr62344646d6.29.1723891828269; Sat, 17 Aug 2024 03:50:28 -0700 (PDT) MIME-Version: 1.0 References: <88CFBD80-2BAA-43AE-8AA5-C032C2761266@cert.org> In-Reply-To: From: David Noveck Date: Sat, 17 Aug 2024 06:50:16 -0400 Message-ID: To: Chris Inacio Content-Type: multipart/alternative; boundary="0000000000000e2a73061fded8f5" Message-ID-Hash: COO53RQJ2B3IFJWDVTADJSB3YITATA5K X-Message-ID-Hash: COO53RQJ2B3IFJWDVTADJSB3YITATA5K X-MailFrom: davenoveck@gmail.com 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 , Chuck Lever III , nfsv4-chairs X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bnfsv4=5D_Re=3A_Feedback_on_user_ID_for_any_bis_work?= List-Id: NFSv4 Working Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000000e2a73061fded8f5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I want to respond to Chris's email, although Gmail has somehow swallowed it= . At the risk of contributing to an ongoing case of multiple personality disorder =F0=9F=98=95, Chris as wg member is alone on the To line, while = Chris, the wg chair, is part of the cc list as a member of nfsv4-chairs. I don't have all that much to contribute to discussion of possible authentication extensions but there are a few peripheral remarks below that relate to Chris's email. - I believe Chris is right about the desirability of a discussion of this at a subsequent interim. I think we need Chris wg-chair to schedul= e an interim meeting. Not clear who would lead the discussion if Chris di= d not want to do it with his chair hat on but Chuck and Chris wg-member se= em like likely candidates. - With regard to the suggestion that we might address this as part of the bis, I think this is not doable, given the need to bring this work t= o closure. If the wg can quickly arrive at some likely future direction, there is some preparatory work that could be done as part of the bis. I'= m thinking we might define the uid/gid string as beginning with a preparat= ory type:: and providing that future formats can be done as extensions in la= ter extension documents. The case in which there is no such type can be fix= ed as it is now: either a numeric value or name@domain. - It appears to me that Chris's remarks about the confused state if the uid/gid string might reflect an earlier version of the security spec. = As a result of Chris's earlier remarks, I took some steps to clarify this. If those are not adequate, we can discuss that issue at the next interim= , assuming it can be scheduled without undue angst. On Fri, Aug 16, 2024, 12:26=E2=80=AFPM Chuck Lever III wrote: > > > > On Aug 16, 2024, at 11:39=E2=80=AFAM, Chris Inacio wr= ote: > > > > 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 =E2=80=98integer's and then loosely defined =E2=80=98str= ing=E2=80=99. So I=E2=80=99ve > been digging into this and I would say, most definitely, do NOT remove th= e > string. So what I can see so far, is that UID/GID numbers are used when > auth =E2=80=98sys=E2=80=99 is the selected mechanism, where current the s= tring is used when > auth is tied to GSS-API. As far as I can tell, the kerberos principal na= me > should be the string in the field. I certainly don=E2=80=99t 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 i= t, > and HOLY RAT HOLE ROBIN is that confusing in practice.) > > > > So, the thing I=E2=80=99m 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. > > > > That also opens a fairly different control domain. Kerberos is well > suited to local enterprise control. You can do that with X.509, but > really, my anecdotal experience says, X.509 certs for enterprise are too > heavy a lift, but they=E2=80=99re the answer when you want a more global = identity. > That raises the question of target users of NFS protocol. And if we=E2= =80=99re (or > maybe that=E2=80=99s just me doing it?) opening a wound there =E2=80=93 t= hen maybe we want > to be able to support authentication and authorization that is more cloud > compatible, which is potentially more than X.509. > > > > These are just thoughts and feedback on some discussions. > > > > Chris > > > > > > P.S. > > > > The complexity of auth is BONKERS!!! So to kind of dig into this I hav= e > a freenas server running with ZFS as the backing store. It=E2=80=99s the= FreeBSD > variant 13.0 stream. I then deployed an LDAP and Kerberos solution > (freeipa on Fedora) to have that running on an RPi4. (This is all in my > house, by the way.) For clients, I have a _real_ menagerie of machines: M= ac > OS 14.6, RPi Raspbian, FreeBSD, and Win 11. For fun, that means NFS > versions running are: Mac OS 14.0 - NFSv4.0, Raspbian/Linux NFSv4.2, > FreeBSD 13.x - NFSv4.1, Win 11 - NFSv3. I can get most of the unixen to = at > least get a Kerberos user principal TGT. Machine-to-machine, host > principals are still a bit of a challenge. The Windows machine seemingly > would rather piss in my Cheerios than do what I want. (What engineer whe= re > convinced their UI people to be able to give error messages as =E2=80=981= 450 > resource unavailable=E2=80=99 and then you need to type `net helpmsg 1450= ` to get > an actual error message, which is completely useless anyway? That person > is either my hero or the devil.) And while Windows doesn=E2=80=99t want t= o > cooperate at all, the unixen management of authentication identities is i= ts > own entire disjoint universe! =E2=80=98SSSD' on Linux, =E2=80=98nfsuserd= ' on FreeBSD, and > I haven=E2=80=99t even tried to cross that bridge on Mac. So I=E2=80=99m= still trying to > get this collection of stuff to attempt to do full kerberos/gss-api > negotiation on a mount. > > > > > > Maybe this is why people run with auth sys! > > No "maybe" about it, this /is/ why people stick with auth_sys. > > > -- > Chuck Lever > > > _______________________________________________ > nfsv4 mailing list -- nfsv4@ietf.org > To unsubscribe send an email to nfsv4-leave@ietf.org > --0000000000000e2a73061fded8f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I want to respond to Chris's email, = although Gmail has somehow swallowed it.

At the risk of contributing to an ongoing case of multiple perso= nality disorder =F0=9F=98=95,=C2=A0 Chris as wg member is alone on the To l= ine,=C2=A0 while Chris, the wg chair, is part of the cc list as a member of= nfsv4-chairs.

I don'= ;t=C2=A0 have all that much to contribute to discussion of possible authent= ication extensions but there are a few peripheral remarks below that relate= to Chris's email.

<= ul>
  • I believe Chris is right about the desirability of a discussion of t= his at a subsequent interim.=C2=A0 I think we need Chris wg-chair to schedu= le an interim meeting.=C2=A0 Not clear who would lead the discussion if Chr= is did not want to do it with his chair hat on but Chuck and Chris wg-membe= r seem like likely candidates.
  • With regard to the suggestion that w= e might address this as part of the bis, I think this is not doable, given = the need to bring this work to closure.=C2=A0 If the wg can quickly arrive = at some likely future direction, there is some preparatory work that could = be done as part of the bis. I'm thinking we might define the uid/gid st= ring as beginning with a preparatory type:: and providing that future forma= ts can be done as extensions in later extension documents.=C2=A0 The case i= n which there is no such type can be fixed as it is now: either a numeric v= alue or name@domain.
  • It appears to me that Chris's remarks abou= t the confused state if the uid/gid string might reflect an earlier=C2=A0 v= ersion of the security spec.=C2=A0 As a result of Chris's earlier remar= ks, I=C2=A0 took some steps to clarify this.=C2=A0 If those are not adequat= e, we can discuss that issue at the next interim, assuming it can be schedu= led without undue angst.




    • On Fri, Aug 16, 2024, 12:26=E2=80=AFPM Chuck Lever III <chuck.lever= =3D40oracle.com@dmarc.ietf.org> wrote= :


    > On Aug 16, 2024, at 11:39=E2=80=AFAM, 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 a= bout how user identity is communicated across NFSv4, and there are 2 option= s, UID/GID =E2=80=98integer's and then loosely defined =E2=80=98string= =E2=80=99.=C2=A0 So I=E2=80=99ve been digging into this and I would say, mo= st definitely, do NOT remove the string.=C2=A0 So what I can see so far, is= that UID/GID numbers are used when auth =E2=80=98sys=E2=80=99 is the selec= ted mechanism, where current the string is used when auth is tied to GSS-AP= I.=C2=A0 As far as I can tell, the kerberos principal name should be the st= ring in the field.=C2=A0 I certainly don=E2=80=99t yet have a full understa= nding about how everything is connected together.=C2=A0 (Just sending the p= rincipal 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=E2=80=99m trying to make sense of, how hard would it b= e 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 authentica= ting
    network peers (ie, hosts). RFC 9289 even says "not for user authentica= tion". So
    I think the term "TLS" here is probably misplaced.

    You instead want to invent a new RPC security flavor or flavors that authen= ticates
    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 sec= urity,
    which doesn't know from users.


    > That also opens a fairly different control domain.=C2=A0 Kerberos is w= ell suited to local enterprise control.=C2=A0 You can do that with X.509, b= ut really, my anecdotal experience says, X.509 certs for enterprise are too= heavy a lift, but they=E2=80=99re the answer when you want a more global i= dentity.=C2=A0 That raises the question of target users of NFS protocol.=C2= =A0 And if we=E2=80=99re (or maybe that=E2=80=99s just me doing it?) openin= g a wound there =E2=80=93 then maybe we want to be able to support authenti= cation and authorization that is more cloud compatible, which is potentiall= y more than X.509.
    >
    > These are just thoughts and feedback on some discussions.
    >
    > Chris
    >
    >
    > P.S.
    >
    > The complexity of auth is BONKERS!!!=C2=A0 So to kind of dig into this= I have a freenas server running with ZFS as the backing store.=C2=A0 It=E2= =80=99s the FreeBSD variant 13.0 stream.=C2=A0 I then deployed an LDAP and = Kerberos solution (freeipa on Fedora) to have that running on an RPi4.=C2= =A0 (This is all in my house, by the way.) For clients, I have a _real_ men= agerie of machines: Mac OS 14.6, RPi Raspbian, FreeBSD, and Win 11.=C2=A0 F= or fun, that means NFS versions running are:=C2=A0 Mac OS 14.0 - NFSv4.0, R= aspbian/Linux NFSv4.2, FreeBSD 13.x - NFSv4.1, Win 11 - NFSv3.=C2=A0 I can = get most of the unixen to at least get a Kerberos user principal TGT.=C2=A0= Machine-to-machine, host principals are still a bit of a challenge.=C2=A0 = The Windows machine seemingly would rather piss in my Cheerios than do what= I want.=C2=A0 (What engineer where convinced their UI people to be able to= give error messages as =E2=80=981450 resource unavailable=E2=80=99 and the= n you need to type `net helpmsg 1450` to get an actual error message, which= is completely useless anyway?=C2=A0 That person is either my hero or the d= evil.) And while Windows doesn=E2=80=99t want to cooperate at all, the unix= en management of authentication identities is its own entire disjoint unive= rse!=C2=A0 =E2=80=98SSSD' on Linux, =E2=80=98nfsuserd' on FreeBSD, = and I haven=E2=80=99t even tried to cross that bridge on Mac.=C2=A0 So I=E2= =80=99m still trying to get this collection of stuff to attempt to do full = kerberos/gss-api negotiation on a mount.
    >
    >
    > Maybe this is why people run with auth sys!

    No "maybe" about it, this /is/ why people stick with auth_sys.

    --
    Chuck Lever


    _______________________________________________
    nfsv4 mailing list -- nfsv4@ietf.org
    To unsubscribe send an email to nfsv4-le= ave@ietf.org
    --0000000000000e2a73061fded8f5--