Re: [nfsv4] Soliciting next steps for RPCSEC_GSSv3

[Andy Adamson <[e-mail]>]

On Wed, Sep 4, 2013 at 5:24 PM, Nico Williams <[e-mail]> wrote:
> On Wed, Sep 4, 2013 at 4:05 PM, Andy Adamson <[e-mail]> wrote:
>> Just out of curiosity, I'm still not clear on why the combination of a
>> compound authenticated identity and the server privilege payloads
>> described in draft-ietf-nfsv4-minorversion2-19 both in a
>> RPCSEC_GSS3_CREATE call don't convey the necessary authorization.
>
> The compound authentication feature requires that one party (the user)
> place full trust on another (the client host).  In the
> server-to-server case you'd not have the destination trust the client,
> so it'd have to be the other way: trust the destination to act on
> behalf of the client.

Hmm.

The copy_from_auth sets a privilege up on the source server from the
client including a shared secret. The copy_to_auth sets a privilege up
on the destination server from the client with the same shared secret.
The copy_confirm_auth is sent from the destination server to the
source server with the same shared secret. The READ is performed under
the GSS3 context established by the copy_confirm_auth privilege.
Doesn't the shared secret allow the client to trust the destination
server to act on behalf of the client?

> Using a structured privilege marked as critical
> would work to constrain the compound context, but you'd be
> establishing an RPCSEC_GSS context per-copy.

Yes, draft-ietf-nfsv4-minorversion2-19 requires a RPCSEC_GSS3 context per copy.

> Ah, that's what I was
> missing: the structured privilege.
>
> OK, so that would work, but I'm not sure it's worth the overhead.

Well, the non-rpcsec_gssv3 proposals have similar overhead - stuff
being sent per COPY.

> Also, if we're going to have structured privileges then we should work
> that into RPCSEC_GSSv3.

Where can I find the definition of "structured privilege"? A quick
google search just turns up a SAP HANA reference ;)

-->Andy