Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt
"Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de> Tue, 23 April 2019 18:38 UTC
Return-Path: <tigran.mkrtchyan@desy.de>
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 9A5E8120255 for <nfsv4@ietfa.amsl.com>; Tue, 23 Apr 2019 11:38:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HK_RANDOM_ENVFROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=desy.de
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 Fvmtz9du2SHB for <nfsv4@ietfa.amsl.com>; Tue, 23 Apr 2019 11:38:50 -0700 (PDT)
Received: from smtp-o-2.desy.de (smtp-o-2.desy.de [IPv6:2001:638:700:1038::1:9b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2558C1200E0 for <nfsv4@ietf.org>; Tue, 23 Apr 2019 11:38:49 -0700 (PDT)
Received: from smtp-buf-1.desy.de (smtp-buf-1.desy.de [131.169.56.164]) by smtp-o-2.desy.de (Postfix) with ESMTP id 963BB160118 for <nfsv4@ietf.org>; Tue, 23 Apr 2019 20:38:48 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp-o-2.desy.de 963BB160118
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=desy.de; s=default; t=1556044728; bh=Y9G4ngYTkNkP3zUbAQVHmVJaaNYAhqaJIbe5Q/r3Fls=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=mtkfnoTxtk8eE+Ngs8dEyp6vJG13/y2QksGu0cu4Ykp2DOWYopHydOTMgeAdJRagE iwpKU88x3K6hJ2trTYjIy8PxdTpqO9tTBNyZ/26PQGD72OaUr/ACLSutkP62o7O4wz c4vGiFNx8G1W++gjxEPGbeJ5rKs5E32q5BIshq5o=
Received: from smtp-m-1.desy.de (smtp-m-1.desy.de [131.169.56.129]) by smtp-buf-1.desy.de (Postfix) with ESMTP id 8F8141201D0; Tue, 23 Apr 2019 20:38:48 +0200 (CEST)
X-Virus-Scanned: amavisd-new at desy.de
Received: from z-mbx-2.desy.de (z-mbx-2.desy.de [131.169.55.140]) by smtp-intra-3.desy.de (DESY-INTRA-3) with ESMTP id 58E071029; Tue, 23 Apr 2019 20:38:48 +0200 (MEST)
Date: Tue, 23 Apr 2019 20:38:48 +0200
From: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>
To: Dave Noveck <davenoveck@gmail.com>
Cc: Olga Kornievskaia <aglo@umich.edu>, NFSv4 <nfsv4@ietf.org>
Message-ID: <1882195188.1819316.1556044728243.JavaMail.zimbra@desy.de>
In-Reply-To: <CADaq8jcs8esWjkAeiZFULp0wZ_DqQh54KcMJ3=BMnXjsTYHo2g@mail.gmail.com>
References: <155535049832.10773.1565621811584007627@ietfa.amsl.com> <CADaq8jcCB9g9v=h4iXu1f6=cAsU7wMdmfh31gCQKvEFw2eG=rA@mail.gmail.com> <804CB622-D696-4FAA-8040-993CB4029508@oracle.com> <20190422154814.GH72232@kduck.mit.edu> <1675709053.1664834.1556009043904.JavaMail.zimbra@desy.de> <CAN-5tyEQA_XiWW7Ry3SfHQYN46cdoSgUqKT3wx6YLn1t9PB18w@mail.gmail.com> <CADaq8jcs8esWjkAeiZFULp0wZ_DqQh54KcMJ3=BMnXjsTYHo2g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Zimbra 8.8.10_GA_3781 (ZimbraWebClient - FF66 (Linux)/8.8.10_GA_3786)
Thread-Topic: I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt
Thread-Index: pbTsWn1re6hHZ1ZNe5Uf2jcnNB/LJw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/pFF0c7omwQTmjuKH3iKvy6dlTos>
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 23 Apr 2019 18:38:53 -0000
----- Original Message ----- > From: "Dave Noveck" <davenoveck@gmail.com> > To: "Olga Kornievskaia" <aglo@umich.edu> > Cc: "Tigran Mkrtchyan" <tigran.mkrtchyan@desy.de>, "NFSv4" <nfsv4@ietf.org> > Sent: Tuesday, April 23, 2019 4:46:15 PM > Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt > Yes the mount will fail as you describe, but, in that case, the error would > be first detected when you try to access the krb5-only fs. In the case > Tigran > is mentioning, the server is interested in preventing unencrypted access > from > the beginning. > Exactly, with sys=krb5x you still allow other securities as long as server have no idea which export do you want to access. I suggest to document specify server/client interaction where server allows only NULL and STARTTLS over a plain connection. Tigran. > This can be an issue in liight of the fact that there is no way (without > rpc-tls) > to cause such operations as EXCHANGE_ID and CREATE_SESSION to be > done with privacy protection. Also, if the server supports AUTH_SYS at > all, > I think it has to accept it for these operations (again no privacy). The > problem > that this leads to is that the clientid and sessionid are the kind of > protocol artifacts that RFC7258 warns us against making observable. In > the > case of NFSv4.1 they can be the basis of denial of service attacks in that > once the COMPOUND is accepted (easy if AUTH_SYS is supported by > the server at all; not much more difficult in the RPCSEC GSS case since only > a single user needs to be compromised), spurious COMPOUNDs can be > issued so that a legitamate client will have its requests rejected since > they apear > to have invalid slot sequence values :-(. > requests > > > On Tue, Apr 23, 2019 at 9:42 AM Olga Kornievskaia <aglo@umich.edu> wrote: > >> On Tue, Apr 23, 2019 at 4:44 AM Mkrtchyan, Tigran >> <tigran.mkrtchyan@desy.de> wrote: >> > >> > >> > >> > The other aspect that probably makes sense to describe is the behavior >> > when server insist on TLS, some thing like that only operation NULL >> > is accepted and anything else fails with error AUTH_TOOWEAK or similar. >> > In general, the point is not to enforce one or an other way, but clearly >> > specify the client/server interaction to avoid ambiguity for >> implementors. >> > IOW, pure egoism :) >> >> Isn't this already taken care of by the NFS layer. Say my server is >> exporting only krb5 flavors and my client mounts with sec=sys, I will >> get a ERR_WRONGSEC back and mount would fail. >> >> > >> > Tigran. >> > >> > ----- Original Message ----- >> > > From: "Benjamin Kaduk" <kaduk@mit.edu> >> > > To: "Chuck Lever" <chuck.lever@oracle.com> >> > > Cc: "NFSv4" <nfsv4@ietf.org> >> > > Sent: Monday, April 22, 2019 5:48:15 PM >> > > Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt >> > >> > > On Tue, Apr 16, 2019 at 01:11:54PM -0400, Chuck Lever wrote: >> > >> >> > >> > On Apr 16, 2019, at 1:09 PM, David Noveck <davenoveck@gmail.com> >> wrote: >> > >> > >> > >> > I'm confused by the addition of the word "opportunistically" in the >> abstract. >> > >> > This document defines an important way of providing security to >> RPC-based >> > >> > protocols such as NFSv4, so as to deal with the very real security >> problemms >> > >> > that these protocols have. While these facilities can only be >> used when both >> > >> > client and the server provides support, I don't think that fact >> alone make the >> > >> > use of these facilties "opportunistic". What exactlty is this >> word intended >> > >> > to imply? >> > >> >> > >> "Opportunistic" is a term of art. See: >> > >> >> > >> https://en.wikipedia.org/wiki/Opportunistic_TLS >> > > >> > > RFC 7435 is also a good reference for this topic (and one that has IETF >> > > consensus, FWIW). >> > > >> > > The summary of the reasoning for the use of this term is basically >> that it >> > > does not provide protection in the face of an *active* attacker (that >> can >> > > force downgrade to the previous/insecure technology), but does protect >> > > against passive observation. >> > > >> > > -Ben >> > > >> > > _______________________________________________ >> > > nfsv4 mailing list >> > > nfsv4@ietf.org >> > > https://www.ietf.org/mailman/listinfo/nfsv4 >> > >> > _______________________________________________ >> > nfsv4 mailing list >> > nfsv4@ietf.org >> > https://www.ietf.org/mailman/listinfo/nfsv4 >> >> _______________________________________________ >> nfsv4 mailing list >> nfsv4@ietf.org >> https://www.ietf.org/mailman/listinfo/nfsv4
- [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.t… internet-drafts
- [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-rpc-tls… Chuck Lever
- Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-rpc… Trond Myklebust
- Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-rpc… David Noveck
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… David Noveck
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… Chuck Lever
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… David Noveck
- Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-rpc… Mkrtchyan, Tigran
- Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-rpc… Trond Myklebust
- Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-rpc… David Noveck
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… Chuck Lever
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… David Noveck
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… Chuck Lever
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… Chuck Lever
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… Benjamin Kaduk
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… Mkrtchyan, Tigran
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… Olga Kornievskaia
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… David Noveck
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… Mkrtchyan, Tigran
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… Chuck Lever
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… David Noveck
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… Chuck Lever
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… David Noveck
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… Chuck Lever
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… Mkrtchyan, Tigran
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… David Noveck