Subject: Re: [nfsv4] Kerberos ticket expiration and NFSv4 state

From: Carl Burnett <[email-masked]>
Date: Mon, 29 Sep 2003 13:21:32 -0500

Look below:

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

Mike Eisler <[email-masked]>
Sent by: [email-masked]
09/29/2003 12:48 PM

        To:     "Noveck, Dave" <[email-masked]>
        cc:     [email-masked]
        Subject:        Re: [nfsv4] Kerberos ticket expiration and NFSv4 state

Noveck, Dave wrote:

>> If lease is not renewed before lease expiration, then the lock
>> goes away either when the lease expires, or when a conflicting
>> lock is requested by the client or a different client.
> 
> But the hypothesis here is that the lease will be renewed because
> other users, who have valid unexpired credentials, will do locking

Ok, fair enough.

> requests that renew the lease associated with all of the locks for
> that client, which also include those associated with the expired
> credentials.  So given that renewal is continuing to occur, the question
> is how the locks associated with the expired credential can be gotten
> rid of.  It won't happen solely due to lease expiration. 

And I'm having trouble accepting that this is normal scenario.
Why wouldn't the client automatically renew his ticket?
If another kinit is required, why wouldn't the user be motivated
to issue one?

CARL: Trust me, its very normal, and many admins want client users to 
periodically recertify their authentication. A lot of effort went into DFS 
to try to deal with this and accommodate recertification w/o immediately 
reclaiming resources.

Worst case, you get rid of the lock via a management interface,
just as some NFS servers today provide the means for
clearing locks the client has apparently forgotten about.

Carl: Not acceptable. Admins don't have time to play with state at the 
server on behalf of thousands of clients and massive numbers of files.

If there are clients that acquire locks without an acceptable
strategy for renewing tickets, then they'll have to issue one
SETCLIENTID per Kerberos principal.

Carl: not necessarily if you consider the client is the responsible entity 
for the some of primarily state oriented ops, not the accessing user.

Hmm, maybe we should have side bad locking protocol that
always listens over AUTH_SYS. Oops, we tried that
already. :-)

Carl: One of the reasons that months ago I proposed the idea of WRONGSEC 
returns on SETCLIENTID and SECINFO options to request a list of flavors 
the server accepts for SETCLIENTID. Then servers with strong client to 
server security requirements can enforce and communicate them to clients.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Mike Eisler <[email-masked]>
Date: Mon, 29 Sep 2003 11:58:43 -0700

> to try to deal with this and accommodate recertification w/o immediately 

Recertification of authentication (of which is kinit
is an example, isn't it?) isn't incompatible with renewing
a ticket or getting a new one. The opposite in fact.

It sounds like you are envisioning environments where users will
be unable to re-certify either via an actual password
prompt or via a renewable TGT. That seems abnormal.

> server on behalf of thousands of clients and massive numbers of files.

Another thought is that if the server records in the lock state that
it was acquired via a non-trivial security flavor, then when the
lock owner's cred expires, the server can revoke the lock when a
conflicting request comes in.

> server security requirements can enforce and communicate them to clients.

In NFSv4.0 Unprotected SETCLIENTID and SECINFO arguments and
results are no threat to the server, just to the client. I agree,
that if NFSv4.next adds a server requirement that the principal doing
the SETCLIENTID be allowed to unlock, close, and return delegations,
that WRONGSEC needs to be among the SETCLIENTID return codes.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 29 Sep 2003 12:26:22 -0700

> > rid of.  It won't happen solely due to lease expiration. 
Mike> And I'm having trouble accepting that this is normal scenario.
Mike> Why wouldn't the client automatically renew his ticket?
Mike> If another kinit is required, why wouldn't the user be motivated
Mike> to issue one?
> to try to deal with this and accommodate recertification w/o immediately 

Yeah, credential expiration at the wrong time can be unavoidable (think
smartcards, PKINIT, SPKM).

Mike> Worst case, you get rid of the lock via a management interface,
Mike> just as some NFS servers today provide the means for
Mike> clearing locks the client has apparently forgotten about.
> server on behalf of thousands of clients and massive numbers of files.

For single-user clients credential expiration is akin to client failure
- let the server reclaim delegations and kill locks and leave it at
that.

Multi-user clients ought to have a hostbased credential that can be used
to flush dirty pages / hold/undo locks held by users whose credentials
have expired.  Unfortunately, such hostbased credentials either have to
be powerful or bound to the same CLIENTID as was used to build up the
state held by users with now expired credentials.

Mike> If there are clients that acquire locks without an acceptable
Mike> strategy for renewing tickets, then they'll have to issue one
Mike> SETCLIENTID per Kerberos principal.
> for the some of primarily state oriented ops, not the accessing user.

See above.

Cheers,

Nico
--