Subject: RE: The RENEW operation and RPC authentication

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 9 Oct 2002 15:37:23 -0700

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.

-----Original Message-----
From: Carl Burnett [mailto:[email-masked]]
Sent: Wednesday, October 09, 2002 5:18 PM
To: [email-masked]
Subject: The RENEW operation and RPC authentication

I have a question about the RENEW operation and the RPC authentication 
that should be used with it. My guess is that RENEW should use the same 
RPC auth flavor and credential that it used to successfully establish the 
associated clientid. If this is true, then the RENEW operation needs to 
check this and potentially return an error (perhaps NFS4ERR_WRONGSEC). 
Currently, the RENEW operation does not list NFS4ERR_WRONGSEC as a 
possible error and it does not discuss RPC security requirements for the 
operation.

Is my guess correct?

Should the spec be updated to provide the needed detail here. If this is 
in the spec, and I missed it, I apologize. If so, can someone point me to 
the right spot.

On the subject of NFS4ERR_WRONGSEC, I noticed that the SECINFO operation 
discusses it as a potential error return in the implementation details, 
but its not included in the list of potential error returns.

Thanks,
Carl

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

---

From: David Robinson <[email-masked]>
Date: Wed, 09 Oct 2002 21:18:30 -0500

> level of paranoia to properly analyze those kinds of

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: Mike Eisler <[email-masked]>
Date: Thu, 10 Oct 2002 12:09:26 -0700

> used for that operation might normally be quite different.

True, but what if everything on the server
is exported with spkm3i? Should
a client then be allowed to use AUTH_NONE
to RENEW the lease? I don't think so.
On the other hand if everything is exported
with AUTH_SYS, then it is ludricous
to require the client to issue RENEW with
the same principal and rpc security
that the _CONFIRM was issued with.

> level of paranoia to properly analyze those kinds of

The attack I can see is is a denial of service attack, whereby the
attacker detects that a client has died (or perhaps has taken command of
the router between a client and server and simulates client death), but
issues RENEW from a  spoofed clientid to force the server to keep resources
held. I can imagine scenarios where this attack would be of minor
impact (especially since, realistically, most clients will be using 
AUTH_SYS,
and that its own set of bigger issues)  and scenarios where it would
be a big deal.

So I think Carl and Dave each  have merits in their arguments. If we want to
deal with this before ietf last call, here is a suggested edit:

ADD, in section 14.2.28.  Operation 30: RENEW - Renew a Lease, this
paragraph after the IMPLEMENTATION section:

    The client that issues RENEW MUST choose the
    principal, RPC security flavor, and if
    applicable, GSS-API mechanism and service
    via one of the following algorithms:

    - The client uses the same principal,  RPC
       security flavor -- and if the flavor was RPCSEC_GSS --
       the same mechanism and service that was used when the client id
       was established via SETCLIENTID_CONFIRM.

    - The client uses any principal, RPC security flavor
       mechanism and service combination
       that currently has an OPEN file on the server. I.e.
       the same principal had a successful OPEN
       operation, the file is still open by that principal,
       and the flavor, mechanism, and service of RENEW match that
       of the previous OPEN.

    The server MUST reject a RENEW that does not use one the aforementioned
    algorithms, with the error NFS4ERR_ACCESS.

CHANGE, in the same section

   ERRORS

     NFS4ERR_ADMIN_REVOKED

TO:

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_ADMIN_REVOKED