Re: [nfsv4] Kerberos ticket expiration and NFSv4 state

cburnett@us.ibm.com

Subject: Re: [nfsv4] Kerberos ticket expiration and NFSv4 state
Message-ID: <OF3901B46E.C433D749-ON87256DB0.0072B929@us.ibm.com>
From: Carl Burnett <cburnett@us.ibm.com>
Date: Mon, 29 Sep 2003 16:10:49 -0500

See below in [Carl: ]
Carl Burnett
AIX Kernel Architecture - Network File System
(512) 838-8498, TL 678-8498
(please reply to cburnett@us.ibm.com)

Mike Eisler <mike@eisler.com>
Sent by: nfsv4-admin@ietf.org
09/29/2003 03:05 PM

        To:     nfsv4@ietf.org
        cc: 
        Subject:        Re: [nfsv4] Kerberos ticket expiration and NFSv4 state

> [stuff clipped out, Mike wrote]
>> The SETCLIENTID is done with the security flavor the
>> client chooses, so it could very well be AUTH_SYS (who
>> among clients uses Kerberos V5 for SETCLIENTID?
> I think that a server may want to require something more than AUTH_SYS.

What if my client doesn't have a krb5 or public key
infrastructure handy?

> Like Dave, it seems to me that the principal that is allowed to do
> a SETCLIENTID should also be allowed to do other state related Ops that
> release state, such as LOCKU and CLOSE (I'm not so sure about 
LOCK,OPEN,...).

Server's are free to allow that. What if the client's don't? Or
what if they do, but the scenario matches what Nico wrote:

> User locks screen, [removes smartcard from reader,] goes on vacation,
> creds expire, dirty data / locks cannot be flushed / unlocked.  Oops.

In this scenario, the application does not close or attempt to unlock
the file. Whether smart-card enabled Kerberos or PKI is
being used at all, makes no difference; the problem applies
ifone is using AUTH_SYS.

Nico's scenario only applies if the user on holiday has his applications
killed by a system administrator. And I won't bother with the obvious 
comments
about the app writer who developed software that would force the system 
administrator
to do that. But the point is, the sys admin has to be involved. Which
now invalidates Carl's assertion of lock management by sys admins being
unacceptable.

Per user client ids seem like the universal solution:
                 - no per-machine creds needed
                 - re-SETCLIENTID can happen without disrupting other
                                 users.
                 - since RENEW of the per-user SETCLIENTID
                                 won't be able to get a ticket, the leases
                                 automtically expire

[Carl: That sounds like a client writer's nightmare and potentially a lot 
of resource consumption on both sides. Given the client gained the 
privilege with its SETCLIENTID call to blow away all its state at the 
server, why let it use the same authentication to do CLOSE and LOCKU. 
Write is a different story since it is modifying file content at the 
server. The data needs to be written with valid user credentials. If 
authentication cannot be renewed, then eventually the client will have to 
discard the data and return errors to the application.

As mentioned below, a client who chooses AUTH_SYS takes on an implied 
exposure. The deficiency here is the lack of a graceful mechanism for the 
server to restrict this and tell the client why. Its not about protecting 
the server. Its about allowing an administrator to dictate the security of 
the environment from a central point of control.
]

My earlier idea about the server tieing lock revocation to ticket
expiry is bogus, because a lock could be held for a *long* time, with
no activity before the context expires, and the renewable TGT expires.

>> The reason is that the server doesn't care; it only promises
>> to reject any future SETCLIENTID for the same client that doesn't use 
the same
>> credential and security flavor that is issued within the
>> lease time.
> 
> Shouldn't the server care about throwing away all the locks when another
> SETCLIENTID is done, which is what another SETCLIENTID with AUTH_SYS and
> same uid would do, if AUTH_SYS is accepted for SETCLIENTID?

The client chose to use a weak flavor to establish the client id
and thus assumed the risk.

> I'm finally working on the GSS stuff and my current feeling (it's not
> quite an opinion yet:-) is that the server has to allow for weak
> authentication for certain Ops (similar to what Mike suggests in Sec.
> 2.3.2 of RFC2623 for V2 and 3), that are useful for the client
> equivalent of "mount".

RFC2623 stated that GETATTR, STATFS, and FSINFO
might be weakly authenticated.

Given that that NFSv4 uses LOOKUP for mounting,
it means that following that approach,
root can now browse anyones directories. I'm
not sure that is desirable.

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

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