IETF Logo Mail Archive

Re: [nfsv4] New wording of Security Section for Flex Files

Thomas Haynes <loghyr@primarydata.com> Fri, 04 August 2017 21:45 UTC

Return-Path: <loghyr@primarydata.com>
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 5B18F128A32 for <nfsv4@ietfa.amsl.com>; Fri, 4 Aug 2017 14:45:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primarydata.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhvNcKiQbm1K for <nfsv4@ietfa.amsl.com>; Fri, 4 Aug 2017 14:45:23 -0700 (PDT)
Received: from us-smtp-delivery-194.mimecast.com (us-smtp-delivery-194.mimecast.com [216.205.24.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437751287A5 for <nfsv4@ietf.org>; Fri, 4 Aug 2017 14:45:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=primarydata.com; s=mimecast20170802; t=1501883122; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references; bh=efyAI616eWkAgdlBdVlue/L/AXkV1eNGMZ3kGml3XfQ=; b=H9amJZN3AkwO5UZaZ0R0LbPlDbbQbfA2Yf+lmkmEOq+GaIZxdhvE67sgrErN8bEC+MNqDxG4o7tJKTcrynglxw2VlOMkHvN9atOVm97mX17OSmDoXgbB2jHxlNBNEBm5NmtA1Y9FEvUMKhyNvpO70g28OpR0+AXEEhiYEcj4Y/8=
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0050.outbound.protection.outlook.com [207.46.163.50]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-55-BDnOCbc0ObCZJF4yMEHKnA-1; Fri, 04 Aug 2017 17:45:20 -0400
Received: from BY2PR1101MB1093.namprd11.prod.outlook.com (10.164.166.21) by BY2PR1101MB1093.namprd11.prod.outlook.com (10.164.166.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Fri, 4 Aug 2017 21:45:17 +0000
Received: from BY2PR1101MB1093.namprd11.prod.outlook.com ([10.164.166.21]) by BY2PR1101MB1093.namprd11.prod.outlook.com ([10.164.166.21]) with mapi id 15.01.1304.025; Fri, 4 Aug 2017 21:45:17 +0000
From: Thomas Haynes <loghyr@primarydata.com>
To: Rick Macklem <rmacklem@uoguelph.ca>
CC: Olga Kornievskaia <aglo@citi.umich.edu>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Thread-Topic: [nfsv4] New wording of Security Section for Flex Files
Thread-Index: AQHTBOJTubmEu3G57EqvOqsgsMtAEKJoh0CAgAdGdgCAABDDgIAAGPyAgAFQjwCAA3LeAIAACpDNgAAGtAA=
Date: Fri, 04 Aug 2017 21:45:17 +0000
Message-ID: <024EF099-758A-4459-8C52-78CC08CB0E83@primarydata.com>
References: <9E3B8A6F-E27C-4A65-A0F7-6E0275B0616A@primarydata.com> <20170728022333.GI58771@kduck.kaduk.org> <CAN-5tyG9cE9JhccW7Fnho10jVE-5YnpoArZ=3DZuz79dFFD9sQ@mail.gmail.com> <CADaq8jc=K5f4cia-jFKjDMAtNhZntFE+Xa0=Lb=LSXOy+sc7Ww@mail.gmail.com> <37BF354D-CF56-4A1C-B391-8565F0E38E72@primarydata.com> <CAN-5tyH-j937PPA=nRSA5iEHOTKynryQjwfKui9dgVdZa3oQrQ@mail.gmail.com> <CAFAFD9C-DF89-4867-8880-1EA43FD4095F@primarydata.com> <YTXPR01MB01898E7371F1E3A4E9D75E40DDB60@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>
In-Reply-To: <YTXPR01MB01898E7371F1E3A4E9D75E40DDB60@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [63.157.6.18]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR1101MB1093; 20:akQLIbHG3Hwsl14HDNMWop0SE/syU7Rl9RoOUiQSnwqL/O+6SF4vBl86Mi+XmF0n9NdNZrUcuNgkXC7ziK9rSSq/cFJEIfN9xycFErCVwD4cSwNVIAf1H7a6+UUZAIzwMj31uER1nO7vwKVTBNBmbdhBdSc1Ojd323v3Hn8MPsE=
x-ms-office365-filtering-correlation-id: 35db42ca-1cba-4880-a38d-08d4db8218fb
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(2017082002075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BY2PR1101MB1093;
x-ms-traffictypediagnostic: BY2PR1101MB1093:
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705);
x-microsoft-antispam-prvs: <BY2PR1101MB109360DB427A7A3469004D4DCEB60@BY2PR1101MB1093.namprd11.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(2016111802025)(20161123564025)(20161123555025)(6072148)(6043046)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY2PR1101MB1093; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY2PR1101MB1093;
x-forefront-prvs: 0389EDA07F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39830400002)(39410400002)(39400400002)(377454003)(199003)(24454002)(189002)(3280700002)(38730400002)(3660700001)(54896002)(236005)(53936002)(110136004)(6246003)(81156014)(6512007)(81166006)(82746002)(8676002)(33656002)(68736007)(15650500001)(50986999)(54356999)(2900100001)(76176999)(2950100002)(99286003)(5660300001)(2906002)(189998001)(6916009)(105586002)(8936002)(106356001)(54906002)(93886004)(101416001)(102836003)(3846002)(6116002)(36756003)(97736004)(229853002)(86362001)(25786009)(4326008)(53546010)(83716003)(6436002)(66066001)(7736002)(14454004)(478600001)(6506006)(6486002)(77096006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR1101MB1093; H:BY2PR1101MB1093.namprd11.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-OriginatorOrg: primarydata.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2017 21:45:17.6052 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 03193ed6-8726-4bb3-a832-18ab0d28adb7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR1101MB1093
X-MC-Unique: BDnOCbc0ObCZJF4yMEHKnA-1
Content-Type: multipart/alternative; boundary="_000_024EF099758A44598C5278CC08CB0E83primarydatacom_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/0YjBPTgKKCM66lxi-Bmi4pgdHiY>
Subject: Re: [nfsv4] New wording of Security Section for Flex Files
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Aug 2017 21:45:25 -0000

On Aug 4, 2017, at 2:41 PM, Rick Macklem <rmacklem@uoguelph.ca<mailto:rmacklem@uoguelph.ca>> wrote:

Well, first I'll mention that fattr4_owner and fattr4_owner_group don't
seem to be defined anywhere (not in the RFCs such as 5661 I grep'd).
Presumably, they are strings, so you can define anything you want in them,
can't you?

Having said that. I think all you should do is say "if support of RPCSEC_GSS
is required, tight coupling needs to be used".
I think Olga suggested this in her first post on the topic?

If someone really wants to support RPCSEC_GSS/Kerberos for a loose
coupled pNFS server, let them figure out exactly how to do it and
write that up at that time. (I believe it might be possible, but doubt
anyone will actually implement it. Just like no one implements security
mechanisms other than Kerberos.)


Full disclosure, the reason I want to define it is that Primary Data does
want to implement it, which means we need to have a standard between
at least the client and metadata server.


rick

v2.29.0 | Report a Bug | By Email | System Status