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

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

Dave Noveck writes:

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

Generally speaking this won't work because the protection
models for SETCLIENTD and file objects are reversed.
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?
Don't all stand up at once. :-))
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.

Whereas RPCSEC_GSS/krb5 is used for the original LOCK, and
presumably the NFS server has bound that form of authentication
to the object being locked.

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 29 Sep 2003 14:36:33 -0400

On Mon, Sep 29, 2003 at 10:37:43AM -0700, Mike Eisler wrote:
> (who among clients uses Kerberos V5 for SETCLIENTID?

Standing up, sheepishly....

Using krb5 for the setclientid turns out to be a pain, though, since it
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
auth_sys for setclientid.  Doesn't that mean anyone that could
impersonate a client using auth_sys could also invalidate all of that
client's state?  I guess it's just a denial of service attack, but it
seems like a particularly effective one.

--Bruce Fields

---

From: Mike Eisler <[email-masked]>
Date: Mon, 29 Sep 2003 12:04:06 -0700

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

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

> seems like a particularly effective one.

Yes.

---

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

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

Cheers,

Nico
--

---

From: Kevin Coffman <[email-masked]>
Date: Mon, 29 Sep 2003 15:31:52 -0400

> 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 :-/

---

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

On Mon, Sep 29, 2003 at 03:31:52PM -0400, Kevin Coffman wrote:
Nico> What bothers some users is the need for a host/<hostname>@<realm>
Nico> princ for Kerberos V authentication + root/<hostname>@<realm> for
Nico> NFS client support.  Arguably one should do - and it's true, it's
Nico> just a small matter of programming/configuration.

> required to do K5 authentication correctly, it is often not done

For single-user systems no hostbased credentials should be necessary for
secure NFS.

For multi-user systems some sort of keying is needed in order to
authenticate users logging into them with any distributed authentication
technology and properly (but not if authentication is done via a local
password db, say).

E.g., one could mix LDAP w/ some host password, or LDAP w/ SASL w/
GSS-SPKM-3 with LDAP server certs, for user authentication to the NFS
client and Kerberos V for user authentication to the NFS server, but one
must still key the multi-user client one way or the other - by giving it
a password, the ability to validate an LDA server's cert, or by giving
it Kerberos V hostbased principal(s) and key(s), etc...

Cheers,

Nico
--

---

From: Mike Eisler <[email-masked]>
Date: Mon, 29 Sep 2003 13:05:34 -0700

> [stuff clipped out, Mike wrote]
> 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

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.

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