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