Subject: RE: [nfsv4] allowed delayed writes via AUTH_GSS

From: Mike Eisler <[email-masked]>
Date: Wed, 01 Oct 2003 16:19:00 -0700

> From: [email-masked]

 > Just suppose the following:
 > 1 - Client does a SetClientID with AUTH_GSS, where the principal is
 > 	nfs/[email-masked] and gets clientid0
 > 2 - Client Opens file "X" for writing, using clientid0 and
 > AUTH_GSS, where
 > 	the principal is <user>@KERBEROS.REALM successfully
 > 	getting stateid0
 > 3 - Client Writes to file "X" using stateid0 and AUTH_GSS, where the
 > 	principal is nfs/[email-masked]
[...]
 > It seems to me it just comes down to how trustworthy the
 > client's keytab
 > file is vs how trustworthy the user passwords and stashed tgt is?

Yes that is the case.

When all we had was AUTH_SYS, ignioring IP
address spoofing, its security came down to
how trustworthy the client was. When we added RPCSEC_GSS
to NFSv[23], the security still came down to how trustworthy the
client was, but there was a way for clients to destroy their
credentials. And eventually, the Kerberos credentials expired.

Your proposal is somewhere between the two extremes, but I'd
put it closer to AUTH_SYS than pure user-to-server security.
In my opinion of course.

There's no need to complicate
the NFSv4[.next] though. Instead, create a new pseudo-mechanism
which is layered over a real mechanism. The real
mechanism uses crypto (for example it might be the existing
Kerberos V5) to authenticate a per-client
machine principal to the target and produces a single context
per client-machine/server pair. The pseudo mechanism implements
GSS_GetMIC, GSS_Wrap,  (which RPCSEC_GSS used for
authentication, integrity, and privacy) via calls to GSS_GetMIC
and GSS_Wrap on the aforementioned machine/server context.

Fewer contexts, easy to use, easy to implement, and you can do it
with NFSv[234] ... NFSv4.1 not needed. Oh and less secure, but
at least the client and server have to agree, and it is a decision
that is obvious to the customer.

Anyone who wants to submit an i-d for this could cut and paste from
the CCM i-d.

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

---

From: Mike Eisler <[email-masked]>
Date: Thu, 02 Oct 2003 10:14:39 -0700

> -----Original Message-----
 > From: Carl Burnett [mailto:[email-masked]]
 > Sent: Thursday, October 02, 2003 5:18 AM
 > To: [email-masked]
 > Subject: Re: [nfsv4] allowed delayed writes via AUTH_GSS
 >
 >
 > Why wouldn't the client be able to use its host
 > authentication (used in
 > SETCLIENTID) when doing DELEGRETURN? That seems like exactly what you
 > would want to do.
[...]

 > To me, this looks fundamentally flawed that primarily state oriented
 > operations are so closely tied to user authentication when in
 > fact state
 > is a client to server. This is especially true for
 > delegations. Client IDs
 > own delegations, not users.

What you see as flawed, others might see as good security.

If one wants to compromise security for convenience, one has the
freedom to add an ACE to his files giving the SETCLIENTID
principal authority to write and read data. With that
authority, the client can then acquire, flush, and
return delegations via the machine cred. ACE inheritence from directories
deals with any of the ease of use issues this entails. The prescence
of the machine cred in the ACL informs the client to use this
capability.

Or simply concede that the pure
machine cred model is adequate for one's purposes and
implement/deploy my suggested GSS pseudo-mechanism.

---

From: Carl Burnett <[email-masked]>
Date: Thu, 2 Oct 2003 13:26:27 -0500

I think this does represent a fairly serious problem with the protocol. 
You have situations where a client cannot return resources to a server. In 
the previously discussed cases of CLOSE and LOCKU, this potentially leads 
to the inability to access files because the client can't release state 
and there is no way short of manual intervention for the server to recover 
the resource. I am not referring the extreme cases where someone leaves an 
app running with opens and locks. Its the more typical cases where an 
application terminates, perhaps due to an EACCES upon loss of 
authentication, the client can't do its job. At least for the DELEGRETURN 
case the server can recall the delegation.

