nfs.secure.ms

早期freebsd实现

.I "conversation key, CK."
The client encrypts the conversation key using a public key scheme,
and sends it to the server in its first transaction.
This key is the only thing that is ever encrypted with public key cryptography.
The particular scheme used is described further on in this chapter.
For now, suffice to say that for any two agents A and B,
there is a DES key $K sub AB$ that only A and B can deduce.
This key is known as the
.I "common key,"
$K sub AB$.
.EQ
gsize 10
.EN
.ne 1i
.PS
.in +.7i
circlerad=.4
boxht=.2
boxwid=1.3
circle "\s+9A\s-9" "(client)" at 0,1.2
circle "\s+9B\s-9" "(server)" at 5.1,1.2
line invis at .5,2 ; box invis "\fBCredential\fP"; line invis;
	box invis "\fBVerifier\fP"
arrow at .5,1.7; box "$A, K sub AB (CK), CK(win)$"; arrow;
	box "$CK(t sub 1 ), CK(win + 1)$"; arrow
arrow <- at .5,1.4; line right 1.3; line;
	box "$CK(t sub 1 - 1), ID$"; arrow <-
arrow at .5,1; box "ID"; arrow;
	box "$CK(t sub 2 )$"; arrow
arrow <- at .5,.7; line right 1.3; line;
	box "$CK(t sub 2 - 1), ID$"; arrow <-
arrow at .5,.3; box "ID"; arrow;
	box "$CK(t sub n )$"; arrow
arrow <- at .5,0; line right 1.3; line;
	box "$CK(t sub n - 1), ID$"; arrow <-
