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

From: Mike Eisler <[email-masked]>
Date: Tue, 14 Dec 2004 09:57:27 -0800

> From: [email-masked]
 > [mailto:[email-masked]]
 > Sent: Monday, December 13, 2004 2:45 PM
 > To: [email-masked]
 > Subject: [nfsv4] more re: NFS4ERR_CLID_INUSE
 >
 >
 > Suppose a different client (spoofing the same client id name)
 > is allowed
 > to do a SetClientID with AUTH_SYS and uid==0 before the lease expires.
 >
 > Couldn't that result in a "denial of service" as well? For example:
 > - Client A has a current ClientID that it is Renew'ing, but no files
 >   currently Open
 > - nasty Client B does a SetClientID using Client A's client id name,
 >   AUTH_SYS and uid==0
 >   - if this is allowed, the server would issue a new ClientID to nasty
 >     Client B
 > now, Client A is going to get NFS4ERR_EXPIRED (at least that seems to
 > be the most appropriate error)
 >
 > Mike mentioned something like "nasty Client B will spoof Client A's IP
 > address", but I see nothing in the RFC that says a Client must always
 > use the same IP address. Further, I believe a Client should be able to

Sure, but a server accepting AUTH_SYS SETCLIENTIDs might want
to use source IP addresses as a sanity check. AUTH_SYS, if it is used
at all, should b

 > change IP address (I'm not referring to Callback address here, nasty
 > Client B could spoof that, since it doesn't care if callbacks work).
 >
 > To me, it seems that the ClientID itself is state that can't be tossed
 > until it expires.

There's nothing in the RFC that says two legitimate client's
can't each come up with the same client id; the long hand id is
opaque. Client implementations have to be prepared
for conflicts in the name. I'll grant you
that a server may keep the client id until it expires, but
it is just as valid to keep it until it has no state associated
with it. It comes down to which ease of use scenario bothers
the server implementor more.

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 14 Dec 2004 13:26:56 -0500

On Tue, Dec 14, 2004 at 09:57:27AM -0800, Mike Eisler wrote:
> I'll grant you that a server may keep the client id until it expires,
> but it is just as valid to keep it until it has no state associated
> with it. It comes down to which ease of use scenario bothers the
> server implementor more.

Doesn't the rfc mandate the latter option?  From 8.1.2:

   "However, client bugs, server bugs, or perhaps a deliberate change of
   the principal owner of the id string (such as the case of a client
   that changes security flavors, and under the new flavor, there is no
   mapping to the previous owner) will in rare cases result in
   NFS4ERR_CLID_INUSE.

   "In that event, when the server gets a SETCLIENTID for a client id
   that currently has no state, or it has state, but the lease has
   expired, rather than returning NFS4ERR_CLID_INUSE, the server MUST
   allow the SETCLIENTID, and confirm the new clientid if followed by
   the appropriate SETCLIENTID_CONFIRM."

--b.

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 14 Dec 2004 13:41:59 -0500

> the server implementor more.

Such a requirement is very difficult to reconcile with the RFCs other
requirement that the client must reuse the same clientid across reboots,
(it also, BTW, advises client implementors not to rely on being able to
record clientids in a local file).

The fact is that NFSv4 does not in practice allow clients to dynamically
select their client id strings, and so you should not allow untrusted
clients to call SETCLIENTID.

Cheers,
  Trond

-- 
Trond Myklebust <[email-masked]>

---

From: Mike Eisler <[email-masked]>
Date: Tue, 14 Dec 2004 10:46:28 -0800

Cool. So Rick has his answer.

---

From: Mike Eisler <[email-masked]>
Date: Tue, 14 Dec 2004 11:09:58 -0800

> record clientids in a local file).

I don't think the RFC lists requirements for
the client's clientid, but it is a big document, and
I might have missed it. It does state a set of considerations,
among which are what you listed it above.

> select their client id strings, and so you should not allow untrusted

I disagree. It does allow it, because when a client does select
a different long hand client id, to the NFSv4 server it is a different
client. One reason static clientids are recommended is to deal
the situation of a a client rebooting and an application immediately
repeating what it was doing before: opening and locking a file.
We don't want the app to block waiting for the lease of the
previous incarnation of the client to expire.

> clients to call SETCLIENTID.

Which means that you are advocating that NFSv4 only be used
with real authentication or with AUTH_SYS to a trusted set of
hosts. I'm all for the former. The latter makes little sense to
me once the trusted set reaches a sufficiently large number.

And I can make the same assertion about NFSv3/NLM/NSM while I'm
at it. Except that I know of no NLM/NSM client or server that
uses real authentication. So singling out version 4 of NFS as being secure
in limited scenarios is not accurate.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 14 Dec 2004 14:14:47 -0500

> Cool. So Rick has his answer.

Yup.  So the linux server, for one, is wrong--we return CLID_INUSE in
this case until the lease expires, even if there's no associated state.

This still worries me, though.  It means that you can't give a client
the right to do setclientid without also giving them a very effective
way to cut off any other client--just wait for a moment when they aren't
holding any state, and then grab their client id name.

--b.

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 14 Dec 2004 14:32:49 -0500

> previous incarnation of the client to expire.

Then you have to be able to guarantee that you select unique strings,
since by the same argument, when a client does select the same long hand
client id, it IS treated as being the same client, and it will cancel
any state associated with that clientid (provided that the verifier
differs).
If you are being forced to change your clientid dynamically, then
clearly such a guarantee is missing...

> me once the trusted set reaches a sufficiently large number.

Well... AUTH_SYS is fine if your security is guaranteed by other means
(no exterior IP connection, no physical access by unauthorized
personnel, ...).

Things like allowing stateful access to world + dog (even if it is
"only" a read-only partition), however, is a no-no...

Cheers,
  Trond

---

From: Mike Eisler <[email-masked]>
Date: Tue, 14 Dec 2004 11:54:18 -0800

> Then you have to be able to guarantee that you select unique strings,

No guarantees, just trial and error. We deliberately chose to
not have a registry for long hand client identifiers, since
we didn't want to see them auctioned on eEbay. :-)

> any state associated with that clientid (provided that the verifier

Cancellation is permitted provided there's no unexpired
state or if there is state, the principal and security
flavor match.

> "only" a read-only partition), however, is a no-no...

Not sure what 'dog' refers to; I'm a cat lover myself.
Regardless, I guess I'd better turn off my http server then. :-)