a very, early view; but pls comment on any non-editorial issues thks, Fred

Fred Glover <fglover@decvax.dec.com> Wed, 05 February 1992 05:10 UTC

Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa05830; 5 Feb 92 0:10 EST
Received: from wdl1.wdl.loral.com by NRI.NRI.Reston.VA.US id aa05824; 5 Feb 92 0:10 EST
Received: by wdl1.wdl.loral.com (5.61+++/WDL-3.08) id AA00602; Tue, 4 Feb 92 20:21:32 -0800
Received: from decvax.dec.com by wdl1.wdl.loral.com (5.61+++/WDL-3.08) id AA00565; Tue, 4 Feb 92 20:20:44 -0800
Received: by decvax.dec.com (5.57/decvax-27Nov90) id AA12413; Tue, 4 Feb 92 23:21:02 -0500
Received: by abyss.zk3.dec.com (5.57/DEC-USSG-ZK3-ULTRIX-09/27/91); id AA04680; Tue, 4 Feb 92 23:20:59 -0500
Date: Tue, 04 Feb 1992 23:20:59 -0500
From: Fred Glover <fglover@decvax.dec.com>
Message-Id: <9202050420.AA04680@abyss.zk3.dec.com>
To: tnfs@wdl1.wdl.loral.com
Subject: a very, early view; but pls comment on any non-editorial issues thks, Fred
Sender: tnfs-request@wdl1.wdl.loral.com

==================================================================
>>> Submissions to the tnfs list: tnfs@wdl1.wdl.loral.com
>>> Additions/deletions/questions: tnfs-request@wdl1.wdl.loral.com
>>> Archive Server: archive-server@wdl1.wdl.loral.com
==================================================================







        Request for Comments On A Specification of            |
          Trusted NFS (TNFS) Protocol Extensions



1.  Status Of This Memo

This draft document specifies extensions  to  RFC  1094  [1]
which  support  network  file  access in a multilevel secure
(MLS) network environment[1].  This draft  was  approved  by
the  Trusted  Systems  Interoperability  Group (TSIG), whose
charter is to promote multi-vendor trusted system interoper-
ability.

2.  Abstract

Additional functionality has been developed for  UNIXr  sys-
tems  to address the TCSEC [2] requirements for trusted sys-
tems.  New  requirements  are  driving  efforts  to  develop
interoperable, networked solutions for trusted UNIX environ-
ments.   A  specific  approach  for  addressing  TCSEC   MLS
requirements  is identified in the CMW requirements document
[3].  Developing support for network interoperability  among
MLS classified systems is a primary goal of the trusted UNIX
community.

Sun Microsystem's Network File System (NFS- ) V2 protocol is
an  industry (de facto) standard network file access mechan-
ism, and represents one of  the  key  components  of  system
interoperability in the current UNIX networking market. This
draft document describes extensions to the NFS  V2  protocol
which  support network file access in a MLS network environ-
ment.  It will be submitted to the RFC editor as a  protocol
specification. Distribution of this draft document is unlim-
ited.  Please send comments to the  author  at  the  address
identified in section 6 below.

3.  MLS Extensions for NFS

MLS  functionality  includes  discretionary  access  control
(DAC),  subject  and  object  security  labeling,  mandatory
access control (MAC), authentication, auditing, and documen-
tation.  Exchanging information between MLS systems requires
communicating additional security information along with the
actual data.
_________________________

  [1] Multilevel Secure systems include,  for  example,
support for B1 and CMW security policies.
  r UNIX is a registered trademark of UNIX Systems  La-
boratories (U.S.L.)

  - NFS is a trademark of Sun Microsystems, Incorporat-
ed



TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY        [Page 1]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


The primary goal of this specification is to describe exten-
sions  to  the  NFS  V2  protocol which support network file
access between MLS systems with  a  minimal  impact  on  the
existing NFS V2 environment[2].  It is  also  intended  that
this  MLS environment will permit unmodified NFS clients and
servers to continue to be fully supported.

The general approach used in extending the NFS  V2  protocol
is  to  transport  additional user context in the form of an
extended NFS UNIX style credential  between  a  Trusted  NFS
(TNFS)  client  and server, and to map that context into the
appropriate server  security  policies  which  address  file
access.   In addition, security file attributes are returned
with each NFS (TNFS) procedure call.  Otherwise, the NFS  V2
protocol remains essentially unchanged.

Two companion documents [4][5] complete the set of  documen-
tation describing the TNFS environment.

3.1.  The Extended User Context

The Sun RPC  protocol  [6][7]  includes  two  authentication
parameters in a request message:

     an authentication credential  -  used  to  identify  or
     present  a  client  subject's  credentials  to a server
     along with a given request for access  or  information,
     and

     an authentication  verifier  -  used  to  validate  the
     subject's credentials,

and an authentication verifier in the RPC response message.

An NFS server uses the client subject's credentials to  per-
form  appropriate  access  checks  prior  to  servicing  the
request.  The verifier parameter in the RPC request  message
is used to authenticate the client subject's credentials[3].

Several styles of authentication are currently  defined  for
NFS[4], and an NFS server  may  elect  to  support  multiple
authentication  styles  concurrently.  A new RPC authentica-
tion style,  AUTH_MLS,  is  defined  for  use  in  the  TNFS
_________________________

  [2] Revisions to the NFS V2 protocol have been speci-
fied  and  presented  for comment to the NFS community;
this document addresses extensions to the  V2  protocol
only.
  [3] Authentication  of  client  and server identities
will not be addressed in this specification.

  [4] Styles    currently    defined   are   AUTH_NONE,
AUTH_UNIX, AUTH_SHORT, and AUTH_DES.



TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY        [Page 2]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


environment. The definition of the AUTH_MLS credential  com-
bines  the  information  in  the  AUTH_UNIX  credential with
extensions for the additional security attributes:

     o    audit id - immutable  subject  (user)  identifier,
          not  affected  by modifications to either the real
          or effective user or group identifiers,

     o    sensitivity label - used with a MAC policy; a sub-
          ject  generally has a static, top-level clearance,
          but is permitted to execute processes at a  sensi-
          tivity  level  different  from  (i.e.  lower than)
          his/her actual clearance,

     o    information label - also used with a  MAC  policy;
          dynamically  adjusted  based  upon the information
          content associated with the subject (or object),

     o    integrity label -  used  with  commercial,  multi-
          party  security policy (eg. Clark-Wilson [8], Biba
          [9]),

     o    privilege mask - used to identify privileges  (eg.
          chown,  chmod) or "rights" granted to a given sub-
          ject, generally to override an  existing  security
          policy, and

     o    vendor label -  used  to  accommodate  additional,
          vendor specific policies

