Subject: Re: Summary of NFSv4 WG Meetings @ IETF 47, Adelaide (long)

From: Mike Eisler <[email-masked]>
Date: Mon, 10 Apr 2000 04:38:30 -0700 (PDT)

Brent wrote:

> Neil Brown raised a question about LIPKEY authentication for server
> callbacks.  Mike Eisler suggested that the server might provide a
> public key for the client to use.
...
> Neil Brown expressed enthusiasm for the use of LIPKEY in a campus
> environment.

I'd like to elaborate on this. The issue Neil brought up relates to
section 3.4 Callback RPC Authentication. An excerpt says:

   It should be noted that LIPKEY may not work for callbacks, since the
   LIPKEY client uses a user id/password.  If the NFS client receiving
   the callback can authenticate the NFS server's user name/password
   pair, and if the user that the NFS server is authenticating to has a
   public key certificate, then it works.

Neil disliked the requirement that the user must get a certificate
in order for callbacks to work. Neil's scenario is that he would like
to be able to use LIPKEY in an environment of desk tops where
users aren't tied to a single machine. He suggested that perhaps
client's could have per-host principal for dealing with callbacks.

Also Paul Sangster of Sun noted to me after the meeting that it seemed
silly, given that LIPKEY requires SPKM-3 and SPKM-3 allows for the client
and server to mutually authenticate each other with a certificate for
each, that NFS client must maintain a server user name and password
pair.

OK, Neil and Paul raised excellent points and I agree.

Another suggestion, not from Neil, Paul, or I, was to allow callbacks
to be unauthenticated. I don't like this ... there are some obvious
denial of service (DoS) issues with that, and no doubt some less
obvious DoS attacks that we can't anticipate today, but crackers will
discover tomorrow.

Since the meeting I've mulled over three solutions.

(1) Extend LIPKEY, or add a variant of LIPKEY that allows the
client side to have present a certificate to the server, and the
server to present a user name/password to the client. So in this
scenario, when the callback is done, the NFS server becomes a LIPKEY
client and uses its certificate to authenticate to the
NFS client (the callback server), and the NFS client uses the user's
user name/password pair to authenticate back the NFS server.

I don't like this for two reasons:

	(a) it's yet another burden upon the NFSv4 implementation.
	(b) it assumes that when the callback is done, that the NFS
		client will have the user's user name and password handy.
		The user name being handy is reasonable, but for security
		reasons, the user's password might not be. We shouldn't
		require/allow implementations to cache a password for
		indefinite periods of time, which delegations decidely
		are.

(2) Implement a new GSS-API mechanism called the "reflective mechanism" 
which would work by taking an existing established security context,
say between user [email-masked], and [email-masked], and allowing
the server side to initiated a callback utilizing the existing context.
This is actually a cool idea, however it has the following
drawbacks:

	(a) Delegations are indefinite. The security context used to establish
		the delegation might have expired. 

	(b) Off the top of my head, I don't know if the reflective mechanism
		is achievable without extending one or more of RPCSEC_GSS,
		GSS-API, or NFSv4.

	(c) it's yet another burden upon the NFSv4 implementation.

(3) Neil's notion of a per-client principal was something I thought about. I
don't like the notion of explicitly  requiring such a principal, but I
realized that for practical implementations on kernel based NFS clients,
such as we'd expect on UNIX, we have a per-client principal. That is the
principal used in the SETCLIENTID operation. NFSv4 is designed so
that a physical client can issue a single SETCLIENTID and still allow
multiple principals to uses the client id that SETCLIENTID handshake
produces. Section 3.4 says

   The callback RPC (described later) must mutually authenticate the NFS
   server to the principal that acquired the delegation (also described
		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   later), using the same security flavor the original delegation
   operation used.

If we change that to:

   The callback RPC (described later) must mutually authenticate the NFS
   server to the principal that acquired the clientid (also described
				^^^^^^^^^^^^^^^^^^^^^^
   later), using the same security flavor the original SETCLIENTID
		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   operation used. Because LIPKEY is layered over SPKM-3, it is permissible
   for the server to use SPKM-3 and not LIPKEY for the callback even if the
   client used LIPKEY for SETCLIENTID.
   
then the practical effect is that the NFS client can establish a per
client host principal for callback purposes and avoid the overhead
the Neil brought up as an issue.

Paul's comment leads to another simplification. When the SETCLIENTID is
done, the client could use LIPKEY for that, and thus send a per-host
user name and password to the server. But this requires that the NFS
server have access to a password database that has per-host entries. I
don't know about NT or W2k, but UNIX environments typically don't have
per-host password entries that are accessible anywhere but locally. So,
using LIPKEY for SETCLIENTID amounts to more infrastructure which was
against the intent of LIPKEY. Furthermore, when the NFS server makes a
callback, it will be authenticating to a target that has a certificate.
Thus a per-NFS client certificate is needed anyway.

So I would add to section 3.4 this text:

	In situations where NFS client uses LIPKEY and uses a per-host
	principal for the SETCLIENTID operation, instead of using
	LIPKEY for SETCLIENTID, it is RECOMMENDED that SPKM-3 with mutual
	authentication be used. This effectively means that the client
	will use a certificate to authenticate and identify the
	initiator to the target on the NFS server. Using SPKM-3 and not
	LIPKEY has the following advantages:

	* When the server does a callback, it must authenticate to the
	principal used in the SETCLIENTID. Even if LIPKEY is used,
	because LIPKEY is layered over SPKM-3, the NFS client will need
	to have a certificate that corresponds to the principal used in
	the SETCLIENTID operation.  From an administrative perspective,
	having a user name, password, and certificate for both the
	client and server is redundant.

	* LIPKEY was intended to minimize additional infrastructure
	requirements beyond a certificate for the target, and the
	expectation is that existing password infrastructure can be
	leveraged for the initiator.  In some environments, a per-host
	password does not exist yet. If certificates are used for any
	per-host principals, then additional password infrastructure is
	not needed.

	* In cases and a host is both an nfs client and server, it can
	share the same per-host certificate.

And in section 3.2.1.3 (SPKM-3 as a security triple) 
change

   Even though LIPKEY is layered onto SPKM-3, SPKM-3 is specified as a
   mandatory set of triples to handle the situation when the initiator
   (the client) is anonymous.  If the initiator is anonymous, there will
   not be a user name and password to send to the target (the server).

to:

   Even though LIPKEY is layered over SPKM-3, SPKM-3 is specified as a
   mandatory set of triples to handle the situations where the
   initiator (the client) is anonymous or where the initiator has its
   own certificate.  If the initiator is anonymous, there will not be a
   user name and password to send to the target (the server). If the
   initiator has its own certificate, then using passwords is superfluous.

The advantages of this approach are:

	- no additional implementation burden
	- minimal (or zero, because most of the hosts in environment
		Neil is considering are both nfs clients and servers)
		additional administrative burden
	- no substantial changes to the nfsv4 protocol

The amount of text changed is not insignificant, but it all stems
from a simple change relating to what principal target to use on callbacks.

	-mre