Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf-nfsv4-flex-files-15: (with DISCUSS and COMMENT)

Tom Haynes <loghyr@gmail.com> Wed, 11 April 2018 00:02 UTC

Return-Path: <loghyr@gmail.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 E3DEF12D876; Tue, 10 Apr 2018 17:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 eSJz_jpkvxiz; Tue, 10 Apr 2018 17:02:10 -0700 (PDT)
Received: from mail-pl0-x242.google.com (mail-pl0-x242.google.com [IPv6:2607:f8b0:400e:c01::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D759712D944; Tue, 10 Apr 2018 17:02:10 -0700 (PDT)
Received: by mail-pl0-x242.google.com with SMTP id bj1-v6so33104plb.8; Tue, 10 Apr 2018 17:02:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zLUnuc9O0a2Lqu0Pi+MC2GMvBalmjJlnaahIZDOkvtI=; b=F6smTwSE/cX1vt2K38YSyrHC7uQ6j5AJI7ZshJZQTpcYqB+qcan8lpXLvNOQMa8xAU CLO/orBW9K9ypSJ/YeJAvYcWR/1bZuLiyy1+E3rRf/0LYzqUpExbwd2ubqCzle5b2WNQ kbgoVKD+gXxlSufqrWHdYh+q7QZnzAFdaKwp9hBjOqM3BKZf4ASUrT2q0ZzUKz0p/5+6 ZRcQc0UZZq+1+8U1pR03kKhQD66uCJ6RNGj2LyAtoo7Qnn/tyvvD54zSQ4cReEGBXYOJ I/gAhycyBU0FPbltXKGR/JMn852rgJIFdvbA/dP7H3Zo1L8gRS9hUV59atYmgXgFB5za gNXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zLUnuc9O0a2Lqu0Pi+MC2GMvBalmjJlnaahIZDOkvtI=; b=JfJGkiZaXaf1Nr66HmvizmziAOY04/SMr26pXj6pov7nZlgeJz6waIU5QgdcUgUqBV J51DnNuZRc+nd610T0hIXvjzfcpQpIZw0JNcsxdSKwSq2RL2p0WTtwYJskkmCksFXFVU lBLWc769+Pc650MkgmIuzQWWYCVEcKHbpakKdcPQjWek2tBX5i+lgvpqXHhEszuX+cAj pQtg1OOBJ0m4/7j+NFWkYtvapSgcW8ZfMOTFdzRxGigt7YBK41Ypf30IUSR02YVLzL6R +0tRnAxpcDSMdBzMlKdlyOnsgzlAtX4y/gtA2az7nebjdP+/t0fSeojzNawskLKH5yi1 KA2A==
X-Gm-Message-State: ALQs6tAaL/yoxB713XMF1l40yqGVj+SHD1kF4rPOJ241La1XaHL3rEXv beDDqKE0tSNnRw/epecm3SE=
X-Google-Smtp-Source: AIpwx4+3NUL44G9W0YAh0Vy4qFhWcfpT263YfSbR0afZATeOo5DhQCOePQ4iV9gt2G+wUnRKkPseRg==
X-Received: by 2002:a17:902:6ac1:: with SMTP id i1-v6mr2513293plt.152.1523404929089; Tue, 10 Apr 2018 17:02:09 -0700 (PDT)
Received: from kinslayer.corp.primarydata.com (63-157-6-18.dia.static.qwest.net. [63.157.6.18]) by smtp.gmail.com with ESMTPSA id q15sm6188726pgv.7.2018.04.10.17.02.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Apr 2018 17:02:08 -0700 (PDT)
From: Tom Haynes <loghyr@gmail.com>
Message-Id: <FD8AF7AF-632A-461C-A82A-BC0711B2F8D0@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F394D757-AE38-459D-878B-8A00ADC45C50"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Tue, 10 Apr 2018 17:02:07 -0700
In-Reply-To: <CABcZeBPM_Rnb0QZvbvBpUCNd6yurtz0ipexUQscmnG_samb2RA@mail.gmail.com>
Cc: Spencer Dawkins <spencerdawkins.ietf@gmail.com>, The IESG <iesg@ietf.org>, draft-ietf-nfsv4-flex-files@ietf.org, NFSv4 <nfsv4@ietf.org>, nfsv4-chairs@ietf.org
To: Eric Rescorla <ekr@rtfm.com>
References: <151683050192.22597.10931170494891133045.idtracker@ietfa.amsl.com> <9FD918F5-D08C-45FC-B6BB-30CBB3D4EC51@gmail.com> <CABcZeBPE5gV3KPpRpRxAtYRSSCZh8+3-fcf-1VsxF3AxmomnwQ@mail.gmail.com> <F2ADAD73-6AB3-45EF-B6FE-033E01F58D8E@gmail.com> <CAKKJt-e=81qyR3YXNb9imu8kzk6+nCYgMjeZqHNwt3xi4CfNxQ@mail.gmail.com> <CABcZeBPM_Rnb0QZvbvBpUCNd6yurtz0ipexUQscmnG_samb2RA@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/QxhlVldk8aq0Wa2fEaC64_ZO9Us>
Subject: Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf-nfsv4-flex-files-15: (with DISCUSS and COMMENT)
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: Wed, 11 Apr 2018 00:02:13 -0000

No, it does not have better security than typical NFS, it has the same security.

The synthetic IDs control access to the files and the metadata server can
modify them to fence off a rogue client*, but in the end, the security of any
AUTH_SYS approach is limited.

* By rogue client I do not mean malicious, I mean one which had established
a connection with the metadata server, was handed a layout, and then when
the layout was recalled, took over 91s to return that layout. It is probable that
there is a network partition between the client and the metadata server and
it is unknown if there is one between the client and the storage device. The
fencing act causes the client to become aware that it needs to once again
reach out to the metadata server.

The security aspect of this version of the flex file layout type is to be as secure
as any other NFS in a data center environment.

The goal of the next version of the flex file layout type is to be as secure
as any other NFS in the WAN. I.e., kerberized connections.

> On Apr 10, 2018, at 4:25 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> Not entirely. I'm inferring from the following text that this draft is
> supposed to have somewhat better security than typical NFS, but it's
> not really clear.
> 
> 
>    If the configuration of the storage device is such that clients can
>    access the directory namespace, then the access control degrades to
>    that of a typical NFS server with exports with a security flavor of
>    AUTH_SYS.
> 
> On Tue, Apr 10, 2018 at 11:43 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com <mailto:spencerdawkins.ietf@gmail.com>> wrote:
> Hi, Eric,
> 
> On Mon, Apr 2, 2018 at 2:56 PM, Tom Haynes <loghyr@gmail.com <mailto:loghyr@gmail.com>> wrote:
> Hi Eric,
> 
> Kathleen has removed her “discuss” from this document (the new version was pushed,
> which satisfied her need for the SecDir review.
> 
> Could you please revisit your position on this draft?
> 
> I'm just following up on this one - could you take a look at whether -17 addresses your Discuss position?
> 
> Thanks,
> 
> Spencer
> 
> (diff from telechat version is https://tools.ietf.org/rfcdiff?url1=draft-ietf-nfsv4-flex-files-15.txt&url2=draft-ietf-nfsv4-flex-files-17.txt <https://tools.ietf.org/rfcdiff?url1=draft-ietf-nfsv4-flex-files-15.txt&url2=draft-ietf-nfsv4-flex-files-17.txt>) 
>