Subject: [nfsv4] Kerberos ticket expiration and NFSv4 state

From: David Sheffield <[email-masked]>
Date: Thu, 25 Sep 2003 16:10:11 -0500

Imagine an application started by a Kerberos-authenticated user that has a
byte-range lock on a file.  If the ticket expires and the application
attempts to unlock, close and exit, neither the LOCKU nor the CLOSE will be
allowed at the server because of the expired ticket.  Since the client must
allow the application to close and exit, it should probably clean up the
state.  However, now the client and server have different views of the
state.  In fact re-running the same application on the client will result
in a lock conflict due to the stale lock on the client.  Assuming the
client is able to continue to renew its lease, I see no way this will ever
get cleared up short of a  SETCLIENTID by the client with a new verifier.
The problem with this is that other users on the same client who may still
be authenticated and have their own state will have their state blown away
on the server by the SETCLIENTID.

What's a client to do?

David W. Sheffield
[email-masked]
(512)838-3535

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 29 Sep 2003 09:48:31 -0700

This is my first reaction and I have to think some more about the
whole issue of credentials for locking requests, about which the 
spec doesn't seem to say much.  That may be because of a principled
decision that they belong squarely within the ambit of server
fs semantics, which the spec leaves alone or it might be that 
we just overlooked the issue.

In any case, you seem to be assuming that the only credentials
with which the LOCKU and CLOSE can be done are the expired ones,
leaving the client unable to do much.  It seems reasonable not
to allow me to destroy your locks, but, you are also assuming 
that the client can do a SETCLIENTED with some other credentials
(root or something like it?), destroying your locks as well as 
everybody else's.  So I'm thinking that if those credentials are
sufficient to destroy everybody's locks, they should also be adequate 
for the client to do LOCKU/CLOSE to get rid of the locks that would 
otherwise be orphaned, causing all the ugliness that you are 
concerned about.   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
David Sheffield
Sent: Thursday, September 25, 2003 5:10 PM
To: [email-masked]
Subject: [nfsv4] Kerberos ticket expiration and NFSv4 state

What's a client to do?

David W. Sheffield
[email-masked]
(512)838-3535

---

From: Mike Eisler <[email-masked]>
Date: Mon, 29 Sep 2003 10:19:22 -0700

> state.  In fact re-running the same application on the client

Not at all. The client is well aware that the attempt to
unlock the file has failed. Isn't this just a variation on
the theme described in:

	http://www.connectathon.org/talks03/eric.pdf

 > will result

If you can re-run the application, then it must have been able
to get a new ticket. Thus the client, because it is
aware it has a lock, can now unlock.

 > get cleared up short of a  SETCLIENTID by the client with a

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.

---

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

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 01:04 PM

        To:     Carl Burnett/Austin/IBM@IBMUS
        cc:     [email-masked]
        Subject:        Re: [nfsv4] Kerberos ticket expiration and NFSv4 state

Carl Burnett wrote:

> I think this is independent of Erik's discussion and the state id 
recovery

We disagree then.

[Carl: Let me try again. As a result of expired authentication, a client 
may have to replay requests. So in that sense the retry stuff applies. But 
the subject of authentication requirements for operations like CLOSE and 
LOCKU has a been presented is a different aspect that is not fully 
addressed by the retry discussion and lessons in Erik's document.
]

> stuff. As Dave Noveck hinted, the server is going to need to allow LOCKU 

> and CLOSE independent of the authentication used. Truth is the 
application 
> close at the client that represents last close isn't necessarily the one 

> that did the open. I could be using a different authentication context 
or 

Why?

> even a different auth flavor. Both CLOSE and LOCKU could be viewed as 

Only if the server allows multiple auth flavors per objects.
If it doesn't, it will be the same authentication flavor.

> "client wide" management, and therefore maybe the client should just use 

> what ever authentication model it used with SETCLIENTID. Perhaps the 
> server should ignore the authentication or just check that is the same 
> authentication that was used in SETCLIENTID.

At the cost of reduced security? User's of NFS won't (and don't)
expect this, and are surprised that this is how it works with NLM
and NFS.

> If its of any relevance, this in concept is how DFS (and AFS minus 
> locking, which it did not really have) viewed the management of open and 

> byte range locking related state. State management was a "client 
> authenticated model", not per user. Credential expiration and related 
> failures for normal users was one of the factors in this. Also, you 
cannot 
> assume a credential expiration or security related failures for a 
> user/application will ever be resolved.

NFSv4.0's authentication model is user to server, not
client host to server. If we want to have a different
model, that's NFSv4.next (or NFS w/ AUTH_SYS).

[CARL: DFS was primarily user to server too. But certain aspects were 
client host to server. Not really that different from the fact that in NFS 
V4, SETCLIENTID is in fact client host to server. DFS just had a wider set 
of operations that fall into that category. As Dave N. stated earlier, it 
may be more of an effect of the NFS spec not stating specifics on some of 
these interesting cases like CLOSE and LOCKU where the primary effect of 
the operation is state management, not file resource access or 
manipulation. LOCKU of course straddles on both a bit.
]

---

From: Carl Burnett <[email-masked]>
Date: Mon, 29 Sep 2003 14:57:06 -0500

As Kevin mentions, the administrative overhead of having to maintain a 
client host principal with DCE/DFS was not popular. This is why later 
releases offered the option of slim client where the client did not have a 
host principal. The trade-off was some security exposure for host to host 
transactions with the benefit of reduced administration. Strong security 
for users accessing data still applied. Many environments that trusted 
their networks were willing to make this trade-off as DCE slim client was 
incredibly popular - especially for DFS installations. For environments 
with higher security requirements or application servers, host principals 
were often used. In addition, the DFS server could be set such that it 
required full DCE (krb5) authentication even for host to host transactions 
such as state management. You could even set the server to allow only 
integrity or privacy.

Carl Burnett

Kevin Coffman <[email-masked]>
Sent by: [email-masked]
09/29/2003 02:31 PM

        To:     Mike Eisler <[email-masked]>, "J. Bruce Fields" <[email-masked]>, 
[email-masked]
        cc: 
        Subject:        Re: [nfsv4] Kerberos ticket expiration and NFSv4 state

> On Mon, Sep 29, 2003 at 12:04:06PM -0700, Mike Eisler wrote:
> > J. Bruce Fields wrote:
> > 
> > >On Mon, Sep 29, 2003 at 10:37:43AM -0700, Mike Eisler wrote:
> > >>(who among clients uses Kerberos V5 for SETCLIENTID?
> > >>Don't all stand up at once. :-))
> > >
> > >Standing up, sheepishly....
> > >
> > >Using krb5 for the setclientid turns out to be a pain, though, since 
it
> > 
> > Why? Pick principal name, any principal name, preferablly host
> > instance specify, shove it into krb5.keytab, configure your
> > client to use that for SETCLIENTID. Done.
> > 
> > >means the client has to have some sort of machine or root creds 
around
> > >all the time.  I'd like to understand what the implications are of 
using
> > 
> > I'm failing to understand why machine creds make people unhappy.
> > I can't imagine how such people manage to run IPsec.
> 
> What bothers some users is the need for a host/<hostname>@<realm> princ
> for Kerberos V authentication + root/<hostname>@<realm> for NFS client
> support.  Arguably one should do - and it's true, it's just a small
> matter of programming/configuration.

What bothers administrators is that these host/root keys require
administrator action for each client.  As I recall, this was a
detriment to DCE/DFS.  And while it is true that a host key is
required to do K5 authentication correctly, it is often not done
correctly :-/