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

Olga Kornievskaia <aglo@citi.umich.edu> Tue, 08 August 2017 21:28 UTC

Return-Path: <olga.kornievskaia@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 EC75E1324CF for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 14:28:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 r-nyJHeo9lhi for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 14:28:00 -0700 (PDT)
Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::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 C12B91324CE for <nfsv4@ietf.org>; Tue, 8 Aug 2017 14:27:59 -0700 (PDT)
Received: by mail-qk0-x242.google.com with SMTP id x77so4133703qka.4 for <nfsv4@ietf.org>; Tue, 08 Aug 2017 14:27:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AqRfaYjnRnEPrlxvUIRrd2PymN5fl6dx3fRGYCsKt3U=; b=CE6qkI41W7HkAMnlrNQUSvJmnhlhTWvBW/XiGcurM/HTsX4XSjfKRwDIDo36uO/4zr R0v9EI4MGF/UzLKK7s8n7ESLrv/1FIp8Gl21zMQf0+7AMf6/Uvf2yT5wIdmY9/lWohTS YEjazKgXYx90thpSMCPeRp0WhxL7GGVeCrrv/PQCnzQQb2U7YlHlCM07Ss+SOTQVppBg iYYCaGAH1ZtQofTlt1oi+9KBri8zhqghizETCEHjK0J6ZT5E0RCIuQvyF9E/kc2b1b/x a4MY5DFaHOUiQ33F2DhsKrq4QvUZyNlfR1Nmw81rkW2JmvSNYk9PIBCdLdWqE21h/3My Da+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AqRfaYjnRnEPrlxvUIRrd2PymN5fl6dx3fRGYCsKt3U=; b=AJy4J3gp6YX60apyRbLBpFsyj6Wgkp0vwcJQzbjbJ71HsoJrf7iV/MTHRsr328l0v2 4f5YPk7za6SiCyxDb832FPcfio7yrrtvmarfE2tYcYuqEuZnIs0ffXFbVEcsDJyMIgGm +R/yjpRJAE65D0JZp43DTSL9CaIotivBY4WyjddhcLn3beIv/cUEn7DzxogPvXFv9wZP x6yJbQ8GUrUxxr6xTUkHZrXcjWM0F+Jh3qmOip9PM4/BTtBizcE4Z4DXjRQMityUslvV Y5VV3pd0utSbeYRJld/6DYgx3GQJU3gm5TjneBEwHwTA/R/Zcm6aJCixX7iqtr62xxg/ DNKw==
X-Gm-Message-State: AHYfb5jX5nl1iWg9wRAMfxB+HRKhc6XPpllO7cz4SBXnB6qwgzHCxhia L4wVWhacJqV6p0IuxLdAhF3gjiYi6Q==
X-Received: by 10.55.72.206 with SMTP id v197mr7155593qka.133.1502227678930; Tue, 08 Aug 2017 14:27:58 -0700 (PDT)
MIME-Version: 1.0
Sender: olga.kornievskaia@gmail.com
Received: by 10.12.186.148 with HTTP; Tue, 8 Aug 2017 14:27:58 -0700 (PDT)
In-Reply-To: <CAABAsM5dAUxbrNA754nxN0iJpkJ-Zep37xnbycRsZXbPQi+hwQ@mail.gmail.com>
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> <CAABAsM5dAUxbrNA754nxN0iJpkJ-Zep37xnbycRsZXbPQi+hwQ@mail.gmail.com>
From: Olga Kornievskaia <aglo@citi.umich.edu>
Date: Tue, 8 Aug 2017 17:27:58 -0400
X-Google-Sender-Auth: nj4gCi6Gp3Hnit0ZEHbVED4VNXI
Message-ID: <CAN-5tyGTZUgCDtVGhCbiXt4Hs6iGNKrhaKcQp8Vo8AveEX04hw@mail.gmail.com>
To: Trond Myklebust <trondmy@gmail.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, "nfsv4@ietf.org" <nfsv4@ietf.org>, Thomas Haynes <loghyr@primarydata.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/iX7ewjInl1ygvF1XiiuuJ8NefnE>
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:28:01 -0000

On Tue, Aug 8, 2017 at 5:12 PM, Trond Myklebust <trondmy@gmail.com> wrote:
>
>
> 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.
>

Since MDS = KDC then it would know which encryption scheme to use.