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

Benjamin Kaduk <> Tue, 08 August 2017 23:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B5B5129AD3 for <>; Tue, 8 Aug 2017 16:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5kOq_-bgkO_W for <>; Tue, 8 Aug 2017 16:27:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64B21131D2C for <>; Tue, 8 Aug 2017 16:27:36 -0700 (PDT)
X-AuditID: 12074422-05bff70000001445-bd-598a48e7353f
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 91.11.05189.7E84A895; Tue, 8 Aug 2017 19:27:35 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id v78NRYhx023215; Tue, 8 Aug 2017 19:27:34 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id v78NRUfT018709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Aug 2017 19:27:32 -0400
Date: Tue, 08 Aug 2017 18:27:30 -0500
From: Benjamin Kaduk <>
To: Olga Kornievskaia <>
Cc: Trond Myklebust <>, Olga Kornievskaia <>, "" <>, Thomas Haynes <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.8.3 (2017-05-23)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IRYrdT0X3u0RVp8K6NxWLto6fsFsv3bGW3 mP3+EavF/VcnmC3uPf7K6sDqsaa1k8Vj56y77B5Llvxk8pg/Vy6AJYrLJiU1J7MstUjfLoEr Y1vjX9aCT9IVHy89YW1g3CXWxcjJISFgIvH35iGWLkYuDiGBxUwSL99PZoZwNjBKTOvbxArh XGGS6Oz/yQrSwiKgIrH3524WEJsNyG7ovswMYosIGEscvTgVrJtZYBujxIlHK8ESwgLxEutn P2UEsXmB9p0+eJYdYupXFolPG1awQCQEJU7OfAJmMwtoSdz495Kpi5EDyJaWWP6PAyTMKWAr 0f1jPliJqICyxLx9q9gmMArMQtI9C0n3LITuBYzMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN 9XIzS/RSU0o3MYJD20VpB+PEf16HGAU4GJV4eG/s6YwUYk0sK67MPcQoycGkJMq7SRsoxJeU n1KZkVicEV9UmpNafIhRgoNZSYRXAxhRQrwpiZVVqUX5MClpDhYlcV5xjcYIIYH0xJLU7NTU gtQimKwMB4eSBG8ISKNgUWp6akVaZk4JQpqJgxNkOA/QcD2w4cUFibnFmekQ+VOMilLivE4g CQGQREZpHlwvKPVIZO+vecUoDvSKMO8Ld6AqHmDagut+BTSYCWhwhG8nyOCSRISUVAOjlOPd OelLrnRHLCl/ZmbZYLK9s6dT47dfCV/ovshPbef36ZprVl3OWP3a83TS5/Yy2ydrzp36ppR5 4EvauxeCD9VfeWuIfszx5G0q2foqc27goeKpO2Zd45MNnuNlv3J2uaaqHPM/yYjcfJObRkvb jYp+zgniEC84ISNdkS9RNXVt9FVNuSwlluKMREMt5qLiRACg9DjWGAMAAA==
Archived-At: <>
Subject: Re: [nfsv4] Fwd: New Version Notification for draft-haynes-nfsv4-flex-filesv2-00.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Aug 2017 23:27:38 -0000

On Tue, Aug 08, 2017 at 06:01:48PM -0400, Olga Kornievskaia wrote:
> > On Aug 8, 2017, at 5:44 PM, Trond Myklebust <> 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.