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

[Benjamin Kaduk <[e-mail]>]

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

-Ben