The  additional  security  attributes   will   actually   be
represented  within  the  AUTH_MLS  credential by fixed size
tokens,  which  can  support  multiple  translation  schemes
through the use of an appropriate translation mechanism [5].
For instance, mechanisms such  as  M.I.T.  Project  Athena's
Hesiod/BIND or Sun Microsystem's NIS[5] lookup service could
be  used  to  support the translation of tokens and security
attribute information.

There are several advantages to the use of a token  transla-
tion model.  One major advantage is that the actual security
attribute information may be defined within the  translation
service,  while  the attribute representation may be defined
by a small, fixed sized token within  the  relatively  small
amount  of unallocated space in the credential structure.  A
second advantage of a  translation  model  is  that  it  may
accommodate  multiple  security  policies  and translations.
Finally, a token translation model permits security policies
to  be  developed independently from the translation mechan-
ism. Tokens are transferred within the  AUTH_MLS  credential
_________________________

  [5] Network Information Service, known previously  as
the Yellow Pages Service



TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY        [Page 3]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


as opaque objects which are given context  by  the  security
policy  mechanisms  implemented  by  the  TNFS  clients  and
servers.

Note that although tokens are  defined  as  opaque  objects,
tokens which represent the same security attribute and which
reside within the same translation scheme  may  be  compared
for equality.  This characteristic permits tokens represent-
ing a specific security attribute to be referenced  in  com-
parisons without requiring the tokens to be translated.

3.2.  Discretionary Access Control

A Discretionary Access Control (DAC) policy provides for the
restriction  of subject access to objects based on the iden-
tity of subjects  and/or  the  groups  for  which  they  are
members.   Most  secure  systems  address  DAC  requirements
through the use of access control  lists.   Associated  with
each  file  is  a  list which identifies the set of user and
group combinations authorized to access the file, along with
the access privileges associated with each combination.

The information contained in the AUTH_MLS  credential  of  a
TNFS  client  request includes user and group identification
sufficient to permit the server  to  apply  appropriate  DAC
policies  in  controlling  access  to its shared, local file
objects.  For example, the subject represented by  the  user
and/or group identifiers contained in the client request may
be checked against the access control list information asso-
ciated  with  the referenced file on the server. Access con-
trol list information is not required to be transmitted from
the client to the server in support of a server based access
control policy.  Client based support for access control  of
server  based file objects is discussed below in the section
which describes the extended attribute cache.

3.3.  Mandatory Access Control

A Mandatory Access Control (MAC)  policy  provides  for  the
restriction of subject access to objects based on the sensi-
tivity of the information contained  in  the  objects.   MAC
policies thus include assigning levels of trust or clearance
to system users (subjects), and  levels  of  sensitivity  to
system  objects, and then ensuring that only users with suf-
ficient clearance can access the classified information.

3.3.1.  Sensitivity Labels

When MAC policies  are  enabled,  each  system  subject  and
object  is  created with a sensitivity label, and the system
MAC policies compare the labels when determining access.

The  AUTH_MLS  credential  contains  the  sensitivity  label
information   associated   with   the  TNFS  client  subject



TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY        [Page 4]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


(application) making the access request.   This  information
is sufficient to permit the MAC policy checking mechanism on
the server to determine whether  to  permit  access  to  the
requested object or information.

3.3.2.  Information Labels

Information labels represent the  actual  sensitivity  of  a
given subject or object, and permit the additional identifi-
cation of control markings for a given piece of information.
The  information  label is dynamically adjusted on both sub-
jects and objects to the highest sensitivity level reflected
by  a  subject/object  pair:  if  a  subject  issues a write
request to an object, the information label  of  the  object
will  be adjusted (if necessary) to the level defined by the
information label of the subject;  if  a  subject  issues  a
read request to an object, the information label of the sub-
ject will be adjusted to the level defined by  the  informa-
tion  label of the object.  Note that information labels are
adjusted upwards as a result of these  actions;  information
labels are never automatically adjusted to a lower level.

The AUTH_MLS credential in the RPC request message  contains
the  current information label associated with a TNFS client
application (subject), and permits a  remote  file's  object
information  label to be adjusted (if necessary) as a result
of a client generated write operation.  The TNFS reply  mes-
sage  includes  a field for the information label associated
with an  accessed  file  object,  permitting  the  subject's
information  label to be adjusted (if necessary) as a result
of a client generated read operation.

These extensions are sufficient to support the MAC  informa-
tion label policies with respect to network file access.

3.3.3.  Privilege

The TCSEC notion of appropriate  privilege  is  an  integral
part  of  the MLS environment. It is expected that a subject
with appropriate privilege will want to gain access  to  the
additional  file  attribute  information for the purposes of
modification and/or viewing of  that  information.   Subject
privileges are defined within the AUTH_MLS credential.

Note, however, that the privileges associated with  a  given
subject  on a given client system may not be extended to the
subject on a given  server.   Although  most  subjects  will
likely  retain  their  privileges  on  the  server, a client
administrator, for example, may not be  granted  administra-
tive privileges on the server.                                |

3.3.4.  File Name Attributes                                  |

UNIX file names may vary in length from 1 to 255 characters,  |



TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY        [Page 5]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


and  represent  an  additional  data storage mechanism which  |
must be protected by appropriate  MLS  policies.  Generally,  |
the  contents  of  a file may be classified, but the name of  |
the file or knowledge of its  existence  is  not.   In  some  |
cases, however, the name of the file as well as its contents  |
may require classification  and  protection.   For  example,  |
consider the following file name:                             |

          codeword.SAND_AIRDEF.is.the.TOP-  |
          SECRET.DESERT_STORM.air.defense.project             |

The association of sensitivity and information  labels  with  |
directory  file  name entries provides the support necessary  |
to protect the use of classified file names.

3.4.  Additional MLS Extensions for NFS