.PE
.EQ
gsize 11
.EN
.in -.7i
.LP
The figure above illustrates the authentication protocol in more detail,
describing client A talking to server B.
A term of the form $K(x)$ means $x$ encrypted with the DES key $K$.
Examining the figure, you can see that for its first request,
the client's credential contains three things: 
its name $A$, the conversation key $CK$ encrypted with the common key 
$K sub AB$, and a thing called $win$ (window) encrypted with $CK$.
What the window says to the server, in effect, is this:
.LP
.I
I will be sending you many credentials in the future,
but there may be crackers sending them too,
trying to impersonate me with bogus timestamps.
When you receive a timestamp, check to see if your current time
is somewhere between the timestamp and the timestamp plus the window.
If it's not, please reject the credential. 
.LP
For secure NFS filesystems, the window currently defaults to 30 minutes.
The client's verifier in the first request contains the encrypted timestamp
and an encrypted verifier of the specified window, $win + 1$. 
The reason this exists is the following.
Suppose somebody wanted to impersonate A by writing a program
that instead of filling in the encrypted fields of the credential and verifier,
just stuffs in random bits.
The server will decrypt CK into some random DES key,
and use it to decrypt the window and the timestamp.
These will just end up as random numbers.
After a few thousand trials, there is a good chance
that the random window/timestamp pair will pass the authentication system.
The window verifier makes guessing the right credential much more difficult.
.LP
After authenticating the client,
the server stores four things into a credential table:
the client's name A, the conversation key $CK$, the window, and the timestamp.
The reason the server stores the first three things should be clear:
it needs them for future use.
The reason for storing the timestamp is to protect against replays.
The server will only accept timestamps
that are chronologically greater than the last one seen,
so any replayed transactions are guaranteed to be rejected.
The server returns to the client in its verifier an index ID
into its credential table, plus the client's timestamp minus one,
encrypted by $CK$.
The client knows that only the server could have sent such a verifier,
since only the server knows what timestamp the client sent.
The reason for subtracting one from it is to insure that it is invalid
and cannot be reused as a client verifier.
.LP
The first transaction is rather complicated,
but after this things go very smoothly.
The client just sends its ID and an encrypted timestamp to the server,
and the server sends back the client's timestamp minus one,
encrypted by $CK$.
.#
.NH 1
\&Public Key Encryption
.IX "public key encryption"
.LP
The particular public key encryption scheme Sun uses
is the Diffie-Hellman method.
The way this algorithm works is to generate a
.I "secret key"
$SK sub A$ at random
and compute a
.I "public key"
$PK sub A$ using the following formula
($PK$ and $SK$ are 192 bit numbers and \(*a is a well-known constant):
.EQ
PK sub A ~ = ~ alpha sup {SK sub A}
.EN
Public key $PK sub A$ is stored in a public directory,
but secret key $SK sub A$ is kept private.
Next, $PK sub B$ is generated from $SK sub B$ in the same manner as above.
Now common key $K sub AB$ can be derived as follows:
.EQ
K sub AB ~ = ~ PK sub B sup {SK sub A} ~ = ~
( alpha sup {SK sub B} ) sup {SK sub A} ~ = ~
alpha sup {( SK sub A SK sub B )}
.EN
Without knowing the client's secret key,
the server can calculate the same common key $K sub AB$
in a different way, as follows:
.EQ
K sub AB ~ = ~ PK sub A sup {SK sub B} ~ = ~
( alpha sup {SK sub A} ) sup {SK sub B} ~ = ~
alpha sup {( SK sub A SK sub B )}
.EN
Notice that nobody else but the server and client can calculate $K sub AB$,
since doing so requires knowing either one secret key or the other.
All of this arithmetic is actually computed modulo $M$,
which is another well-known constant.
It would seem at first that somebody could guess your secret key
by taking the logarithm of your public one, 
but $M$ is so large that this is a computationally infeasible task.
To be secure, $K sub AB$ has too many bits to be used as a DES key,
so 56 bits are extracted from it to form the DES key.
.LP
Both the public and the secret keys
are stored indexed by netname in the Yellow Pages map
.I publickey.byname
the secret key is DES-encrypted with your login password.
When you log in to a machine, the
.I login 
program grabs your encrypted secret key,
decrypts it with your login password,
and gives it to a secure local keyserver to save
for use in future RPC transactions.
Note that ordinary users do not have to be aware of 
their public and secret keys.
In addition to changing your login password, the
.I yppasswd 
.IX "yppasswd command" "" "\&\fIyppasswd\fP command"
program randomly generates a new public/secret key pair as well.
.LP
The keyserver
.I keyserv (8c)
.IX "keyserv daemon" "" "\&\fIkeyserv\fP daemon"
is an RPC service local to each machine
that performs all of the public key operations,
of which there are only three.  They are:
.DS
setsecretkey(secretkey)
encryptsessionkey(servername, des_key)
decryptsessionkey(clientname, des_key)
.DE
.I setsecretkey()
tells the keyserver to store away your secret key $SK sub A$ for future use;
it is normally called by
.I login .
The client program calls
.I encryptsessionkey()
to generate the encrypted conversation key
that is passed in the first RPC transaction to a server.
The keyserver looks up
.I servername 's
public key and combines it with the client's secret key (set up by a previous
.I setsecretkey()
call) to generate the key that encrypts
.I des_key .
The server asks the keyserver to decrypt the conversation key by calling
.I decryptsessionkey().
Note that implicit in these procedures is the name of caller,
who must be authenticated in some manner.
The keyserver cannot use DES authentication to do this,
since it would create deadlock. 
The keyserver solves this problem by storing the secret keys by
.I uid ,
and only granting requests to local root processes.
The client process then executes a
.I setuid 
process, owned by root, which makes the request on the part of the client,
telling the keyserver the real
.I uid 
of the client.  Ideally, the three operations described above
would be system calls, and the kernel would talk to the keyserver directly,
instead of executing the
.I setuid 
program.
.#
.NH 1
\&Naming of Network Entities
.IX "naming of network entities"
.IX "network naming"
.LP
The old UNIX authentication system has a few problems when it comes to naming.
Recall that with UNIX authentication,
the name of a network entity is basically the
.I uid .
These
.I uid s
are assigned per Yellow Pages naming domain,
which typically spans several machines.
We have already stated one problem with this system,
that it is too UNIX system oriented, 
but there are two other problems as well.
One is the problem of
.I uid 
clashes when domains are linked together.
The other problem is that the super-user (with
.I uid 
of 0) should not be assigned on a per-domain basis, 
but rather on a per-machine basis.
By default, the NFS deals with this latter problem in a severe manner:
it does not allow root access across the network by
.I uid 
0 at all.
.LP
DES authentication corrects these problems
by basing naming upon new names that we call
.I netnames.
Simply put, a netname is just a string of printable characters,
and fundamentally, it is really these netnames that we authenticate.
The public and secret keys are stored on a per-netname,
rather than per-username, basis.
The Yellow Pages map
.I netid.byname
maps the netname into a local
.I uid 
and group-access-list, 
though non-Sun environments may map the netname into something else.
.LP
We solve the Internet naming problem by choosing globally unique netnames.
This is far easier then choosing globally unique user IDs.
In the Sun environment, user names are unique within each Yellow Page domain.
Netnames are assigned by concatenating the operating system and user ID
with the Yellow Pages and ARPA domain names.
For example, a UNIX system user with a user ID of 508 in the domain
.I eng.sun.COM 
would be assigned the following netname:
.I [e-mail] .
A good convention for naming domains is to append 
the ARPA domain name (COM, EDU, GOV, MIL) to the local domain name.
Thus, the Yellow Pages domain
.I eng 
within the ARPA domain
.I sun.COM 
becomes
.I eng.sun.COM .
.LP
We solve the problem of multiple super-users per domain
by assigning netnames to machines as well as to users.
A machine's netname is formed much like a user's.
For example, a UNIX machine named
.I hal 
in the same domain as before has the netname
.I [e-mail] .
Proper authentication of machines is very important for diskless machines
that need full access to their home directories over the net.
.LP
Non-Sun environments will have other ways of generating netnames, 
but this does not preclude them from accessing
the secure network services of the Sun environment.
To authenticate users from any remote domain,
all that has to be done is make entries for them in two Yellow Pages databases.
One is an entry for their public and secret keys, 
the other is for their local
.I uid 
and group-access-list mapping.
Upon doing this, users in the remote domain
will be able access all of the local network services,
such as the NFS and remote logins.
.#
.NH 1
\&Applications of DES Authentication
.IX "applications of DES authentication"
.IX "authentication" "DES"
.LP
The first application of DES authentication
is a generalized Yellow Pages update service. 
This service allows users to update private fields in Yellow Page databases.
So far the Yellow Pages maps
.I hosts,
.I ethers,
.I bootparams
and
.I publickey
employ the DES-based update service.
Before the advent of an update service for mail aliases,
Sun had to hire a full-time person just to update mail aliases.
.LP
The second application of DES authentication is the most important: 
a more secure Network File System.
There are three security problems with the 
old NFS using UNIX authentication.
The first is that verification of credentials occurs only at mount time
when the client gets from the server a piece of information
that is its key to all further requests: the
.I "file handle" .
Security can be broken if one can figure out a file handle
without contacting the server, perhaps by tapping into the net or by guessing.
After an NFS file system has been mounted,