Subject: RE: The RENEW operation and RPC authentication

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 10 Oct 2002 03:22:17 -0700

David Robinson wrote (in part):
> While I am only moderately paranoid, ...

You're too modest. :-)

Your analysis makes sense, but I'd like to consider the 
extension of this scenario in light of automatic lease 
renewal.

If you allow anonymous access for instance, then any
individual could open some file (presumably some files
would be accessible to "nobody" or what's the point),
and then use that stateid to read, renewing the lease
as a side-effect and causing this denial-of-service 
attack.

So I guess that if you are worried this about sort of 
attack, you probably want servers that provide access to
critical files and those that provide anonymous access
to be different servers, at least logically (One server
could have two IP addresses, export two different pseudo-fs's,
etc.  In that case the leases that contain stateids for
anonymous access are separate from those that conation 
stateids to the files you care about.)

-----Original Message-----
From: David Robinson [mailto:[email-masked]]
Sent: Wednesday, October 09, 2002 10:19 PM
To: [email-masked]
Cc: 'Carl Burnett'
Subject: Re: The RENEW operation and RPC authentication

Noveck, Dave wrote:
> One thing that would argue against such a restriction on
> RENEW is that most renewal is implicit.  If you use some
> valid state id associated with the client, then this
> renews the lease, just as renew does, and the security 
> used for that operation might normally be quite different.
> Maybe I don't (probably I don't) understand the security 
> issues that leases might have, not having the appropriate
> level of paranoia to properly analyze those kinds of
> things.

While I am only moderately paranoid, there may be a
denial of service attack.  A core purpose of the stateids is
to have the the client indicate to the server that it has
the same view of the shared state.

A rogue node issuing a RENEW with a stateid that is currently valid and
the real client is functional is a no-op, the real client will
renew anyways.

A rogue node issuing a RENEW with an old stateid will just be
rejected as if it were a stale replay, no harm.

A rogue node issuing a RENEW with a valid stateid but the real
client is dead or unable to communicate, the leases will
continue to be maintained when they would otherwise be
timed out and prevent potential locks being granted to another client.
If the real client can reconnect, it can trigger reboot recovery
causing new stateids invalidating the rogue clients efforts.
However if it were a partition, if the real client maintained
the stateids everything is fine, if however after the client
could not connect within the lease period it discarded the locks
and stateids, the old orphaned locks will still be maintained.
A potential denial of service if it is an exclusive manditory
lock.

It would seem to me that a RENEW should have the same level
of authentication as a SETCLIENTID, both have control
over the shared state.

	-David

---

From: David Robinson <[email-masked]>
Date: Thu, 10 Oct 2002 11:43:18 -0500

> stateids to the files you care about.)

The core problem is that we have two different trust domains
and we are allowing them to impact each other. Fundementally
the stateid is in the trust domain of the client and server
interaction, while the file access is the trust domain of
the user and server interaction. We muddle things up by allowing
the user to gain access using weak authentication but the
side effect of stateid management can demand stronger
authentication.

 From my perspective, if you grant weak security access to
a file on the server, this becomes a price you simply have to
pay.  A rogue client could perform a denial of service attack,
but under a weak security association all sorts of other bad
things can happen.

Clients have some control as well, one possible implementation
would be to create multiple logical clients to a single server on a single
physical client. There can be one logical client for each
different security "level".  The result is that there will be
multiple different stateid spaces and the "weak" mounts will
not cause automatic lease renewal of the "strong" mounts. The
only restriction is that the client cannot mix security levels
to the same file or it will cause the same file to be in two
different logical clients. Probably not much of a restriction.

	-David