In an MLS environment, both DAC and MAC access control poli-
cies  are  applied  in determining access to a given object.
In a network environment of  MLS  systems  participating  in
TNFS  file  access,  the  AUTH_MLS credential permits a TNFS
server to apply both DAC and MAC policies  in  consideration
of  a  request  from a remote NFS client subject.  Thus, MLS
based network file access using the NFS V2 protocol  can  be
supported  through  the  use  of  the AUTH_MLS credential as
described.

Listing or modifying the DAC and MAC security attributes  of  |
a  server's  file  or  file  name  from  a  client, however,
requires additional protocol extensions.  Identifying  addi-
tional  security  access restrictions when a request is made
to open a remote file is also considered to  be  a  require-
ment.  Extensions designed to satisfy these requirements are
addressed by TNFS, and are described  in  the  next  subsec-
tions.

3.4.1.  Remote Access to Extended File Attributes


The DAC and MAC security attribute information includes  MAC
and  information labels, and access control list information
(ACLs).  Supporting remote access  to  this  information  is
more difficult to address in the network environment, since:

     o    it requires transmitting additional file  security
          attribute   information  (or  its  representation)
          "over the wire", and

     o    additional file attribute  information  cannot  be
          accommodated  in the existing NFS V2 protocol file
          attribute data structures; additional support  for
          setting  and  getting the extended security attri-
          butes is required




TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY        [Page 6]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


Thus, extensions to the NFS V2 protocol procedures have been  |
defined  to  support  access  to  the extended attributes of  |
served files and file names. The complete set of NFS  proto-
col  procedures  and  security extensions are referred to in
this document as the TNFS protocol.

3.4.2.  File Open Enhancement

Using the NFS V2 protocol, a client request to  open  (2)  a
remote  file  on  the server may be translated by the client
into a GETATTR procedure call for the current  directory[6],
followed  by  a  LOOKUP  procedure  call  for the file to be
opened. If valid responses from these  procedure  calls  are
returned,  the client's NFS file attribute cache is updated,
and an open file descriptor may be returned to the  request-
ing application.

Since the NFS V2 protocol does not transmit an  actual  open
request  to  the  server, however, an MLS server will not be
able to apply the appropriate DAC and MAC policy at the time
of  the  open  request, and the application may find that it
has successfully opened the file, but that it cannot  access
the  file  due  to  stronger  access  control policies being
applied by the server in response to specific client  access
requests.

An access protocol procedure  would  permit  the  client  to
determine  whether  access to the file would be supported by
the server, based on the application's open request type and
the associated extended security attribute information.  The
ACCESS TNFS protocol procedure has been defined  to  address
this issue.

3.4.3.  File Name Enhancement                                 |

Supporting the retrieval of the additional  security  attri-  |
butes  associated  with each file name requires an extension  |
to the directory result structure returned by the NFS direc-  |
tory  procedures:  LOOKUP, CREATE, and MKDIR. This extension  |
is defined in the next section.                               |

The ability to modify  the  file  name  security  attributes  |
independently from the file data security attributes is also  |
considered to be a requirement.  A new TNFS procedure,  SET-  |
LABEL, has been defined to accommodate this issue.            |

3.4.4.  Multi-Level Directory Enhancement                     |

Directories are files which contain file names and  pointers  |
to  the file data associated with the file names.  The files  |
_________________________

  [6] Depends on the presence of  valid  attributes  in
the lookup cache (DNLC).



TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY        [Page 7]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


contained in a directory include both regular files as  well  |
as  other  subdirectory files. Directories are used to group  |
files, and to support the file system hierarchy.  Each  UNIX  |
system  user  typically  maintains a personal or home direc-  |
tory, which contains files that belong to  that  user.   The  |
UNIX  system  also  maintains a set of directories: some for  |
its own use, and some, such as the /tmp directory,  for  use  |
by all members of its user community.                         |

In an MLS environment, files  and  directories  are  labeled  |
with  specific classifications.  Security policies limit the  |
access of files to users with  appropriate  classifications.  |
MLS implementations must continue to maintain the basic file  |
system directory hierarchy, and also support the MLS  access  |
policies.   They  must  support  the  creation, storage, and  |
access of files and data of different  security  classifica-  |
tions,  and  provide  some accommodation for the use of com-  |
monly shared directories, such as /tmp and /usr/tmp.          |

Several implementation mechanisms  have  been  developed  to  |
address these issues [4].  One implementation makes use of a  |
set of diversion directories which  are  created  below  the  |
actual MultiLevel Directory (MLD).  Each divergent directory  |
is associated with a specific classification level, and user  |
access  is directed into the appropriate divergent directory  |
in a transparent, pass-through manner.  Another  implementa-  |
tion  makes  use  of  the  file name security attributes and  |
maintains each directory as an MLS directory.                 |

An important TNFS goal is  to  identify  the  protocol  pro-  |
cedures  and  extensions required to support MLS implementa-  |
tions. The addition of the file name security attributes and  |
the  TNFS  SETLABEL  procedure described previously accommo-  |
dates the MLS  MultiLevel  Directory  implementations.   The  |
TNFS  MLD  procedure  has  been  defined  to accommodate the  |
divergent MultiLevel Directory implementations.               |

3.4.5.  TNFS Protocol Extensions

Extensions to the NFS V2 protocol are defined in  this  sec-
tion of the specification.  These extensions are designed to
support remote access to the security file attribute  exten-
sions, and to support the file open enhancement.

3.4.5.1.  Data Structure Definitions

The  definitions  which  support  the  MLS  extensions   are
described  in  this  section.  Since the definitions for the
TNFS protocol are an extension of the original NFS V2 proto-
col,  this  specification  will  include all of the extended
data structure definitions, and a few of the original defin-
itions  for clarity. Note that the arguments and results are
defined using the RPC language.




TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY        [Page 8]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


The following RPC constants are used to  identify  the  TNFS
extensions  which  support  MLS security policies.  The TNFS
program will be registered as a separate  service  with  the
RPC port mapping service.[7]  Registration  as  a  different
service distinguishes the TNFS service from the original NFS
V2 service.  The use of a different version  number  distin-
guishes each request/response message.


     PROGRAM 390086  /* TNFS Program Number */
     VERSION      1  /* TNFS Version 1 */


