Subject: Re: [nfsv4] Soliciting next steps for RPCSEC_GSSv3

From: Nico Williams <[email-masked]>
Date: Tue, 3 Sep 2013 15:32:08 -0500

On Fri, Aug 23, 2013 at 8:16 PM, Nico Williams <[email-masked]> wrote:
> On Fri, Aug 23, 2013 at 7:17 PM, Andy Adamson <[email-masked]> wrote:
>> On Fri, Aug 23, 2013 at 7:01 PM, Nico Williams <[email-masked]> wrote:
>>> And because RPCSEC_GSSv3 is about describing the
>>> *subject*, not some third party, it's really not relevant.
>>
>> Well, the RPCSEC_GSSv3 compound authentication is all about
>> identifying  some third party (the inner context handle). That
>> combined with a privilege seems to me to do what NFSv4.2 SSC requires.
>
> Oh.  I hadn't understood that you wanted to combine a user and a
> server initiator credential.  The goal for me had been to combine a
> client host and a client user credential.  I guess this alternative
> can work too, but... the server that will be acting as a client needs
> to be in possession of the security context, OR that server has to
> round-trip all its messages to the other server via the real client.
> Seems tricky.  I'll think about it.

The compound authentication feature is designed for a three-party
protocol where one of the parties is a proxy for another ("proxied"),
*fully* trusted by the proxied party.  The client node is the proxy,
the user is the proxied party, and the fileserver is the fileserver.
The user has no choice but to fully trust the client node or not at
all.

In the server-to-server copy scenario there is no entity that either
of the other two are willing to fully trust.  Therefore the design of
RPCSEC_GSSv3's compound authentication feature is not appropriate.
There might be cases where a client would be willing to fully trust
one of the servers, but that won't be the case generally.

I believe a simpler and better design would be for the client to tell
the source server that the destination is allowed to read from the
given FH for a certain amount of time.  If the destination needs more
time, then the client should add time, else if the destination
finishes too soon then the client can forget the temporary
authorization (it will eventually expire) or perhaps it could revoke
it,

Nico
--

---

From: "Noveck, David" <[email-masked]>
Date: Tue, 3 Sep 2013 19:44:53 -0400

If I understand what Nico is saying, RPCSEC_GSSv3 has two problems as a solution to the inter-server copy security problem:

	o It isn't complete
	o If it were, it still wouldn't solve the security problem.

If I've summarized the matter correctly, let's not try to extend RPCSECGSSv3 to do what it can't do..

Andy how does the part of RPCSEC_GSSV3 intended to support labeled NFS look?  Does it look like that can be wrapped up in a reasonable time (for your own definition of "reasonable")?

