RE: [nfsv4] allowed delayed writes via AUTH_GSS

mike@eisler.com

Message-ID: <3F7B60E4.2080303@eisler.com>
From: Mike Eisler <mike@eisler.com>
Subject: RE: [nfsv4] allowed delayed writes via AUTH_GSS
Date: Wed, 01 Oct 2003 16:19:00 -0700

 > From: rick@snowhite.cis.uoguelph.ca

 > Just suppose the following:
 > 1 - Client does a SetClientID with AUTH_GSS, where the principal is
 > 	nfs/host1@KERBEROS.REALM and gets clientid0
 > 2 - Client Opens file "X" for writing, using clientid0 and
 > AUTH_GSS, where
 > 	the principal is <user>@KERBEROS.REALM successfully
 > 	getting stateid0
 > 3 - Client Writes to file "X" using stateid0 and AUTH_GSS, where the
 > 	principal is nfs/host1@KERBEROS.REALM
[...]
 > It seems to me it just comes down to how trustworthy the
 > client's keytab
 > file is vs how trustworthy the user passwords and stashed tgt is?

Yes that is the case.

When all we had was AUTH_SYS, ignioring IP
address spoofing, its security came down to
how trustworthy the client was. When we added RPCSEC_GSS
to NFSv[23], the security still came down to how trustworthy the
client was, but there was a way for clients to destroy their
credentials. And eventually, the Kerberos credentials expired.

Your proposal is somewhere between the two extremes, but I'd
put it closer to AUTH_SYS than pure user-to-server security.
In my opinion of course.

There's no need to complicate
the NFSv4[.next] though. Instead, create a new pseudo-mechanism
which is layered over a real mechanism. The real
mechanism uses crypto (for example it might be the existing
Kerberos V5) to authenticate a per-client
machine principal to the target and produces a single context
per client-machine/server pair. The pseudo mechanism implements
GSS_GetMIC, GSS_Wrap,  (which RPCSEC_GSS used for
authentication, integrity, and privacy) via calls to GSS_GetMIC
and GSS_Wrap on the aforementioned machine/server context.

Fewer contexts, easy to use, easy to implement, and you can do it
with NFSv[234] ... NFSv4.1 not needed. Oh and less secure, but
at least the client and server have to agree, and it is a decision
that is obvious to the customer.

Anyone who wants to submit an i-d for this could cut and paste from
the CCM i-d.

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