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

[Trond Myklebust <[e-mail]>]

On 9 August 2017 at 14:36, Olga Kornievskaia <[e-mail]>
wrote:

> On Tue, Aug 8, 2017 at 7:55 PM, Trond Myklebust <[e-mail]> wrote:
> >
> >
> > On 8 August 2017 at 19:27, Benjamin Kaduk <[e-mail]> wrote:
> >>
> >> 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.
> >>
> >
> > 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.
>
> I keep coming back to the question of what's different about assuming
> that MDS and storage server belong to the same Kerberos realm (whether
> or not it's corporate or private) and the tightly-coupled model where
> everybody belongs to the same realms and normal ACL-based control is
> used? Why is using normal principals and ACLs is ok in the
> tightly-coupled model but it's not for loosely-coupled?
>

In the tightly coupled model, the server has a special control channel to
the DS, and which it uses to enforce the layout semantics.

In the loosely coupled model, the control channel is NFSv3 and so layout
enforcement needs to be done by other means; in practice the only way to do
so is to use access controls. Please see the discussion about synthetic
uids and gids in the existing flex files draft for how it works.

The options I see for how to send the ticket back,  if it's a private
> realm, then krb5p must be used and encrypt the secret that's also in
> the service ticket. If it's a corporate realm, then krb5i could be
> used and secret encrypted with the user's key. Maybe you can create a
> return structure such that allows for either of the approaches. If
> this flag is set, then client should decrypt with one and with another
> otherwise. Then the implementors/administrators can decide whether
> they want private realms or shared MDS/KDC appoarch.
>
>
The expectation is that the client would need to use krb5p to protect the
LAYOUTGET call to the MDS.

An alternative that might be worth exploring is to have the LAYOUTGET
return a stateid representing the credential to use, and then add a
separate LAYOUTAUTH call to convert the stateid into something that could
be used to set up the RPCSEC_GSS session to the DS.
The reason why that might be interesting is that it could allow the client
to reuse an existing RPCSEC_GSS session if one is already available.
It might also allow the client to share information such as supported
encryption types, etc as extra arguments to the LAYOUTAUTH call.