How about the approach in draft-ietf-nfsv4-minorversion2-20 (based on Mike Eisler's idea)?   Unless somebody finds a flaw, we should go with that in v4.2.

On the other hand,  if Nico  can write up his time-based idea in the form of diffs to draft-ietf-nfsv4-minorversion2-20, the group would have two approaches to choose from.

So maybe we'll be able to close on this issue soon.

The other problem with inter-server copy is the issue with the  destination server using a stateid that the client got from the source server.  Trond had a proposal to deal with that, but there is no proposed spec text to go with it.  I'm pretty sure Tom had another approach but he hasn't written that up either.  I also have a proposal to deal with the issue but I'm busy also and won't have spec text for the proposal for about a week.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nico Williams
Sent: Tuesday, September 03, 2013 4:32 PM
To: Andy Adamson
Cc: J. Bruce Fields; NFSv4
Subject: Re: [nfsv4] Soliciting next steps for RPCSEC_GSSv3

On Fri, Aug 23, 2013 at 8:16 PM, Nico Williams <[email-masked]> wrote:
>>> And because RPCSEC_GSSv3 is about describing the *subject*, not some 
>>> third party, it's really not relevant.
>>

The compound authentication feature is designed for a three-party protocol where one of the parties is a proxy for another ("proxied"),
*fully* trusted by the proxied party.  The client node is the proxy, the user is the proxied party, and the fileserver is the fileserver.
The user has no choice but to fully trust the client node or not at all.

In the server-to-server copy scenario there is no entity that either of the other two are willing to fully trust.  Therefore the design of RPCSEC_GSSv3's compound authentication feature is not appropriate.
There might be cases where a client would be willing to fully trust one of the servers, but that won't be the case generally.

I believe a simpler and better design would be for the client to tell the source server that the destination is allowed to read from the given FH for a certain amount of time.  If the destination needs more time, then the client should add time, else if the destination finishes too soon then the client can forget the temporary authorization (it will eventually expire) or perhaps it could revoke it,

Nico
--
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Nico Williams <[email-masked]>
Date: Tue, 3 Sep 2013 20:54:05 -0500

>         o If it were, it still wouldn't solve the security problem.

v3 gets you a compound *authenticated identity*, not a constrained or
delegated *authorization*.  The read operations in server-to-server
copy represent an authorization problem.  Of course, RPCSEC_GSSv3 is
intended to convey some authorization-relevant information, but
compound authentication alone isn't a solution.

> If I've summarized the matter correctly, let's not try to extend RPCSECGSSv3 to do what it can't do..

An authentication mechanism that allows you to convey authorization
data might help, but since RPCSEC is below the application layer it's
a bit difficult to get very operation-specific authorization data in
and out of it.  Whereas the other authorization data it *is* designed
to convey is about the subject *process*, not specific operations, and
is known before any application operations even start, therefore it's
easy to just send all of it, and in an application-generic way too.

> On the other hand,  if Nico  can write up his time-based idea in the form of diffs to draft-ietf-nfsv4-minorversion2-20, the group would have two approaches to choose from.

Another alternative is to have an OP telling a server what client to
callback for delegated authorization.  Or something like that.  But I
think the "hey, server B can read this FH for the next 10 minutes"
works best (note too that there's no time synchronization problem here
-- relative time is good enough).

> The other problem with inter-server copy is the issue with the  destination server using a stateid that the client got from the source server.  Trond had a proposal to deal with that, but there is…

Well, so just as the client should tell the source that the
destination principal needs to read for a while, so must the
destination know the stateid.

That's another thing: either the client needs to know the destinations
GSS initiator principal name or we must use some secret cookie (which
then implies confidentiality protection).  Pick your poison.

One more thing: how does the client know when the copy is complete?
When it does, it should make sure to revoke the destination's
authorization to read the source.  There's a bit of a race there.
Ideally the destination could revoke its authorization, tell the
client (including some source-provided proof) and then let the client
verify that self-revocation at the source.  If the source restarts the
client will have to re-authorize the destination, most likely.  If the
destination crashes the client may not know if the copy completed
(file length is not enough: there may be holes); a "hash byte range of
FH" operation might help.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 3 Sep 2013 21:02:08 -0500

> FH" operation might help.

Maybe the right answer is that the client doesn't care.  But then, a
"hash byte range" operation could be oh so handy.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 4 Sep 2013 11:50:48 -0400

> FH" operation might help.

I was assuming COPY behaved like write, but looking back at the draft it
doesn't have stable_how or verifier fields.  So I guess it's implicit
that the operation is reflected in stable storage before it's reported
to the client as done.

Should we instead add the stable_how and verifier fields?

--b.

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 4 Sep 2013 16:20:06 +0000

>> One more thing: how does the client know when the copy is complete?

CB_OFFLOAD

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 4 Sep 2013 16:23:44 +0000

Will the duration of the copy interrupt the time-based authorization for the copy?
Seems as though a long running copy (very likely) would need to account for re-authorization.

Spencer

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Haynes, Tom
> Sent: Wednesday, September 4, 2013 9:20 AM
> To: Nico Williams
> Cc: J. Bruce Fields; Andy Adamson; NFSv4
> >> verify that self-revocation at the source.  If the source restarts
> >> the client will have to re-authorize the destination, most likely.
> >> If the destination crashes the client may not know if the copy
> >> completed (file length is not enough: there may be holes); a "hash
> >> byte range of FH" operation might help.
> >

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Sep 2013 11:54:41 -0500

> Seems as though a long running copy (very likely) would need to account for re-authorization.

We want the destination server to read all of some byte ranges from
some FH on the source server.  We must either:

 - allow the destination to read many times, until the authz is
revoked (what if the client forgets to revoke it?)
 - allow the destination to read at most once (must keep state on the
source server; what if it loses state?)
 - allow the destination to read many times over some time period
(requires re-authz if that time is too short; requires revocation if
that time is too long; requires state on the source server, but could
get encoded as an encrypted state cookie stored by the destination)

Are there other options?

I like the time-based approach because the client need not remember to
revoke the authz (e.g., if the client restarts).

We really need a "hash byte range(s) of FH" operation to be able to
efficiently detect copy completion.  (Note that destination servers
can compute the hash as they go, so that computing the hash need not
require additional disk I/O on the destination.  The source too could
optimize this way, but at the cost of keeping some ephemeral state.)

Nico
--

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 4 Sep 2013 17:12:34 +0000

I think those are the options.  Good summary.

> From: Nico Williams [mailto:[email-masked]]
> Sent: Wednesday, September 4, 2013 9:55 AM
> To: Spencer Shepler
> Cc: Haynes, Tom; J. Bruce Fields; Andy Adamson; NFSv4
> We want the destination server to read all of some byte ranges from some
> FH on the source server.  We must either:
> 
>  - allow the destination to read many times, until the authz is revoked (what
> if the client forgets to revoke it?)
>  - allow the destination to read at most once (must keep state on the source
> server; what if it loses state?)
>  - allow the destination to read many times over some time period (requires
> re-authz if that time is too short; requires revocation if that time is too long;
> requires state on the source server, but could get encoded as an encrypted
> state cookie stored by the destination)
> 
> Are there other options?
> 
> efficiently detect copy completion.  (Note that destination servers can
> compute the hash as they go, so that computing the hash need not require
> additional disk I/O on the destination.  The source too could optimize this
> way, but at the cost of keeping some ephemeral state.)
> 
> Nico
> --

---

From: "Noveck, David" <[email-masked]>
Date: Wed, 4 Sep 2013 13:16:26 -0400

> Are there other options?

How about what is in draft-ieff-nfsv4-minorversion2-20?

If you think that won't work, tell us why?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nico Williams
Sent: Wednesday, September 04, 2013 12:55 PM
To: Spencer Shepler
Cc: J. Bruce Fields; Andy Adamson; Haynes, Tom; NFSv4
Subject: Re: [nfsv4] Soliciting next steps for RPCSEC_GSSv3

> Seems as though a long running copy (very likely) would need to account for re-authorization.

We want the destination server to read all of some byte ranges from some FH on the source server.  We must either:

 - allow the destination to read many times, until the authz is revoked (what if the client forgets to revoke it?)
 - allow the destination to read at most once (must keep state on the source server; what if it loses state?)
 - allow the destination to read many times over some time period (requires re-authz if that time is too short; requires revocation if that time is too long; requires state on the source server, but could get encoded as an encrypted state cookie stored by the destination)

Are there other options?

I like the time-based approach because the client need not remember to revoke the authz (e.g., if the client restarts).

We really need a "hash byte range(s) of FH" operation to be able to efficiently detect copy completion.  (Note that destination servers can compute the hash as they go, so that computing the hash need not require additional disk I/O on the destination.  The source too could optimize this way, but at the cost of keeping some ephemeral state.)

Nico

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Sep 2013 13:10:29 -0500

[Resend; forgot to cc the list.]

> If you think that won't work, tell us why?

That's fine.  There's no expiration on the COPY_NOTIFY authorization.
I'm not sure if "source server lost the copy authorization" errors can
be conveyed in CB_OFFLOAD or OFFLOAD_STATUS, so that might be a
problem.

I'd suggest three enhancements to the protocol in
draft-ietf-nfsv4-minorversion2-20:

 - add an OPTIONAL relative expiration time argument to COPY_NOTIFY
(to help protect zealous clients against loss of client-side state)

 - make sure that it's clear how the destination indicates failure due
to EACCES from the source (so the client can repeat the COPY_NOTIFY)
-- the source server MUST be allowed to forget about COPY_NOTIFYs, no?

 - add a "hash byte range(s)" op by which the client can verify copies
in a way that survives loss of state on both servers.  If the sequence
and size of I/Os done by the destination can be characterized then the
client could even bisect to find what I/Os are missing if the
destination restarts and loses the copy operation state, then complete
the copy more optimally than by just restarting it.

Nico
--

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 4 Sep 2013 14:37:22 -0400

> (to help protect zealous clients against loss of client-side state)

Note there's already a lease_time argument whose only difference from
this is that it limits the time till the server *starts* the copy.  So I
guess you could also just redefine that argument.

> -- the source server MUST be allowed to forget about COPY_NOTIFYs, no?

Yeah I don't see any explanation of this case.  But I may have
overlooked something.

> the copy more optimally than by just restarting it.

The client can always just restart the copy from scratch.

The hash-byte-range-op might provide a faster option, but how much
faster seems likely to depend on a lot of details of the hardware and
implementation.  And specifying it seems complicated.

And it's just a new op so should be easy to add in the future.

So, we should drop hash-byte-range until people have tried the simpler
thing and failed at it, at which point they'll probably be motivated to
get the new thing right.

--b.

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Sep 2013 14:44:15 -0500

> thing and failed at it, at which point they'll probably be motivated to

It's an optimization, *just like server-to-server copy offload*.  The
hash thing optimizes destination restarts.  That's not a very likely
event, so it makes sense to say that it's not worth the bother.  But
it'd be quite useful in general.

Nico
--

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 4 Sep 2013 16:31:46 -0400

> it'd be quite useful in general.

Agreed, it sounds interesting.  Write it up and I'll look forward to
reading about it.

--b.

---

From: Andy Adamson <[email-masked]>
Date: Wed, 4 Sep 2013 17:05:23 -0400

> compound authentication alone isn't a solution.

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.

BTW I'm perfectly fine with a v4.2 only solution.

-->Andy

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Sep 2013 16:24:35 -0500

> 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.  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.  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.
Also, if we're going to have structured privileges then we should work
that into RPCSEC_GSSv3.

---

From: Andy Adamson <[email-masked]>
Date: Wed, 4 Sep 2013 17:55:49 -0400

On Wed, Sep 4, 2013 at 5:24 PM, Nico Williams <[email-masked]> wrote:
> 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
> 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

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

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

-->Andy

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Sep 2013 17:48:41 -0500

> client including a shared secret. The copy_to_auth sets a privilege up

And now you must be using confidentiality protection.

> server to act on behalf of the client?

Yes, and if the priv is marked critical, which you got right.

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

OK.

> Well, the non-rpcsec_gssv3 proposals have similar overhead - stuff

It's probably comparable, yeah.

> google search just turns up a SAP HANA reference ;)