The stat type is returned  from  every  procedure  call.   A
value  of  NFS_OK indicates the call completed successfully.
Other values indicate that an error occurred during the ser-
vicing  of  the  request.  Note: this structure is unchanged
from the NFS V2 Protocol Specification.  It  is  (partially)
reproduced here for clarity.


     stat

     enum stat {
          NFS_OK = 0,
          NFSERR_PERM = 1,
             NFSERR_NOENT = 2,
             . . .
             [other NFS errors as defined in the V2 protocol
     specification]
     };


The credential parameter is included  in  each  RPC  request
message,  and is used to supply the client subject's creden-
tials to the server.  The AUTH_MLS credential will  be  used
with the TNFS procedure calls and is defined as follows:


     #define AUTH_MLS 200000     /* decimal */

     #define MLS_TOKEN_SIZE 4    /* 4 octets or 32 bits */

     typedef opaque t_token[MLS_TOKEN_SIZE]; /*  tokens  are
     opaque */

     struct authmls_cred {
             u_long  auc_stamp;         /* arbitrary ID */
             char    auc_machname<255>; /* machine name */
_________________________

  [7] TNFS server implementations may elect to share  a
common  UDP  [13]  port number with the original NFS V2
service, or to make use of a different port number.



TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY        [Page 9]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


             u_long  auc_uid;           /* effective uid */
             u_long  auc_gid;           /* effective gid */
             u_long  auc_len;           /* len of groups list */
             u_long  auc_gids<24>;      /* groups */
             u_long  auc_aid;           /* audit id */
             t_token auc_privs;         /* privileges token */
             t_token auc_sens;          /* sensitivity token */
             t_token auc_info;          /* information token */
             t_token auc_integ;         /* integrity token */
             t_token auc_vend;          /* vendor specific policy token */
     };


     Note that if a given security attribute  is  not  being
     exchanged,  then  the  corresponding  credential  token  |
     value shall be set to "all bits on".  A given  security
     policy  may  require that only a subset of the security
     attributes  provided  for  in  this  specification   be
     exchanged.   For  example, a C2 network security policy
     requires the support  of  privileges,  and  might  also
     require  support  for  Access Control Lists (ACLs).  In
     that case, the sensitivity, information, integrity, and
     vendor  specific token values shall be set to "all bits  |
     on" in the exchange messages.


The fattr structure defines the complete set of file  attri-
butes  of  a file. The extended fattr structure combines the
NFS V2 fattr structure with additional fields for  a  file's
security    attributes.    The   security   attributes   are
represented by tokens.


     struct fattr {
             ftype   type;      /* file type */
             u_long  mode;      /* encoded access mode */
             u_long  nlink;     /* number of hard links */
             u_long  uid;       /* file's owner id */
             u_long  gid;       /* file's group id */
             u_long  size;      /* file size in bytes */
             u_long  blocksize; /* number bytes/block */
             u_long  rdev;      /* device number of the file */
             u_long  blocks;    /* current number of blocks */
             u_long  fsid;      /* file system id */
             u_long  fileid;    /* unique file identifier */
             timeval atime;     /* time of file's last access */
             timeval mtime;     /* time last modified (written) */
             timeval ctime;     /* time of last attribute change */
             t_token privs;     /* privileges token */
             t_token sens;      /* sensitivity token */
             t_token info;      /* information token */
             t_token integ;     /* integrity token */
             t_token acl;       /* access control list token */
             t_token vend;      /* vendor specific policy token */



TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY       [Page 10]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


     };


     Note that if a given security attribute  is  not  being
     exchanged,  then the corresponding file attribute token  |
     value shall be set to "all bits on".

The sattr structure defines the file attributes which can be
set  from  the client. The extended sattr structure combines
the NFS V2 sattr structure with additional  fields  for  the
security  attributes,  which  are  represented by tokens.  A
token value of "all bits on" indicates that the token  field  |
is to be ignored.


     struct sattr {
             u_long  mode;    /* encoded access mode */
             u_long  uid;     /* file's owner id */
             u_long  gid;     /* file's group id */
             u_long  size;    /* file size in bytes */
             timeval atime;   /* last access time */
             timeval mtime;   /* last data modify time */
             t_token privs;   /* privileges token */
             t_token sens;    /* sensitivity token */
             t_token info;    /* information token */
             t_token integ;   /* integrity token */
             t_token acl;     /* access control list token */
             t_token vend;    /* vendor specific policy token */
     };


The sattrargs structure is used by  the  SETATTR  procedure.
It contains the extended sattr structure definition.


     struct sattrargs {
         fhandle file;
         sattr attributes;
     };


The attrstat structure defines  a  common  procedure  result
containing the status of the procedure call.  It is returned
with the results of GETATTR, SETATTR,  and  WRITE  procedure
calls.   If  the  call was successful, attrstat contains the
results for the specific procedure called, and the  complete
set  of  file attributes for the file on which the procedure
was executed.


     union attrstat switch (stat status) {
             case NFS_OK:
                 fattr attributes;
             default:



TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY       [Page 11]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


                 void;
     };


The diropres structure defines the results  of  a  directory
procedure  call.   If the call was successful, diropres con-
tains a new file handle file and the complete set of associ-
ated file attributes.


     union diropres switch (stat status) {
             case NFS_OK:
                 struct {
                     fhandle file;
                     fattr attributes;
                     t_token sens;                            |
                     t_token info;                            |
                 } diropok;
             default:
                 void;
     };


The readlinkres structure defines the results of a  READLINK
procedure  call.   If  the  call was successful, readlinkres
contains the data in the symbolic link of the  file  identi-
fied  by  the  file handle argument, and the complete set of
associated file attributes.  File  attributes  are  returned
with  the READLINK procedure call to support the information
label adjustment policy.


     union readlinkres switch (stat status) {
             case NFS_OK:
                 struct {
                     path data;
                     fattr attributes;
                 } readlinkok;
             default:
                 void;
     };


The readdirres structure defines the results  of  a  READDIR
procedure  call.   If  the  call  was successful, readdirres
returns a variable number of directory entries, with a total
size  of up to the amount specified in the argument count of
the readdirargs structure. Each entry contains a unique file
identifier, and an opaque "pointer" to the next entry in the
directory.  The eof flag has a value of TRUE if there are no
more  directory  entries.  File attributes are returned with
the READDIR procedure call to support the information  label
adjustment policy.




TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY       [Page 12]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


     union readdirres switch (stat status) {
             case NFS_OK:
                 struct {
                     entry *entries;
                     bool eof;
                     fattr attributes;
                 } readdirok;
             default:
                 void;
     };


3.4.5.2.  TNFS Protocol Procedure Definitions

The TNFS Protocol Definition integrates the use of:

     o    the extended fattr and sattr structures,

     o    an AUTH_MLS authentication style RPC credential,

     o    a new TNFS protocol version  number  to  differen-  |
          tiate  between  NFS  V2  and the security extended  |
          TNFS protocol,

     o    a new protocol procedure, ACCESS, to  support  the  |
          file open enhancement,                              |

     o    a new protocol procedure, SETLABEL, to support the  |
          modification of the file name security attributes,  |
          and                                                 |

     o    a new protocol procedure, MLD, to  support  diver-  |
          gent MultiLevel Directories

Other than these changes, however, the syntax and  semantics
of TNFS remain the same as in the original NFS V2 specifica-
tion.

3.4.5.2.1.  Access Procedure

The following descriptions are used to define the new ACCESS
procedure.


Definitions used to identify the access request type:

     #define READ    0x001
     #define WRITE   0x002
     #define EXEC    0x004
     #define SEARCH  0x008
     #define APPEND  0x010


Arguments for the remote access procedure:



TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY       [Page 13]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


     accessargs

     struct accessargs {
             fhandle  file;
             u_long   flag;
      };


Response from the remote access procedure:

     accessres

     union accessres switch ( stat status ) {
         case NFS_OK:
             struct {
                 bool_t status;   /* access status: TRUE  or
     FALSE  */
                 fattr  attributes;  /* standard file attri-
     butes */
             }  accessok;

         default:
          void;

     };


Procedure definition for checking remote access permission:

     accessres
     NFSPROC_ACCESS(accessargs) = 18

     Description:

     Determine if access as described by flag will  be  per-
     mitted  on the remote served object file by the reques-
     ter.  Flag values are bit  encoded  as  defined  previ-
     ously.  READ  access means that the data in file can be
     read, WRITE access means that the data in file  can  be
     modified  (written), EXEC access means that file can be
     accessed and executed  (local  execution  of  a  remote
     file),  SEARCH access means that the directory file can
     be used as the argument  to  a  LOOKUP  operation,  and
     APPEND  means  that  the file size can be extended.  If
     status is NFS_OK:

          accessok.status will be set to TRUE if the  access
          request  would be allowed, and set to FALSE other-
          wise, and

          attributes will contain the complete set  of  file
          attributes

     Otherwise:



TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY       [Page 14]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


          the NFSERR error number  returned  identifies  the
          error condition

     Implementation:

     The ACCESS procedure provides a means for checking file
     access  permission prior to issuing a subsequent set of
     file operations. For example, a TNFS client  may  issue
     an  access  procedure  as  a result of an application's
     file open (2) request to determine if  subsequent  file
     reads  and/or writes by the application would be denied
     by the server as a result of the server's extended file
     access  security  policies.  Note  that the information
     returned by the server in response to  an  ACCESS  pro-
     cedure  call is not static; subsequent file administra-
     tive procedures may result in the modification  of  the
     file's security attributes.

3.4.5.2.2.  Set Label Procedure                               |

The following descriptions are used to define the new SETLA-  |
BEL procedure.                                                |


Arguments for the set label procedure:                        |

     setlabargs                                               |

     struct setlabargs {                                      |
             struct diropargs dirargs;                        |
             t_token  sens;                                   |
             t_token  info;                                   |
      };                                                      |


The results of the SETLABEL  procedure  are  returned  in  a  |
diropres  structure.  If the call succeeded, a new file han-  |
dle "file", the file "attributes" associated with that file,  |
and  the  security  attributes associated with the file name  |
are returned along with the "status".                         |


Procedure definition for setting file name  security  attri-  |
butes:                                                        |

     diropres                                                 |
     NFSPROC_SETLABEL(setlabargs) = 19                        |

     Description:                                             |

     Set the file name security attributes, the  sensitivity  |
     label sens, and the information label info, on the file  |
     name name in the parent directory dir.   If  status  is  |
     NFS_OK:                                                  |



TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY       [Page 15]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


          then the reply file and reply attributes  are  the  |
          file  handle  and  attributes for the file name in  |
          the directory given by dir in  the  argument,  and  |
          the  reply  sens and repl info are the sensitivity  |
          and information labels for the file name name.      |

     Otherwise:                                               |

          the NFSERR error number  returned  identifies  the  |
          error condition                                     |

     Implementation:                                          |

     The SETLABEL procedure provides a means  for  modifying  |
     the  file name security attributes, the sensitivity and  |
     information  labels  associated  with  the  file   name  |
     object.   When  a file is created, the file name sensi-  |
     tivity label will be set equal to the sensitivity label  |
     associated  with  the  file  data,  and the information  |
     label will be set to "SYSTEM LOW".  Once  the  file  is  |
     created,   however,  the  sensitivity  and  information  |
     labels of the file name and the  file  data  are  main-  |
     tained independently.  The file data security attribute  |
     information is maintained by SETATTR, and the file name  |
     security  attribute information is maintained by SETLA-  |
     BEL.                                                     |

3.4.5.2.3.  MLD Procedure                                     |

The following descriptions are used to define  the  new  MLD  |
procedure.                                                    |


Definitions used to identify the MLD request type:            |

     #define CREATE    0x001                                  |
     #define REMOVE    0x002                                  |
     #define ISMLD     0x004                                  |


Arguments for the MLD procedure:                              |

     mldargs                                                  |

     struct mldargs {                                         |
             fhandle  file;                                   |
             u_long   flag;                                   |
      };                                                      |


Response from the remote access procedure:                    |

     mldres                                                   |




TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY       [Page 16]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


     union mldres switch ( stat status ) {                    |
         case NFS_OK:                                         |
             struct {                                         |
                 bool_t status;   /* ISMLD status:  TRUE  or  |
     FALSE  */                                                |
                 fattr  attributes;  /* standard file attri-  |
     butes */                                                 |
             }  mldok;                                        |

         default:                                             |
          void;                                               |

     };                                                       |