From a security perspective, I think you have to view it with a separation 
of the security around the file system resources that are being protected 
and the security around the client host to server host state management. 
The security of the file system resources is based on the real user 
accessing the files and enforcement of the access controls on them. That's 
different from the security of the client to server shared state. With 
SETCLIENTID, the protocol has already established that state control is in 
fact based on the security of SETCLIENTID. The problem is that the 
protocol operations for more granular state control have been coupled to 
file system export controls because of the use of the PUTFH operation.

As as been discussed, environments desiring stronger security beyond the 
protection of the data would probably want to leverage the use of 
RPCSEC-GSS on SETCLIENTID by creating a machine principal for the client. 
But history says many environments will not do this to reduce 
administration on the client side. They still get the strong security on 
the data, which is the key thing.

I am hoping for some good discussion on this topic at the upcoming 
bakeoff.

Thanks,
Carl

Carl Burnett
AIX Kernel Architecture - Network File System
(512) 838-8498, TL 678-8498
(please reply to [email-masked])

Mike Eisler <[email-masked]>
Sent by: [email-masked]
10/02/2003 12:14 PM

        To:     [email-masked]
        cc: 
        Subject:        RE: [nfsv4] allowed delayed writes via AUTH_GSS

[...]

---

From: Carl Burnett <[email-masked]>
Date: Thu, 2 Oct 2003 13:32:41 -0500

In my earlier post, I was assuming the client already had successfully 
pushed dirty data back to the server using the user's authentication, 
which is what you really have to do.

But the client at some point will return the delegation if it has not 
already been revoked. For example if its recycling a vnode. That's really 
the case I was thinking about.

Carl

Carl Burnett

Nicolas Williams <[email-masked]>
10/02/2003 12:46 PM

        To:     Carl Burnett/Austin/IBM@IBMUS
        cc:     [email-masked]
        Subject:        Re: [nfsv4] allowed delayed writes via AUTH_GSS

On Thu, Oct 02, 2003 at 07:17:59AM -0500, Carl Burnett wrote:
> Why wouldn't the client be able to use its host authentication (used in 

Because that would also require that the client host have permission to
WRITE dirty buffers.  That's too much permission to grant implicitly to
client host principals, methinks.

Fortunately, delegation revocation is per-open file, not per-clientid.

So:

 - user goes away

 - clients keeps RENEWing using its hostbased principal creds

 - server recalls delegations

 - client can't flush dirty buffers or return the delegations

 - server revokes those delegations

 - user comes back, refreshes his/her creds, but finds that his/her app
   that had dirty state lost that state and got sent some signal that
   killed it (say, SIGLOST).

I think this is fine.

Though I think we could consider an operation that allows the user to
explicitly delegate to the client host permission to do DELEGRETURN and
WRITE on his behalf for his open files.

> would want to do. Of course one barrier I see is that it takes a 
> filehandle via PUTFH, and PUTFH will be checking the authentication 
> against the allowed security flavors for the exported data. This is 
> unfortunate since a client would like to be able to hang on to and 
manage 
> its granted delegation across many opens for potentially many users. The 

> client should not have to carefully watch all the authentication 
contexts 
> for the accessing users in order to know that it must do a DELEGRETURN 
> when the last related context is about to expire or be destroyed. And 
then 
> what if an admin actually removes the principal from the KDC or some 
async 
> event happens that makes the last applicable user context at the client 
> unusable. Now you have a client holding a delegation that it can 
> successfully return.

What if the network goes away permanently?  That's pretty much the
effect of having the credentials of all involved go away permanently.

There's always going to be failure modes we can't easily recover from.
Even with plain AUTH_NONE and AUTH_SYS!  :)

Oh well.

> operations are so closely tied to user authentication when in fact state 

> is a client to server. This is especially true for delegations. Client 
IDs 
> own delegations, not users.

The more I think about it, the happier I am that delegations are
per-principal, rather than per-clientid.  That's because returning a
write delegation means writing dirty buffers and that's too much
permission to be implicitly granting to client host principals.

Cheers,

Nico
--