What I had in mind for privs was what Linux calls "capabilities", what
Solaris calls "privileges" -- mere strings.  You need privs with
structure, which is why you had a struct copy_to_auth_priv -- that's
what I meant: structs, not strings.

Nico
--

---

From: Andy Adamson <[email-masked]>
Date: Wed, 4 Sep 2013 18:55:16 -0400

> what I meant: structs, not strings.

So - AFAICS the use of rpcsecgssv3 in
draft-ietf-nfsv4-minorversion2-19 solves the inter-server copy
security problem - yes?

-->Andy

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Sep 2013 18:00:23 -0500

> draft-ietf-nfsv4-minorversion2-19 solves the inter-server copy

Yes.  Sorry I thought otherwise earlier.  We'd have to specifically
indicate that privs can have structure.  We'd have to define all NFSv4
privs as a union, not a struct (or a struct containing a union), as I
don't want to lose the originally intended uses of privs.

---

From: "Haynes, Tom" <[email-masked]>
Date: Thu, 5 Sep 2013 15:33:30 +0000

> The other problem with inter-server copy is the issue with the  destination server using a stateid that the client got from the source server.  Trond had a proposal to deal with that, but there is…

Pretty sure holes were shot into whatever plan I had in the past.

So how about this:

1) We only allow NFSv4.2+ as the copy-engine.

