Re: [nfsv4] Fwd: New Version Notification for draft-haynes-nfsv4-flex-filesv2-00.txt

Trond Myklebust <trondmy@gmail.com> Tue, 08 August 2017 21:12 UTC

Return-Path: <trondmy@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 85B61132366 for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 14:12:26 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 0rcUlQ8a7oo1 for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 14:12:23 -0700 (PDT)
Received: from mail-vk0-x243.google.com (mail-vk0-x243.google.com [IPv6:2607:f8b0:400c:c05::243]) (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 39CC81323AF for <nfsv4@ietf.org>; Tue, 8 Aug 2017 14:12:23 -0700 (PDT)
Received: by mail-vk0-x243.google.com with SMTP id z187so2841043vkd.3 for <nfsv4@ietf.org>; Tue, 08 Aug 2017 14:12:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ad5er0mT4q3+rTs8Gp8CRNgrXecyFuIs18CLqDoCiHs=; b=leZDZF7liglmIrM5dbMSPru5ikKurmYoMpPm3YHNAYcSkzA6zYWOz80ZY1VHzi2t2b 000cJWyi356Mra/ntGwN1N0NwXCJVZAvLIjrRutNWyKj5DLLGF1Yho4olr3cA3FWXB/U cWqcyqoJW/B+LXyYzfkWBrZA2cRHmmVxQiIqhEbgdCWRHjHVj/DKYjQswMyxMHeU/oJ+ e4VW91WDwRFO3R5PgPZikr6LJEasXQ6AAsDPl0moii4/11iA/qJ/q0JxrRKRvBQeAypi lhmLcONjY/XWPzF49rVZcKku3y3uxOrh9xjn6zQxrBayn5Zp70FIOZelkG9JOPIjEHO/ FOqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ad5er0mT4q3+rTs8Gp8CRNgrXecyFuIs18CLqDoCiHs=; b=FjgHDrtooxQwhG2cz/S0coL+6pHDYatYIA2lxhHNj5cl0jVWOVhQTTEw1z1QmjDHin GBVYH3fLS1QjHIbPiVXJEY9bQL7EWIdJPEWEcGqtJ5CcbsSl1ebAZ6eKbo8DYF6LttDB U9cqwBL+giBV1XG6cgyAzzoHesk5Th4XPIV5d1f37JQf48MBKMZGSkJB/tqOVWYNwILk zJNvyAGSwf+MWIrFDRbFLNHx4MJrE71qdDlf0j7N+oS1hzt6sVp2ttcXSR7r7AgCV7ha eOMER1N9JsH0olThcr8Lm8SZdWn4dihRD5xAJWNSdBgAyyupfLrk16B4teckBlOIfRWS NhEw==
X-Gm-Message-State: AHYfb5jA/O3TCXq+NzrHUl4RbLmeIhoQwf8FKNIpCqPbl+3H1Gc5dMVg j8Py9PdenIRO+MY3K1hFzt5OXN0J0w==
X-Received: by 10.31.3.146 with SMTP id f18mr3948442vki.184.1502226742257; Tue, 08 Aug 2017 14:12:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.27.28 with HTTP; Tue, 8 Aug 2017 14:12:21 -0700 (PDT)
In-Reply-To: <20170808194916.GR70977@kduck.kaduk.org>
References: <150215110527.12392.18161698955589691126.idtracker@ietfa.amsl.com> <2CA259E3-BD3A-482B-BFBF-3B90425AD3EA@primarydata.com> <CAN-5tyETNMCPVC5wJ-_77vM5+hVB+-uasd37kn+M=hoCeK6P7w@mail.gmail.com> <CAABAsM6rmrDU4BR6Ho7YFjjYA2amEkwuRGtzN537VXUZ-Eh-hg@mail.gmail.com> <20170808185803.GQ70977@kduck.kaduk.org> <CAABAsM7xOpbopPa3v1YMtfcFZbNZ=Jygap37Bg6qGfDDAvRHhQ@mail.gmail.com> <20170808194916.GR70977@kduck.kaduk.org>
From: Trond Myklebust <trondmy@gmail.com>
Date: Tue, 8 Aug 2017 17:12:21 -0400
Message-ID: <CAABAsM5dAUxbrNA754nxN0iJpkJ-Zep37xnbycRsZXbPQi+hwQ@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Olga Kornievskaia <aglo@citi.umich.edu>, "nfsv4@ietf.org" <nfsv4@ietf.org>, Thomas Haynes <loghyr@primarydata.com>
Content-Type: multipart/alternative; boundary="001a11429004582c8b0556446b92"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/WH2hd0P23NjdXk8J0ApiHF1SGys>
Subject: Re: [nfsv4] Fwd: New Version Notification for draft-haynes-nfsv4-flex-filesv2-00.txt
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: Tue, 08 Aug 2017 21:12:27 -0000

On 8 August 2017 at 15:49, Benjamin Kaduk <kaduk@mit.edu> wrote:

> On Tue, Aug 08, 2017 at 03:37:41PM -0400, Trond Myklebust wrote:
> > On 8 August 2017 at 14:58, Benjamin Kaduk <kaduk@mit.edu> wrote:
> >
> > > On Tue, Aug 08, 2017 at 02:54:58PM -0400, Trond Myklebust wrote:
> > > > Why pass Kerberos tickets around? Is there any reason not to just
> pass an
> > > > initialised RPCSEC_GSS session handle?
> > >
> > > There's not a standard serialization of the GSS security context object
> > > that it contains, for transfer across the network.
> > >
> >
> > I thought rfc1964 provides one, which is pretty much the basis for the
> user
> > library gss_krb5_lucid_context_v1_t typedef. Am I mistaken?
>
> I only see formats for security context establishment (negotiation) tokens,
> which are exchanged so that the peers can establish a complete security
> context -- I think you're mistaken.
>
> AIUI the gss_krb5 lucid contexts came about due to the need to establish
> a GSS security context in userspace and then export the keying material
> into the kernel for per-message processing (for NFS).  I'm only about 95%
> sure, but the information from a lucid context ought to be enough to
> send from MDS to client and let the client use RPCSEC_GSSv3.  The
> lucid context is a per-implementation extension, though, and we can't
> use it in our standard without standardizing the lucid context first.
>

Right, but there are some issues with just passing back a KRB5 service
ticket too.

For one thing, how does the MDS choose which encryption scheme to use? It
knows what encryption the client is using for the RPCSEC_GSS session, but
presumably it has no idea what kind of ticket was used to negotiate that
session.