Procedure definition for maintaining MultiLevel Directories:  |

     mldres                                                   |
     NFSPROC_MLD(mldargs) = 20                                |

     Description:                                             |

     Support the creation and  removal  of  divergent,  Mul-  |
     tiLevel  Directories,  and  support also the ability to  |
     determine if a given directory is an MLD.  Flag  values  |
     are bit encoded as defined previously. CREATE indicates  |
     that an MLD is to be created, REMOVE indicates that  an  |
     MLD  is  to  be destroyed.  ISMLD requests that the MLD  |
     status of the file be returned.  If status is NFS_OK:    |

          if the flag was ISMLD, then mldok.status  will  be  |
          set to TRUE if the file is a MultiLevel Directory,  |
          and set to FALSE otherwise                          |

          if the flag was not ISMLD, then  the  mldok.status  |
          flag has no meaning                                 |

          attributes will contain the complete set  of  file  |
          attributes                                          |

     Otherwise:                                               |

          the NFSERR error number  returned  identifies  the  |
          error condition                                     |

     Implementation:                                          |

     The MLD procedure  provides  the  means  for  creating,  |
     removing,  and  checking  for  the  existence of a Mul-  |
     tiLevel Directory (MLD).                                 |

3.4.5.2.4.  TNFS Service Routines

The TNFS protocol definition is defined below as  a  set  of



TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY       [Page 17]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


procedures,  arguments,  and  results.   All  modified  data
structure definitions are included  in  this  specification.
Most  NFS V2 protocol data definitions remain unchanged, and
are documented in the NFS V2  protocol  specification.   The
complete  set of TNFS protocol procedures are defined below.
The ACCESS, SETLABEL, and MLD procedures are  new,  but  the  |
other procedures are the same as those defined in the NFS V2
specification.   The  GETATTR,  SETATTR,  LOOKUP,  READLINK,
READ,  WRITE,  CREATE, MKDIR, READDIR, ACCESS, SETLABEL, and  |
MLD procedures for the TNFS protocol, however,  include  the  |
extended file attribute structure fattr in the response mes-
sage.

     program TNFS_PROGRAM {
         version TNFS_VERSION {
             void        NFSPROC_NULL (void) = 0;
             attrstat    NFSPROC_GETATTR (fhandle) = 1;
             attrstat    NFSPROC_SETATTR (sattrargs) = 2;
             diropres    NFSPROC_LOOKUP (diropargs) = 4;
             readlinkres NFSPROC_READLINK (fhandle) = 5;
             readres     NFSPROC_READ (readargs) = 6;
             attrstat    NFSPROC_WRITE (writeargs) = 8;
             diropres    NFSPROC_CREATE (createargs) = 9;
             stat        NFSPROC_REMOVE (diropargs) = 10;
             stat        NFSPROC_RENAME (renameargs) = 11;
             stat        NFSPROC_LINK (linkargs) = 12;
             stat        NFSPROC_SYMLINK (symlinkargs) = 13;
             diropres    NFSPROC_MKDIR (createargs) = 14;
             stat        NFSPROC_RMDIR (diropargs) = 15;
             readdirres  NFSPROC_READDIR (readdirargs) = 16;
             statfsres   NFSPROC_STATFS (fhandle) = 17;
             accessres   NFSPROC_ACCESS (accessargs) = 18;
          diropres    NFSPROC_SETLABEL (setlabargs) = 19;     |
             mldres      NFSPROC_MLD (mldargs) = 20;          |
         } = 1;     /* Trusted NFS Version 1  */
     } = 390086;    /* Trusted NFS Program Number */

3.4.6.  Using TNFS

With the TNFS protocol procedures described  above,  listing
and  modifying  remote  extended file attributes is now sup-
ported. The definition  of  a  new  application  programming
interface  (API) to support the display of a file's security
attributes will permit either a new file list command  (e.g.
lsacl,  lsmac) or a modification to the existing ls (2) com-
mand to display the security attribute  information  associ-
ated  with a remote file.  Likewise, the definition of a new
API for setting a file's security attributes will permit new
change  security  attribute  commands  to be developed (e.g.
chacl, chmac).

The file open enhancement discussed previously  may  now  be
supported.   The  open API will be translated into a GETATTR
operation for the current directory, a LOOKUP operation  for



TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY       [Page 18]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


the file to be opened, and an ACCESS operation which returns
a boolean value  indicating  whether  the  access  requested
would  be  permitted,  along  with  the  complete set of the
file's attributes.  Thus,  the  TNFS  client  can  determine
whether  the  application requesting to open the remote file
will be able to access it based on the open request type and
the  application's  security credentials.  As described ear-
lier, a server may choose to associate a set  of  privileges
with  the  remote  subject  which  are  different  from  the
privilege set associated with the subject on the client sys-
tem.  The ACCESS procedure call returns the server's assess-
ment of the subject's access capabilities.

The information label adjustment policy is supported,  since  |
the  AUTH_MLS  credential contains the subject's information
label, and the TNFS reply message contains an extended  file
attribute  structure which includes the file object's infor-
mation label.  Note that the subject's information label may
require  adjustment  as  a  result  of reading a remote file
(READ), reading a remote directory (READDIR), or  reading  a
remote  symbolic  link (READLINK).  A remote file's (object)
information label may be adjusted as a  result  of  SETATTR,
WRITE,  CREATE,  RENAME,  LINK, SYMLINK, and MKDIR TNFS pro-
cedure calls.                                                 |

File Name security attributes are supported.  TBD.            |

MLS and divergent,  MultiLevel  Directories  are  supported.  |
TBD.

3.4.7.  TNFS Access Control Policy

The access control policy recommended by this  proposal  may
be stated as follows:

     o    a client system shall always apply the access con-
          trol  policy  to  a  local request for access to a
          local resource,

     o    a server system shall always apply the access con-
          trol  policy  to  a  local request for access to a
          local resource,

     o    a server system shall always apply the access con-
          trol policy to a remote access request for a local
          resource, and

     o    a client system may (temporarily) apply the access
          control   policy   to   a  locally  cached  remote
          resource, iff:

          *    client security attribute caching support  is
               included in the implementation, and




TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY       [Page 19]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


          *    a client security attribute caching policy is
               enabled by the host security officer

This TNFS access control policy ensures that no access  will
be  made  without the application of appropriate access con-
trol.

3.4.8.  TNFS Auditing Policy

The auditing policy recommended by this proposal  is  stated  |
as follows. When the security auditing function is enabled:

     o    an implementation shall:                            |

          (1)  audit  all  local  requests  for  local  file  |
               access:

               >    a client system  shall  always  audit  a
                    local  request  for  access  to  a local
                    resource,

               >    a server system  shall  always  audit  a
                    local  request  for  access  to  a local
                    resource

          (2)  provide the capability to  audit  all  remote  |
               file access requests:

               >    the client shall support the  capability
                    to  audit  local  requests for access to
                    remote resources on a server, and

               >    the server shall support the  capability
                    to  audit  remote requests for access to
                    local resources on the server[8]

          (3)  enable  client  system  auditing   of   local  |
               requests   for  access  to  remote  files  by  |
               default

Thus, when the security auditing function is enabled:

     o    all local requests for access to local  files  are  |
          audited,

     o    client system requests for access to remote  files  |
          are audited[9]                                      |
_________________________

  [8] This option  may  require  the  auditing  of  the
specific  TNFS protocol procedure calls, since the pro-
tocol procedures are not translated into actual "system
calls" in many server implementations.
  [9] This  is the default policy; site specific audit-



TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY       [Page 20]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


     o    the capability to audit remote file access by both  |
          client and server is provided:

          *    client system  auditing  may  be  enabled  to  |
               audit  local  requests  for  access to remote  |
               resources; client system auditing is  enabled  |
               by default,

          *    server system  auditing  may  be  enabled  to  |
               audit  remote  requests  for  access to local  |
               resources

     o    enabling of the remote file access auditing  capa-
          bility  shall  be supported by a system management
          operation

This TNFS policy ensures that each  TNFS  host  shall  audit  |
local  requests for local file access, each TNFS client sys-  |
tem  shall  audit  requests  for  remote  file  access   (by  |
default),  and  both TNFS clients and servers shall have the  |
cability to enable auditing of remote file access  activity.
In  a  given  network  environment,  it  may be desirable to
optionally disable auditing of remote access on  either  the
client or the server to avoid duplication.

3.4.9.  The Extended Attribute Cache

NFS caching strategies are implementation specific, and  are
not  part of the NFS protocol.  Caching is also not required
to support TNFS interoperability.  This  specification  will
therefore  not  include  specific  details  on  the issue of
attribute caching.  However, since  the  caching  mechanisms
are  included in the NFS reference source code releases, and
since attribute caching is critical for achieving  NFS  per-
formance  goals,  several  suggestions  are included in this
section.

In most NFS client implementations, remote  file  attributes
are cached on the client, improving performance and reducing
network traffic.  The attribute cache is updated frequently,
as  most  NFS  procedures  return file attributes along with
other requested information.

A client side cache for the extended  security  file  attri-
butes  should also be considered for similar reasons.  Since
all of the file's security attributes are returned with each
TNFS  file  access  request,  an extended security attribute
cache can now be maintained on the client.

Extending the  attribute  validation  procedure  to  include
_________________________
ing policies are established by the site security  off-
icer.




TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY       [Page 21]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


validating the security file attributes permits the complete
set  of  file attributes to be checked and refreshed if they
are no longer valid.  If the file's  cached  attributes  are
not  valid,  a GETATTR procedure call can be made.  The TNFS
reply to this procedure now includes  the  complete  set  of
file  attribute  information,  permitting  all of the file's
cached attributes to be refreshed.  Cached attribute entries
shall be aged and eventually flushed unless refreshed.

Note again that an attribute caching policy is not  part  of
the  protocol,  and  is  an implementation technique used to
improve performance.  During the window  of  time  that  the
cache  entry  is  valid,  the  client system applies the MLS
access control policies on  behalf  of  the  server.  It  is
recommended  that  if  an implementation supports the use of
client side attribute  caching,  it  shall  also  support  a
mechanism  for  disabling  the  attribute cache.  Additional
implementation details are provided in [4].

4.  Related Requirements and Expectations

This specification addresses extensions the NFS V2  protocol
which accommodate network file access in a trusted, MLS net-
work environment.   Expectations  for  the  environment  for
which this specification is applicable include:

     o    the TNFS network environment is a trusted environ-
          ment:

          >    TNFS  authentication  and  message  integrity
               support shall not be required

          >    use of TNFS in an untrusted environment (i.e.
               commercial   network   environment)   is  not
               addressed by this specification

     o    other, related RPC services are required  to  sup-
          port  the  execution  of NFS; these services shall
          support the AUTH_MLS credential  flavor,  but  may
          also  support  alternative policies which make use
          of other authentication flavors:

          >    the token management service is  required  to
               translate    security    attributes   between
               expanded and tokenized formats [5],

          >    the mount service is required to support  NFS
               mount requests,

          >    the lock manager and status monitor  services
               are  required  to  support  NFS file and file
               region locking

     o    client side mounts  shall  be  restricted  to  the



TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY       [Page 22]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


          server's exported mount points:

          >    client requests to mount a subdirectory which
               resides   below   the  export  point  in  the
               server's exported directory shall be denied,

          >    without this restriction,  client  access  to
               server   files  mounted  below  the  server's
               export point bypass the authorization  checks
               which  would  otherwise  have been made using
               the  access  modes  of  the  file  components
               located   higher  in  the  server's  exported
               tree[10]

     o    most file access will take place between MLS modi-
          fied  clients  and  servers, but some TNFS systems
          will continue to interoperate with NFS V2  systems
          through  the  use  of  an  appropriate policy; for
          example, a  filter  or  gateway  could  be  placed
          between  a  MLS system and an unmodified system to
          insert or delete  appropriate  security  attribute
          information on behalf of the unmodified system

     o    a  TNFS  client  should  not  send  any   security
          extended  NFS  procedure  calls  to a server which
          does not  support  this  service;  a  TNFS  client
          should  also refrain from sending extraneous secu-
          rity attribute information to a TNFS  server  that
          does not support those attributes

     o    additional TCB information[11]  is  maintained  by
          each  MLS system to support trusted interoperabil-
          ity [10]; for example, each MLS host may:

          >    maintain a list of the hosts  which  it  will
               communicate with,

          >    maintain the set of security attributes which
               it  expects  to  use  in the exchange of data
               with a given host, and

          >    maintain the specific translation  scheme  or
               schemes  which  will  be  used in translating
               tokens with a given host [5]