2) We provide a new procedure which is sent from the destination to the source:

 COPY_STATE_REGISTER cfg, source_stateid

which returns a stateid that is valid for the destination.

The source will have given this stateid to the client and the fact that the destination
is presenting it means that it is for the COPY. It does not refer to any new locking state
on the source. I.e., the source knows that it MUST not revoke the state it gave to
the client.

---

From: "Noveck, David" <[email-masked]>
Date: Thu, 5 Sep 2013 12:25:36 -0400

Let me give a rough outline about what I was thinking.   I believe that the most substantial reasons for locking (and thus stateids) have to do with the destination and not the source.  For the source the only thing, that I believe most people  would ever want is to prevent someone else from writing in the file while it is being copied.  The client can do that by simply opening the file with WRITE-deny.  Once he has done that, he can pass a special stateid and let the destination do his own open for read.  The client can do the matching close once he finds out the copy is complete.   

So I would allow the src_stateid to be passed as a special (e.g. all zero) stateid and say that, in that case, the destination does a CLAIM_FH open of the source file to be copied.  

There may be a case in which an application has opened a file for WRITE and DENY-all and still wants it server-side copied.   I think Tom's approach would handle that, but I don't think it's a must-have. 

-----Original Message-----
From: Haynes, Tom [mailto:[email-masked]] 
Sent: Thursday, September 05, 2013 11:34 AM
To: Noveck, David
Cc: Nico Williams; Andy Adamson; J. Bruce Fields; NFSv4
Subject: Re: [nfsv4] Soliciting next steps for RPCSEC_GSSv3

