Subject: The RENEW operation and RPC authentication

From: Carl Burnett <[email-masked]>
Date: Wed, 9 Oct 2002 16:18:24 -0500

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: Carl Burnett <[email-masked]>
Date: Fri, 11 Oct 2002 13:13:57 -0500

Mike,

I am wondering if it can be simplified to only require the client use the 
same security (auth_flavor, sec_mechanism, credential) that it used to 
establish its clientid (SETCLIENTID). The client already has to maintain 
this, so it should be pretty easy for the client to recall and use it when 
calling RENEW to refresh the lease based on clientid.

Here is an attempt to provide rational:

The client obtained its client id using security that was administratively 
allowed for the SETCLIENTID operation

For the case of the per object operations (OPEN, LOCK, etc), the client 
has passed some number of checkpoints.

 it has passed any applicable export restrictions for the accessed file 
system
 for many of the operations it has successfully negotiated a valid stateid
 it has passed per object access controls

So the implicit renewals do have some level of security behind them that 
has been established by administration and individual object access 
controls. The security conscious admin can control the exposure through 
export controls, etc. For example, requiring RPCSEC-GSS on all requests.

If RENEW is covered by the security requirements for establishing client 
ids (SETCLIENTID), then it seems sufficient. Now the admin has control 
over that as well, through assumed configuration of the allowable security 
for SETCLIENTID.

Thoughts?

Note, that my primary objective in asking the original question was just 
to understand how to implement RENEW. A second goal was to ensure the spec 
provides the needed guidance. And third, is the discussion of what 
security there should be.

Thanks a lot to everyone who has responded,
Carl

Carl Burnett

Mike Eisler <[email-masked]>
10/10/2002 02:09 PM

        To:     "Noveck, Dave" <[email-masked]>
        cc:     Carl Burnett/Austin/IBM@IBMUS, [email-masked]
        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.

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.

>
> 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.

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

>
>
> -----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
>
>