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

Trond Myklebust <trondmy@gmail.com> Tue, 08 August 2017 23:56 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 C89E8132016 for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 16:56:36 -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 PiTZ098Hdg5v for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 16:56:33 -0700 (PDT)
Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (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 2B24813219A for <nfsv4@ietf.org>; Tue, 8 Aug 2017 16:55:48 -0700 (PDT)
Received: by mail-ua0-x235.google.com with SMTP id f9so22263152uaf.4 for <nfsv4@ietf.org>; Tue, 08 Aug 2017 16:55:48 -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=aD4Jk/UizuCfJYCYxyg01ZF79ERZ9JAv7ub/XUMbStU=; b=JePandGeYElP2pASo808dY4vLKjmvyRb7zXcVUeccPvH7V7d9q5d+4HQczD0T+2lNT 0aA75hfVidL+rVqQ3DRGtiXCABHXg9/uNnxHmF5ipzHqc8vLJHLnVtV7LXPQXYfRZbgT NRkonB5J3awW0HFievcI8Lce+MG+Cn6yfCq6Av+i2pPktaSrMRVZJ/mVPLi45TjsKDWQ KExyQFNucItHEP4+6oKDCue1OHm+2NAG/bxvxkeR1ZDGc5MN3rb6DPws9gbFdBIRNKlZ YopZgvy1UV+8wtscYid7vktbCjCAsbj+VzhUmw/mJJ4hCbzqT0ixu4kcmpNx3Izl0kqr rHUw==
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=aD4Jk/UizuCfJYCYxyg01ZF79ERZ9JAv7ub/XUMbStU=; b=aKDTp3Fq/NqZys+/w/nFN5qovXCDwcNenX6Fl1zEIja1cJ1ZvlCc3A20T4/3Xpd7oK WjHzOjujpqvVtrNlKruxNGpsXL/C/XX2QifJ1jcuDaJpv9eMyc4Gq2h87dwTbz6cCrDe 2JNpF7WCGvijwAKZ2elPnrYXDaRqG/78Xlug03HV2iGRUzvYdlOniBUNSFA5L4Tm1is2 mQlv9PDPLhCn5J81wSf/0S3as7ZXT5TVZ/p+CzT76uDWyb7XXS6ACuvWs2KfJKjSnJ5k ERGEsrGAMmdXrQQcpRI+24tMyl2fNmHYpDhBuTa63e4+MUpfonSGYnDd//7lMCmh6ICt CGiA==
X-Gm-Message-State: AHYfb5i5x3gjszSsRefnQCZAffRezCY46oMeKlKxb/IHYx607J27FRZI lWe4CbuY6grJQPGPhZx0Vre6wunXeQ==
X-Received: by 10.159.34.73 with SMTP id 67mr4559408uad.90.1502236547014; Tue, 08 Aug 2017 16:55:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.27.28 with HTTP; Tue, 8 Aug 2017 16:55:46 -0700 (PDT)
In-Reply-To: <20170808232729.GU70977@kduck.kaduk.org>
References: <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> <CAABAsM7iB_KRNFVmd8p4UTmEZSBj01uZoDhHt+827DzpmveuHQ@mail.gmail.com> <CC8CD648-2657-4CC1-ACDD-C7FF8B3BEADB@gmail.com> <20170808232729.GU70977@kduck.kaduk.org>
From: Trond Myklebust <trondmy@gmail.com>
Date: Tue, 8 Aug 2017 19:55:46 -0400
Message-ID: <CAABAsM4xo7-TWktFTcQJ92RCeBfJ0s9ukbAe8LB_X1sguqgpKA@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Olga Kornievskaia <olga.kornievskaia@gmail.com>, Olga Kornievskaia <aglo@citi.umich.edu>, "nfsv4@ietf.org" <nfsv4@ietf.org>, Thomas Haynes <loghyr@primarydata.com>
Content-Type: multipart/alternative; boundary="001a113df5f8c0e7b7055646b307"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/5d0lEjF_PxP4QAocvs8wsc3wp6I>
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 23:56:37 -0000

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

> On Tue, Aug 08, 2017 at 06:01:48PM -0400, Olga Kornievskaia wrote:
> >
> >
> > > On Aug 8, 2017, at 5:44 PM, Trond Myklebust <trondmy@gmail.com> wrote:
> > >> >
> > >>
> > >> 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.
> >
> >
> > But mds has access/copy of the principal database so it knows encryption
> types for the client server keys
>
> There is a possible design where the MDS has access to the KDC's database,
> yes.
> There are a couple other possible designs, though, and I don't think we've
> ruled them out yet (whether due to technical constraints that cause them
> to not actually work, policy decisions, or other).
>
> (1) MDS is colocated with KDC or otherwise has access to the KDC database.
>
> It's easy to get policy consistency between the KDC and MDS, find out about
> supported enctypes, etc.  Issuing tickets is also easy and can be done with
> direct database access and reuse a lot of code; the normal policy checks
> are applied, authorization data can be included as usual, etc.  Actual
> principal
> entries can be created/destroyed on demand for handing out as synthetic
> credentials.  Access control can be done via synthetic client principal
> name or authorization data in the tickets.
>
> But, it adds more code running on the highly-privileged KDC machine, and a
> bug
> in the MDS risks compromising the entire Kerberos realm -- a monstrous
> rekeying/re-enrolling task.
>
> (2) MDS is permitted by the KDC to use S4U2Proxy
>
> This has some nice properties, like letting the KDC keep an audit trail
> from the initial client authentication to the issued synthetic ticket and
> separating the MDS from the KDC.  But, it is harder to create/destroy
> client principal entries on demand, and most likely access control would
> need to be done via authorization data in the resulting ticket.  (The KDC
> might need to know to preserve and/or validate that authorization data
> as part of the S4U2Proxy flow, but generally it should allow unknown
> authorization data in the request to be preserved in the resulting ticket.)
> The data server might need modification to use the Kerberos authorization
> data for access control decisions.
>
> (3) MDS knows data server's private key
>
> This essentially makes the MDS trusted to emulate/hijack the data server's
> NFS role, by making the key formerly shared between just the data server
> and the KDC also shared by the MDS.  That key is used for authentication
> and integrity (source) validation, so the MDS could impersonate the KDC
> to the data server or vice versa.
>
> This is very flexible about ticket "issuance", again allowing arbitrary
> synthetic client principal names to be used and authorization data to be
> inserted.  But, it causes the KDC to lose visibility into what is happening
> in the Kerberos protocol and may have weaker auditability properties.
>
> It also requires sharing the private key of the data server with another
> party, which is in general something that should be avoided when using
> Kerberos -- this sort of problem is one of the things that S4U2Proxy was
> designed to address.
>
>
> All three of these are only considering how to get a Kerberos ticket that
> the MDS and/or client can ues to authenticate to the data server using
> GSS-API; the details of how credentials and/or keys are conveyed from the
> MDS to the client are a different problem, one that seems independent
> of which of the above three options is taken.
>
>
There is a fourth option.

Give the MDS its own KDC and own domain that is completely separate and
untrusted by the corporate domain. The DSes would be required to recognise
principals from that domain, and not from the corporate domain.

The reason why that might be compelling is to ensure that principals that
are generated to support synthetic uids and gids may not be used to
authenticate to anything else in the corporate domain.

It also ensures that someone with a principal from the corporate domain has
no special privileges to access data on the DSes unless granted a layout by
the MDS.

IOW: the idea is to keep the authentication domain for the pNFS data path
entirely private to the storage system, while using the corporate domain to
authenticate to the MDS.