So how about this:

The source will have given this stateid to the client and the fact that the destination is presenting it means that it is for the COPY. It does not refer to any new locking state on the source. I.e., the source knows that it MUST not revoke the state it gave to the client.

---

From: Andy Adamson <[email-masked]>
Date: Tue, 10 Sep 2013 15:16:28 -0400

> Andy how does the part of RPCSEC_GSSV3 intended to support labeled NFS look?  Does it look like that can be wrapped up in a reasonable time (for your own definition of "reasonable")?

I have only done a quick read-through - but it looks to me that the
RPCSEC_GSS_V3 labeled support has a small impedance mismatch with the
NFSv4.2 labeled support.
RPCSEC_GSS_V3 uses a DOI based approach:

      ///  typedef opaque rpc_gss3_doi<>;
      ///  struct rpc_gss3_label {
      ///          rpc_gss3_doi    doi;
      ///          opaque          label<>;
      ///  };

Whereas NFSv4.2 uses an LFS based approach:

  struct labelformat_spec4 {
           policy4 lfs_lfs;
           policy4 lfs_pi;
   };

   struct sec_label4 {
           labelformat_spec4       slai_lfs;
           opaque                  slai_data<>;
   };

But past addressing that, the rpc_gss3_label is just another payload
for the RPCSEC_GSS3_CREATE operation, and a simple one at that. So, I
don't see a lot of work past what is needed for SSC.  I do see some
NFSv4.2 work in more fully describing the use of RPCSEC_GSSv3 labels,
more along the lines of the detailed description of SSC's use of
copy_to_auth, copy_from_auth, and copy_confirm_auth.

BTW: will anyone implement full mode labeling over NFSv4.2 - is there a market?

> The other problem with inter-server copy is the issue with the  destination server using a stateid that the client got from the source server.  Trond had a proposal to deal with that, but there is…

