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

From: [email-masked]
Date: Mon, 29 Sep 2003 14:53:56 -0400 (EDT)

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

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

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

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".
Then, the SetClientId Op defines a "priviledged principal" for the
state related to the resultant clientid (the one that is checked for
when the SetClientIDConfirm is done and remembered for subsequent
SetClientID Ops with the same client name). I am thinking that this
"priviledged principal" should be allowed to do state related Ops on
that ClientId, as noted above.

I am thinking that my server might require a principal for SetClientID
be in the same form as a callback principal (ie nfs@<hostname>), for clients
not allowed to use AUTH_SYS.
(I believe nfs@<hostname> uses a keytab entry, so the client can always get
another ticket for it? I am not very conversant with Kerberos.)

I would be very interested in hearing what other server writers are
doing w.r.t. requirements on GSS authenticators for various Ops.

What's a client to do?
If servers do what I'm thinking about above, the client can fall back
to the principal used for SetClientID to do the Ops.

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

---

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

> release state, such as LOCKU and CLOSE (I'm not so sure about LOCK,OPEN,...).

And writes (e.g., dirty blocks but no unexpired creds to write them with)?

> 2.3.2 of RFC2623 for V2 and 3), that are useful for the client

Not for single-user clients, no.  I'm starting to think that what we
need for multi-user clients is: a) a hostbased credential for the
client, b) binding of all GSS contexts to the CLIENTID, c) the use of
the client's hostbased principal to clean up state authenticated with
principals now not available on the client.  So, I think I agree with
you.  Which principal is used to tear down state is not important as
long as its contexts are bound to the same CLIENTID.

Of course, binding to the CLIENTID is not as neat as binding to a
cryptographically protected session whose key exchange involves a
Diffie-Hellman exchange...  CCM, IPsec and all that...

> that ClientId, as noted above.

As long as the contexts for all principals on the client are bound to
the CLIENTID, which, I think, they sort of are (I should check), no
problem.

> another ticket for it? I am not very conversant with Kerberos.)

Well, yes, though clients generally use "root@hostname" GSS hostbased
names (which translates to root/hostname@realm, for Kerberos V).

The form of the client principal name is really not very interesting,
though some server implementations may require one form or another for
clients that are to have super-user privileges.

Cheers,

Nico
--