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

[Olga Kornievskaia <[e-mail]>]

For the client to authenticate to the server, it needs a service
ticket. A ticket carries a secret key encrypted with something known
only to the server. A client proves he knows the key inside the ticket
by encrypting a payload with that key (and presents the ticket as
well). KDC (MDS) encrypts that secret with something known only to KDC
and the client.

RPCSEC_GSS session handle is a number (allows to locate the real
crypto to use to decrypt the payload). It has no crypto, there is no
security there.

On Tue, Aug 8, 2017 at 2:54 PM, Trond Myklebust <[e-mail]> wrote:
> Why pass Kerberos tickets around? Is there any reason not to just pass an
> initialised RPCSEC_GSS session handle?
>
> Cheers
>   Trond
>
> On 8 August 2017 at 11:56, Olga Kornievskaia <[e-mail]> wrote:
>>
>> Hi Tom,
>>
>> Are you planning to expand the 4.1.1? The same comment that I wrote on
>> my last email applies here where I suggested to specify 4things. It's
>> needed to have interoperable implementations. As something can choose
>> to return back TGTs (something like and AS_REP) and some might return
>> server tickets (something like a TGS-REP). Some server implementation
>> might encrypt needed info under the session key from the secured
>> communication, some might encrypt it with the user's main key. How
>> would the client know what to expect?
>>
>> Also when I wrote about opaque_auth being 400bytes I was talking about
>> including just a single credential reply back. I'm looking on the
>> network trace and my AS_REP is 801bytes and TGS_REP is 960bytes. And
>> if somebody plans to include any authorization data in their tickets,
>> well that will blow up even more.
>>
>> On Mon, Aug 7, 2017 at 8:25 PM, Thomas Haynes <[e-mail]>
>> wrote:
>> > So here is a first hack at Flex Files v2. I thought it would come in
>> > much
>> > smaller than 11 pages,
>> > so perhaps some pruning will be necessary.
>> >
>> > I’m aware Ben had some comments on:
>> >
>> >    Can I suggest putting in a typed opaque auth blob instead of explicit
>> >    synthetic uid/gid fields?
>> >
>> > I have purposely done:
>> >
>> >    /// struct ffv2_data_server4 {
>> >    ///     deviceid4               ffds_deviceid;
>> >    ///     uint32_t                ffds_efficiency;
>> >    ///     stateid4                ffds_stateid<>;
>> >    ///     nfs_fh4                 ffds_fh_vers<>;
>> >    ///     fattr4_owner            ffds_user;
>> >    ///     fattr4_owner_group      ffds_group;
>> >    ///     opaque_auth             ffds_auth;
>> >    /// };
>> >
>> > Because of AI1:
>> >
>> >    [[AI1: after the lesson learned from ffds_stateid, we either need to
>> > put
>> > an
>> >    array here or define all of the file handles to share the same
>> >    credentials.  And as Olga points out in her email, this gets big
>> >    fast.  Especially if we throw in many mirrored copies!  --TH]]
>> >
>> > I.e., the ffds_auth is inside an array of ffv2_data_server4 which is
>> > in itself inside an array of ffv2_mirror4 AND it could be argued that
>> > ffds_auth (and ffds_user/ffds_group) need to be an array.
>> >
>> > Even if we decide to make all FHs share the same credentials, we
>> > eventually can hit a limit of the number of mirrored copies.
>> >
>> > And Ben, the other reason not to use a typed opaque auth blob
>> > is because the  ffds_user and ffds_group are strings, and do
>> > not fit into AUTH_UNIX. We could define AUTH_SYNTHETIC. :-)
>> >
>> > Begin forwarded message:
>> >
>> > From: <[e-mail]>
>> > Subject: New Version Notification for
>> > draft-haynes-nfsv4-flex-filesv2-00.txt
>> > Date: August 7, 2017 at 5:11:45 PM PDT
>> > To: Thomas Haynes <[e-mail]>
>> >
>> >
>> > A new version of I-D, draft-haynes-nfsv4-flex-filesv2-00.txt
>> > has been successfully submitted by Thomas Haynes and posted to the
>> > IETF repository.
>> >
>> > Name: draft-haynes-nfsv4-flex-filesv2
>> > Revision: 00
>> > Title: Parallel NFS (pNFS) Flexible File Layout v2
>> > Document date: 2017-08-07
>> > Group: Individual Submission
>> > Pages: 11
>> > URL:
>> >
>> > https://www.ietf.org/internet-drafts/draft-haynes-nfsv4-flex-filesv2-00.txt
>> > Status:
>> > https://datatracker.ietf.org/doc/draft-haynes-nfsv4-flex-filesv2/
>> > Htmlized:
>> > https://tools.ietf.org/html/draft-haynes-nfsv4-flex-filesv2-00
>> > Htmlized:
>> > https://datatracker.ietf.org/doc/html/draft-haynes-nfsv4-flex-filesv2-00
>> >
>> >
>> > Abstract:
>> >   The Parallel Network File System (pNFS) allows a separation between
>> >   the metadata (onto a metadata server) and data (onto a storage
>> >   device) for a file.  The flexible file layout type is an extension to
>> >   pNFS which allows the use of storage devices in a fashion such that
>> >   they require only a quite limited degree of interaction with the
>> >   metadata server, using already existing protocols.  This document
>> >   describes two extensions to the flexible file layout type to allow
>> >   for multiple stateids for tightly coupled NFSv4 models and an
>> >   additional security mechanism for loosely coupled models.
>> >
>> >
>> >
>> >
>> > Please note that it may take a couple of minutes from the time of
>> > submission
>> > until the htmlized version and diff are available at tools.ietf.org.
>> >
>> > The IETF Secretariat
>> >
>> >
>> >
>> > _______________________________________________
>> > nfsv4 mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/nfsv4
>> >
>>
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nfsv4
>
>