_________________________

  [10] Note that appropriate use of symbolic  links  on
the  client  will  result  in  a client file name space
similar to one previously constructed by mounting  sub-
directories of exported server file trees.
  [11] Note that this  information  is  needed  by  all
trusted network applications, and is not limited to NFS
file access.




TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY       [Page 23]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


     o    the  security  information  defined   within   the
          AUTH_MLS  credential and file attribute structures
          provides for the transfer of  security  attributes
          required  to  support  MLS access policies without
          requiring the underlying network layer to  provide
          security attribute information:

          >    if security attributes are provided  by  both
               the  RPC  layer  and  the  underlying network
               layer, then the security  attribute  informa-
               tion  provided  by  the  RPC  layer  shall be
               applied to the file data  transferred  within
               the RPC message

          >    transferring security attributes  within  the
               RPC  layer provides for the support of a pol-
               icy where data  may  be  transferred  with  a
               security  classification  which  is different
               from the security classification of the  net-
               work  layer;  for  instance, file data with a
               given security classification might first  be
               encrypted and then transferred through a net-
               work with a lower security classification.

          >    support for the transfer of  MAC  sensitivity
               labels  for  the  Internet Protocol Suite has
               been addressed by the CIPSO [11],  and  RIPSO
               [12] documents

5.  Conclusion

This document describes the set of extensions which  support
network  file  access in a network environment consisting of
MLS systems using the  proposed  TNFS  protocol  extensions.
Unmodified  NFS  clients and servers are supported using the
de facto NFS V2 protocol.

With the previously defined extensions, the MLS network file
access requirements are met.  The extended structure defini-
tions support the DAC and MAC attributes required for  modi-
fying  or displaying the security attribute information. The
enhanced file  open  operation  and  the  information  label
adjustment policies are also supported.

Thus, a small set of extensions to the  NFS  V2  environment
permits MLS access control policies to be supported.  Agree-
ment on these changes will permit the current  base  of  NFS
clients  and  servers  to  be  accommodated  in  the  secure
environment with no changes, and for TNFS  modified  systems
to interoperate using MLS policies.

6.  Acknowledgements

I would like to acknowledge the members of the ITEF/TSIG NFS



TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY       [Page 24]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


Subcommittee,  who  were  instrumental  in  evolving the MLS
extended NFS Protocol Specification from the original propo-
sal.  Many  comments were also made during the review of the
later drafts which greatly improved the specification's rea-  |
dability.   Contributing  IETF  TNFS  working  group members  |
include Jeff Edelheit, Fran Fadden, Ali Gohshan, Carl Smith,  |
Mark  Saake,  Dave Summers, and Charlie Watt.  I'd also like  |
to acknowledge the contributions of the original members  of  |
the  TSIG  Trusted  NFS  working  group:  in addition to the  |
above, these members included Morgan Clark,  Tricia  Jordan,  |
Will Lees, Scott Norton, and Mike Shipley.

The specification was also reviewed by numerous persons out-
side  of the subcommittee. I would like to acknowledge these
persons as well, as a number  of  their  comments  are  also
reflected in the final version.

7.  Author's Address

Fred Glover
Digital Equipment Corporation
110 Spit Brook Road ZK03-3/U14
Nashua, New Hampshire 03062-2698

Phone: 603-881-0388

EMail: fglover@decvax.dec.com

8.  References

[1] Sun Microsystems, Inc., "Network  Filesystem  Specifica-
     tion",  RFC-1094,  DDN  Network Information Center, SRI
     International, Menlo Park, CA.

[2] National Computer Security Center, United States Depart-
     ment  of  Defense, "Trusted Computer Systems Evaluation
     Criteria" National Computer Security Center, Ft. George
     G. Meade, MD., 1985, DoD 5200.28-STD

[3] Defense Intelligence Agency, United States Department of
     Defense,  "Security  Requirements  for  System High and
     Compartmented Mode Workstations", Defense  Intelligence
     Agency,  Washington,  D.C.,  DIA  document  number DDS-
     2600-5502-87

[4] Trusted Systems Interoperability  Group,  "The  MLS  NFS
     Implementor's Guide", TSIG Document

[5] Trusted Systems Interoperability Group, "The  MLS  Token
     Translation Specification", TSIG Document

[6] Sun Microsystems, Inc., "Remote Procedure Call  Specifi-
     cation",  RFC-1057, DDN Network Information Center, SRI
     International, Menlo Park, CA.



TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY       [Page 25]





INTERNET-DRAFT  TNFS Protocol Specification February 3, 1992


[7] Sun Microsystems, Inc.,  "External  Data  Representation
     Specification",   RFC-1014,   DDN  Network  Information
     Center, SRI International, Menlo Park, CA.

[8] Clark, D. D. and David R. Wilson, "A Comparison of  Com-
     mercial   and  Military  Computer  Security  Policies",
     Proceedings of the 1987 IEEE Symposium on Security  and
     Privacy, IEEE Computer Society Press, Washington, DC.

[9] Biba, K. J., "Integrity Considerations for  Secure  Com-
     puter Systems", TR-76-372, Electronic Systems Division,
     Air Force Systems Command, U.S. Department of  the  Air
     Force, Hanscomb AFB, MA., April 1977

[10]  Trusted  Systems  Interoperability   Group,   "Trusted
     Administration Specification", TSIG Document

[11] Trusted Systems Interoperability Group, "Commercial  IP
     Security Option", TSIG Document

[12] "The Revised IP Security Option",  RFC-1038,  RFC-1108,
     DDN  Network  Information  Center,  SRI  International,
     Menlo Park, CA.

[13] Postel, J.,  "User  Datagram  Protocol",  RFC-768,  DDN
     Network  Information  Center,  SRI International, Menlo
     Park, CA.






























TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY       [Page 26]