[nfsv4] authentication required by SetClientID, etc.

rick@snowhite.cis.uoguelph.ca

From: rick@snowhite.cis.uoguelph.ca
Message-Id: <200309301612.MAA00578@snowhite.cis.uoguelph.ca>
Subject: [nfsv4] authentication required by SetClientID, etc.
Date: Tue, 30 Sep 2003 12:12:52 -0400 (EDT)

Disclaimer, this got somewhat long winded and doesn't really discuss the
protocol design, per se.
> So there are two issues here. One is whether to allow servers
> to require certain security flavors for SETCLIENTID. That's
> a reasonable idea, but can't be done till NFSv4.1 due to the
> lack of WRONGSEC in the SETCLIENID* return codes.

I'm going to put on my sysadmin hat here. Down the road, when I have
an NFSv4 server running that lots of clients can talk to, I seem to
have three choices when it comes to allowing internet access to the
server.
1 - Allow access from the world, so that anyone anywhere can do a
    SetClientID with uid 0 under AUTH_SYS. (To me this is unacceptable.
    We recently had to block off-campus ICMP Ping, because it was
    causing too much grief.)
2 - Don't allow any access from the world. This is what my V2/3 servers
    currently do, using a combination of limited routing tables and
    from IP# address filtering in the NFS server. (I only allow access
    from the 3 subnets I administer directly. The campus sysadmins put
    their Netapp boxes on private VLANS, so only their selected client
    machines can see them.) This works, but is somewhat counter to one of
    the goals of NFSv4.
3 - Allow the world to access the server so long as it has a valid
    handle for a valid AUTH_GSS token. Otherwise, the server can:
    - Drop the request/connection silently.
    OR
    - Reply AUTH_TOOWEAK at the RPC level. (This is what I am currently
      thinking of doing.)
    I don't see how replying AUTH_TOOWEAK for a compound NFSv4 RPC request
    is violating the RFC?

Now, allowing #3 does put the server at increased risk, but would be nice
to do, if it works. (One thought I've had is to let a compound RPC request
which only has PutRootFH, PutPubFH and SecInfo Ops in it through, even for
AUTH_SYS so that a client can figure out what security context it needs to
use.)

For V2/3, filtering on the basis of IP# could be done on a
per-server-filesystem basis, since an FH was at the start of each request.
Since this isn't the case for V4, I don't see how I can implement different
levels of authentication for different subtrees yet (but I'm thinking
about it), since it would be nice to be able to export a read-only subtree
to the world (the public fh), without a requirement for AUTH_GSS.
(At this point, I don't see how I can do this, except by using a separate
 server dedicated to that and accept that it is vulnerable to the
 SetClientID denial of service attack, etc.)

> Two is whether to allow the flavor used for SETCLIENTID to
> also issue the LOCKU and CLOSE (DELEGRETURN?) if it has
> the same principal as original locker, even if the flavor
> differs from what was used to get the lock.
> 
> That I think is a reasonable and correct thing to allow.

I'm not willing to trust AUTH_SYS with a uid == 0 from any machine that
is not under my administrative control, so I'm only going to allow this
if the principal is derived from AUTH_GSS, for SetClientID, etc.
If others argue that #3 above
is not acceptable (ie. AUTH_SYS must be allowed for SetClientID), then
I'm stuck with #2.

> Though I'm still puzzled as to what problem it solves.

I thought I understood his original problem, now I'm not so sure, rick

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4