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

Trond Myklebust <trondmy@gmail.com> Tue, 08 August 2017 21:44 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 9E7DB13249A for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 14:44:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 bVEec5nelHhV for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 14:44:29 -0700 (PDT)
Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 72E66132495 for <nfsv4@ietf.org>; Tue, 8 Aug 2017 14:44:29 -0700 (PDT)
Received: by mail-vk0-x22b.google.com with SMTP id j189so19062222vka.0 for <nfsv4@ietf.org>; Tue, 08 Aug 2017 14:44:29 -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=023fnAsOtIh2I3abwJQfHQyFHrR/Oeaqi4D+6aGu4O4=; b=DEY9zPyL8vLltOn3UlGro5JC0DjPVZk+XxUWLNWkrxmRb3w/2tmniqSjoaRrsjCzOr 4I829UaVfDWvdh5HdcBZerb0XXuhke98PHa0EemPAVe9FA32mR0DG03CN+56FQ/Fe39W HBsEdY+eFvXdMlwqwGUI/IuUhu/T/c3hd1zE1Ub3Qu8klIt+QQAd3kDiTCjy5v0RoFTj 6qu/8PgTpjhSOLE5+S2XkwLGWxEW7P0ELy35dGYtdm8X855D/AZWIbYAB64c0lsBWs08 YuqJldjVseAJUBkwwWCP0nYu7xSUYMJScg2SJDqoGD7UkcU83bMF9q7YvXYM1OeNelIi 4fqg==
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=023fnAsOtIh2I3abwJQfHQyFHrR/Oeaqi4D+6aGu4O4=; b=RQDyGclt0Pvmv/lBGPDEdvFkEk6nqHZp6CFk9sGlWkVijgvxkcSQgLVbCbq5/j4fAH /cKKM6XLoo3O+oDedraa1fbZ0w6x5eUC3VvEy76evV5upmfC7Qx4fLjtfaVr51sqIyFh cN5cseTQWvaAvEgmBSvKiRyPeh9jTPIFWZ5LjUOdGCrtxceeOD4W4jAxE0GOFqzTh3hq Hn21z5TaRCTsamBlei1bDagZHA+gLG0Ptx6YNgjBUonKGEMZrX+CinfFN3OohjtUxLsh zSnk8LVfJYZ+UTx+Q38r7QHCc+qkeGsNWe+btvmjvh/jcsbSfYBmM9SbkKTLaqPLLDCE y3wA==
X-Gm-Message-State: AHYfb5jbtt2CKn1gFfCpgCNnbilJONFszkEfFSKXzhqoCZPBW+gR40gw 6GCLQ+fi9Cu5WfLtG46hJUZMmWU0dA==
X-Received: by 10.31.198.135 with SMTP id w129mr3911483vkf.169.1502228668455; Tue, 08 Aug 2017 14:44:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.27.28 with HTTP; Tue, 8 Aug 2017 14:44:27 -0700 (PDT)
In-Reply-To: <CAN-5tyGTZUgCDtVGhCbiXt4Hs6iGNKrhaKcQp8Vo8AveEX04hw@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> <CAN-5tyGTZUgCDtVGhCbiXt4Hs6iGNKrhaKcQp8Vo8AveEX04hw@mail.gmail.com>
From: Trond Myklebust <trondmy@gmail.com>
Date: Tue, 8 Aug 2017 17:44:27 -0400
Message-ID: <CAABAsM7iB_KRNFVmd8p4UTmEZSBj01uZoDhHt+827DzpmveuHQ@mail.gmail.com>
To: Olga Kornievskaia <aglo@citi.umich.edu>
Cc: Benjamin Kaduk <kaduk@mit.edu>, "nfsv4@ietf.org" <nfsv4@ietf.org>, Thomas Haynes <loghyr@primarydata.com>
Content-Type: multipart/alternative; boundary="001a114d5b0427a19b055644defd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/hQPwu1wZ-QC5Y_edR7ShtsvmsBQ>
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:44:32 -0000

On 8 August 2017 at 17:27, Olga Kornievskaia <aglo@citi.umich.edu> wrote:

> 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.
>

The client will usually authenticate to the MDS using the corporate KDC.
The KDC on the MDS itself is not required to be the same.