AFAICS the rpcsec_gssv3 combination of compound authentication and
server privileges solves the above mentioned stateid problem. The
copy_to_auth privilege delivers the shared secret to the source server
with the resultant RPCSEC_GSS3 context used for the COPY_NOTIFY. The
copy_from_auth privilege delivers the shared secret to the destination
server, with the resultant RPCSEC_GSS3 context being used for the COPY
operation. The copy_confirm_auth delivers the shared secret from the
destination server (acting as a client) to the source server. The
shared secret ties the stateid sent in the COPY_NOTIFY to the stateid
sent in the COPY, and the RPCSEC_GSS3 handle resulting from a
successful copy_confirm_auth is used to authenticate the READ
operations - the source server knows that the stateid used in said
READ operations came from the client via the COPY_NOTIFY. So the
destination server uses standard SEQUENCE/PUTFH/READ authenticated by
the copy_confirm_auth RPCSEC_GSS3 context which ties the READ to the
COPY_NOTIFY.

-->Andy

---

From: "Noveck, David" <[email-masked]>
Date: Tue, 10 Sep 2013 16:02:06 -0400

> AFAICS the rpcsec_gssv3 combination of compound authentication and server privileges solves the above mentioned stateid problem.

I see that it could, but then someone would have to write the appropriate spec text.

So now it appears that the basic authentication issue and the stateid issue are tied together.  If the advocates of advocates of the three approaches are all going to be present at an WG  meeting in Vancouver (assuming we have one), we could have a useful discussion and come  to an agreement about which way we want to go.

BTW, the current minorversion2 spec, has adopted Mike Eisler's approach to the basic authentication issue, and doesn't address the stateid issue.

-----Original Message-----
From: Andy Adamson [mailto:[email-masked]]
Sent: Tuesday, September 10, 2013 3:16 PM
To: Noveck, David
Cc: Nico Williams; J. Bruce Fields; NFSv4
Subject: Re: [nfsv4] Soliciting next steps for RPCSEC_GSSv3

   struct sec_label4 {

But past addressing that, the rpc_gss3_label is just another payload for the RPCSEC_GSS3_CREATE operation, and a simple one at that. So, I don't see a lot of work past what is needed for SSC.  I do see some
NFSv4.2 work in more fully describing the use of RPCSEC_GSSv3 labels, more along the lines of the detailed description of SSC's use of copy_to_auth, copy_from_auth, and copy_confirm_auth.

> The other problem with inter-server copy is the issue with the  destination server using a stateid that the client got from the source server.  Trond had a proposal to deal with that, but there is…

AFAICS the rpcsec_gssv3 combination of compound authentication and server privileges solves the above mentioned stateid problem. The copy_to_auth privilege delivers the shared secret to the source server with the resultant RPCSEC_GSS3 context used for the COPY_NOTIFY. The copy_from_auth privilege delivers the shared secret to the destination server, with the resultant RPCSEC_GSS3 context being used for the COPY operation. The copy_confirm_auth delivers the shared secret from the destination server (acting as a client) to the source server. The shared secret ties the stateid sent in the COPY_NOTIFY to the stateid sent in the COPY, and the RPCSEC_GSS3 handle resulting from a successful copy_confirm_auth is used to authenticate the READ operations - the source server knows that the stateid used in said READ operations came from the client via the COPY_NOTIFY. So the destination server uses standard SEQUENCE/PUTFH/READ authenticated by the copy_confirm_auth RPCSEC_GSS3 context which ties the READ to the COPY_NOTIFY.

-->Andy

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf
> Of Nico Williams
> On Fri, Aug 23, 2013 at 8:16 PM, Nico Williams <[email-masked]<mailto:[email-masked]>> wrote:
>> On Fri, Aug 23, 2013 at 7:17 PM, Andy Adamson <[email-masked]<mailto:[email-masked]>> wrote:
>>> On Fri, Aug 23, 2013 at 7:01 PM, Nico Williams <[email-masked]<mailto:[email-masked]>> wrote:
>>>> And because RPCSEC_GSSv3 is about describing the *subject*, not
>>>> some third party, it's really not relevant.
>>>
> [email-masked]<mailto:[email-masked]>