Subject: RE: [nfsv4] NFS4ERR_CLID_INUSE when SetClientID changes authenticationmechanisms

From: Mike Eisler <[email-masked]>
Date: Mon, 13 Dec 2004 10:49:24 -0800

> From: [email-masked]
 > [mailto:[email-masked]]

 > A problem has cropped up when a client does a umount/mount of the same
 > file system, switching between AUTH_SYS and RPCSEC_GSS using Krb5. My
 > server sees the SetClientID with a different principal (uid==0 vs
 > [email-masked]) and replies NFS4ERR_CLID_INUSE.
 >
 > At first, I thought this made sense and it was a client side problem,
 > but now I'm thinking that maybe my server should be changed...
 >
 > If the "principal name" is the GSSAPI one, ie:
 > [email-masked] (not root/host.domain@KRB5REALM)
 > then I think it would stay the same when switching between different
 > Mechanisms in RPCSEC_GSS. Is that right?
 >
 > If so, then AUTH_SYS becomes a special case, since it doen't
 > really have
 > a principal name (just uid). I vaguely recall that the reason
 > for returning
 > NFS4ERR_CLID_INUSE was to subvert a denial of service attack
 > via replay.
 > If that is correct, then it doesn't seem that it should matter what
 > happens for AUTH_SYS. (ie. You should only be allowing
 > "trusted" clients
 > to use AUTH_SYS, since they can do lots of other nasty things
 > beyond denial
 > of service.)

The attack is this:
	client A uses RPCSEC_GSS/krb5pi to issue a SETCLIENTID with
		principal root/<client A>@<REALM> which the
		server maps to uid 0.

	client B spoofs A's source network address and issues a
		SETCLIENTID, with the same client id string as
		client A, via AUTH_SYS with uid = 0.

	The uid in both cases is the same. Does the filer allow
		the operation or not? If it does, then all of
		client A's state is blown away. That's denial of
		service. So in general,while I agree with Andy that
		AUTH_SYS is no special case, I don't agree the
		SETCLEINTID should generally be allowed. Though see below.

AUTH_SYS shouldn't be special cased at all. What could reasonably
be special cased is allowing a SETCLIENTID for the same effective
uid, but different security flavor if the client has no state,
other than the short hand client id. Since the NFS client has
unmounted the apparently one mount it had to the NFSv4 server,
presumably all its state has been returned. Thus, a SETCLIENTID
with a different flavor is permitted. If the client doesn't
want to return its state with the final unmount, then it should
keep better track of with principal/security flavor it used
when it issued SETCLIENTID for the first time.

Another point: the client, if is abandoning state on the server,
will eventually lose its state due to lease timeout. A client
id not used for the amount of time equal to the lease timeout
should no longer be considered in use when SETCLIENTID comes
in.

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 13 Dec 2004 14:12:07 -0500

On Mon, Dec 13, 2004 at 10:49:24AM -0800, Mike Eisler wrote:
> Since the NFS client has unmounted the apparently one mount it had to
> the NFSv4 server, presumably all its state has been returned.

The only way for the client to "return" its state at that point is just
to stop sending renews and wait the lease period, right?

> Thus, a SETCLIENTID with a different flavor is permitted.

But only after the lease period.

> should no longer be considered in use when SETCLIENTID comes

Right.  So the complaint is that you do something like

mount -osec=sys myserver:/export /mnt
ls /mnt
umount /mnt
mount -osec=krb5 myserver:/export /mnt

and get an error.  This is the sort of thing developers or people trying
out krb5 for the first time are likely to try.  Eventually they figure
out that they just need to wait a minute or two between unmount and
mount, but that's annoying.

> If the client doesn't want to return its state with the final unmount,
> then it should keep better track of with principal/security flavor it
> used when it issued SETCLIENTID for the first time.

I guess the client could continue renewing its state with auth sys, but
that doesn't seem ideal.

--b.

---

From: Mike Eisler <[email-masked]>
Date: Mon, 13 Dec 2004 11:40:24 -0800

> to stop sending renews and wait the lease period, right?

LOCKU, DELEGRETURN, CLOSE all return state, leaving just the
shorthand client id.

> But only after the lease period.

If theres no lock, open, and delegation state, why wait for
the lease period?

> mount, but that's annoying.

Very annoying. Since the above sequence creates no state other than the
client id (until we get directory delegations)
why should the server annoy the client user?

> I guess the client could continue renewing its state with auth sys, but

It has to RENEW its state with the same creds used with SETCLIENTID.
If the creds expire and aren't renewable, then, it will have to
remove its state. A root/<client name> cred stored in a krb5.keytab file
is infinitely renewable.

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 13 Dec 2004 15:09:06 -0500

> If theres no lock, open, and delegation state, why wait for

You still don't want to allow some third party to change the callback
channel parameters from underneath you.

Cheers,
  Trond

-- 
Trond Myklebust <[email-masked]>

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 13 Dec 2004 14:21:22 -0600

> If theres no lock, open, and delegation state, why wait for

Right. And the server has the right to reclaim that clientid if there
is no other state associated with it.  The client has to deal with it
either way.

Spencer

---

From: Mike Eisler <[email-masked]>
Date: Mon, 13 Dec 2004 12:55:21 -0800

> channel parameters from underneath you.

I was assuming the context of this email thread was SETCLIENTIDs that
establish new short hand client ids, not the ones that re-use
short hand client ids for the purpose of updating callback info.
I based that assumption on the example sequence
	mount -o sec=krb5 / umount / mount - sec=sys

If the context of this thread is that of updating callback info and still
retaining the short hand client, then yes, changing the
security flavor from krb5 to AUTH_SYS is something the server
should reject, possibly with an RPC-level weak authentication
error.