openldap/doc/drafts/draft-ietf-ldapext-acl-model-xx.txt

          Internet-Draft                                     E. Stokes
          LDAP Extensions WG                                  D. Byrne
          Intended Category: Standards Track                       IBM
          Expires: 10 September 2000                        B. Blakley
                                                                Dascom
                                                         10 March 2000

                         Access Control Model for LDAP
                     <draft-ietf-ldapext-acl-model-05.txt>

          STATUS OF THIS MEMO

             This document is an Internet-Draft and is in full
             conformance with all provisions of Section 10 of RFC2026.

             Internet-Drafts are working documents of the Internet
             Engineering Task Force (IETF), its areas, and its working
             groups. Note that other groups may also distribute
             working documents as Internet-Drafts. Internet-Drafts are
             draft documents valid for a maximum of six months and may
             be updated, replaced, or obsoleted by other documents at
             any time. It is inappropriate to use Internet-Drafts as
             reference material or to cite them other than as "work in
             progress."

             The list of current Internet-Drafts can be accessed at
             http://www.ietf.org/ietf/1id-abstracts.txt

             The list of Internet-Draft Shadow Directories can be
             accessed at http://www.ietf.org/shadow.html.

             Comments and suggestions on this document are encouraged.
             Comments on this document should be sent to the  LDAPEXT
             working group discussion list:

                    ietf-ldapext@netscape.com

          COPYRIGHT NOTICE
             Copyright (C) The Internet Society (1997).  All Rights
             Reserved.

          ABSTRACT

             This document describes the access control model for the
             Lightweight Directory Application Protocol (LDAP)



          Stokes, Byrne, Blakley   Expires 10 September 2000        [Page 1]






          Internet-Draft      Access Control Model       10 March 2000



             directory service. It includes a description of the
             model, the LDAP controls, and the extended operations to
             the LDAP protocol.  The current LDAP APIs are sufficient
             for most access control operations.  An API (in a
             separate document) is needed for the extended operation
             getEffectiveAccess and specifyCredentials.

             The keywords "MUST", "SHOULD", and "MAY" used in this
             document are to be interpreted as described in
             [Bradner97].



          1.  Introduction

             The ability to securely access (replicate and distribute)
             directory information throughout the network is necessary
             for successful deployment.  LDAP's acceptance as an
             access protocol for directory information is driving the
             need to provide an access control model definition for
             LDAP directory content among servers within an enterprise
             and the Internet.  Currently LDAP does not define an
             access control model, but one is needed to ensure
             consistent secure access across heterogeneous LDAP
             implementations. The major objective is to provide a
             simple, but secure, highly efficient access control model
             for LDAP while also providing the appropriate flexibility
             to meet the needs of both the Internet and enterprise
             environments and policies.  This document defines the
             model and the protocol extensions (controls and extended
             operations).


          2.  Overview

             Access Control mechanisms evaluate requests for access to
             protected resources and make decisions about whether
             those requests should be granted or denied.  In order to
             make a grant/deny decision about a request for access to
             a protected resource, an access control mechanism needs
             to evaluate policy data.  This policy data describes
             security-relevant characteristics of the requesting
             subject and the rules which govern the use of the target
             object.




          Stokes, Byrne, Blakley   Expires 10 September 2000        [Page 2]






          Internet-Draft      Access Control Model       10 March 2000



             The access control model defines

                - A wire protocol for interoperability:  The existing
                  LDAP protocol flows for add, delete, modify, and
                  search are used to manipulate access control
                  information.  There is an additional LDAP control
                  and extended protocol operation defined,
                  getEffectiveRights, to further help management of
                  access control information.

                - A set of access control information (ACI) attributes
                  for application portability:  These attributes are
                  used as input to the LDAP APIs so access control
                  information can be addressed uniformly independent
                  of how that information is addressed and stored at
                  the server. These same attributes appear in LDIF
                  output for interchange of access control
                  information.

                - A set of attributes to identity the access control
                  mechanisms supported by a server and in a given part
                  of the namespace.

             Encoding of access control information on the wire is per
             the LDAPv3 specifications.

             The instantiation of an access control model at the
             directory server is not defined in this document.

             No mechanisms are defined in this document to control
             access to access control information or for storage of
             access control information at the server; this is vendor
             dependent.

             A separate requirements document for access control
             exists.  The access control model used the requirements
             documents as a guideline for the development of this
             specification and are reflected in this specification to
             the extent that the working group could agree on an
             access control model.








          Stokes, Byrne, Blakley   Expires 10 September 2000        [Page 3]






          Internet-Draft      Access Control Model       10 March 2000



          3.  Terminology

             An "access control list" contains the access control
             policy information controlling access to an object or
             collection of objects.  An access control list consists
             of a set of access control list entries.

             An "access control list entry" defines a single subject
             security attribute's granted rights for the objects
             governed by the access control list to which it belongs.

             The "access control information" (aci) for an object or a
             collection of objects defines which subject security
             attributes entitle a subject to which granted rights.
             The access control information for an object may be
             stored in an access control list.

             An "access decision" is a boolean-valued function which
             answers the question: "can the subject with these subject
             security attributes perform this operation on this
             object?"

             An "access decision function" is an algorithm which makes
             an access decision based on subject security attributes,
             access control information, an object identifier, and an
             operation name (possibly augmented by additional
             contextual information).

             An "access decision function interface" is a programmatic
             interface through which applications can request an
             access decision.

             An "access identity" is an identity which is used by an
             access decision function to make an access decision.

             An "audit identity" is an identity which does not, in the
             absence of additional information, enable a party
             receiving and examining it to determine which subject it
             belongs to.

             A "credential" is a collection of subject security
             attributes.

             "effective rights" are the complete set of rights a
             subject is entitled to based on all access control lists



          Stokes, Byrne, Blakley   Expires 10 September 2000        [Page 4]






          Internet-Draft      Access Control Model       10 March 2000



             which apply to a specific object and based on all of the
             subject's security attributes.

             "granted rights" are the complete set of rights an access
             control list entitles a subject to based on a specific
             subject security attribute.

             A "group" is a privilege attribute asserting a subject's
             membership in the collection of subjects whose name is
             that of the group.

             An "identity" is a subject security attribute which is
             unique to a single subject.

             A "privilege attribute" is a subject security attribute
             which may be shared by several subjects.

             "required rights" are the complete set of rights needed
             to authorize a requester to perform a specific operation
             on an object of a specific type.

             A "right" is the basic unit of access control
             administration.  For each object type in an information
             system, a security administrator defines a set of
             required rights for each operation.  For each object in
             the system, a security administrator defines a set of
             granted rights for each subject security attribute.  When
             an access decision is required, an access decision
             function checks to make sure that the requester's subject
             security attributes have been granted all required rights
             needed to perform the requested operation on the
             specified target object.

             A "role" is a privilege attribute asserting a subject's
             organizational position and entitlement to perform the
             operations appropriate to that organizational position.

             A "subject' is an entity which initiate actions in an
             information system.

             A "subject security attribute" is a defined property
             which is used by a security policy evaluation system to
             make policy decisions.





          Stokes, Byrne, Blakley   Expires 10 September 2000        [Page 5]






          Internet-Draft      Access Control Model       10 March 2000



          4.  The Model

             The access control mechanism described in this draft
             addresses these activities:

                - Definition of subject security attributes
                  information

                - Definition of access control policy

                - Retrieval of subject security attributes

                - Retrieval of effective access rights

                - Externalization of access control policy information

          4.1  Access Control Information Model

             This document does not define formats for storage of
             access control information; it does define the
             operational semantics of access control operations.



























          Stokes, Byrne, Blakley   Expires 10 September 2000        [Page 6]






          Internet-Draft      Access Control Model       10 March 2000



             The diagram below illustrates the componentry of a LDAP
             system and the placement of the function specified in
             this draft.

                   +-------------+
                   | Application |<--attrs to address ACI
                   +-------------+    - ldapACI
                     +--------+       - policyOwner
                     | LDAP   |
                     | Client |
                     +--------+
                         |
                         | <-- LDAP control
                         |       - getEffectiveAccess
                         |
                         | <-- LDAP extended operation
                         |       - getEffectiveAccess
                         v
              +-----------------------------+
              |   LDAP Server (e.g. SLAPD)  |
              +-----------------------------+
                    .               |
                    .               |
                    .               |
                    .               |
                    v               v
              +----------+   +-----------+
              | Access   |   |           |<-attrs to define
              | Control  |<--| Datastore |  access control mechanisms
              | Manager  |   |           |   - supportedACIMechanisms
              +----------+   +-----------+   - aCIMechanisms

             LDAP clients use the control and extended operation
             specified in this document to administer access control
             policy enforced by LDAP servers.  Servers may store
             access control information in any way they choose. In
             particular, servers may use the access control mechanisms
             of their datastores to store and enforce LDAP access
             control, or they may implement access control managers
             external to their datastores.  Datastores and external
             access control managers may implement any access control
             rule syntax and semantics they choose, as long as the
             semantics are compatible with that defined in the section
             titled "Operational Semantics of Access Control
             Operations".



          Stokes, Byrne, Blakley   Expires 10 September 2000        [Page 7]






          Internet-Draft      Access Control Model       10 March 2000



             The access control administration mechanisms specified in
             this document are neutral with respect to policy
             inheritance mechanisms, explicit vs.  implicit denial,
             and group nesting.


          5.  Access Control Mechanism Attributes

             There are several attributes defined associated with
             access control.  Two attributes are defined to identify
             which access control mechanisms are supported by a given
             server and by a given subtree:  supportedACIMechanisms
             and aCIMechanisms.


          5.1  Root DSE Attribute for Access Control Mechanism

             The server advertises which access control mechanisms it
             supports by inclusion of the 'supportedACIMechanisms'
             attribute in the root DSE.  This attribute is a list of
             OIDs, each of which identify an access control mechanism
             supported by the server.

              (<OID to be assigned>
                 NAME      'supportedACIMechanisms'
                 DESC      list of access control mechanisms supported
                             by this directory server
                 SYNTAX    LDAPOID
                 USAGE     dSAOperation
              )

             The access control mechanism defined is:
                  LDAPv3     <OID to be assigned>

             Other vendor access control mechanisms can be defined (by
             OID) and are the responsibility of those vendors to
             provide the definition and OID.


          5.2  Subschema Attribute for Access Control Mechanism

             A given naming context must provide information about
             which access control mechanisms are in effect for that
             portion of the namespace.  The following attribute must
             be in each subschema entry associated with a naming



          Stokes, Byrne, Blakley   Expires 10 September 2000        [Page 8]






          Internet-Draft      Access Control Model       10 March 2000



             context whose access control mechanism is different from
             adjacent naming contexts supported by that directory
             server.

             aCIMechanisms lists the values (list of OIDs) that
             defines the access control mechanism in effect for the
             scope of that subschema entry.  More than one mechanism
             may be in effect for the scope of that subschema entry.

              (<OID to be assigned>
                 NAME      'aCIMechanisms'
                 DESC      list of access control mechanisms supported
                             in this subtree
                 SYNTAX    LDAPOID
                 USAGE     dSAOperation
              )



          6.  Access Control Information Attributes


             The intent of the following attribute definitions is to
             design a common interchange format.  Any given LDAP
             server should be able to translate the below defined
             attributes into a meaningful operation requests. Each
             server should be able to understand the attributes; there
             should not be any ambiguity into what any part of the
             syntax means.

             While the end goal is to have a common behavior model
             between different LDAP server implementations, the
             attribute definition alone will not ensure identical ACL
             processing behavior between servers.  The semantics of
             how a server interprets the ACI syntax are defined in the
             "Operational Semantics of Access Control' section of this
             document.  Additionally, while the server must recognize
             and act on the attribute when received over the wire,
             there are no requirements for the server to physically
             store this attribute.

             The attribute definition maintains an assumption that the
             receiving server supports inheritance within the security
             model. If the server does not support inheritance, the
             receiving server must expand any inherited information



          Stokes, Byrne, Blakley   Expires 10 September 2000        [Page 9]






          Internet-Draft      Access Control Model       10 March 2000



             based on the scope flag.  If the server does not support
             partial inheritance and both the entry and subtree scope
             are used, then entry is the prevailing scope.

             Two attributes are defined so access control information
             (ACI) can be addressed in a server independent of server
             implementation.  These attributes are used in typical
             LDAP APIs and in LDIF output of ACI. These two attributes
             may be queried or set on all directory objects:  ldapACI
             and policyOwner.  Their BNF and definitions are defined
             below.


          6.1  The BNF

          < ldapACI > ::= < acl entry syntax >

          < acl entry syntax > ::= <familyOID> + '#' + <scope > + '#'
                             + < rights >  + '#' + < dnType >
                             + '#' + < subjectDn >

          < policyOwner > ::= < familyOid > + '#' + <scope >
                             + '#' +< dnType > + '#' + < subjectDn >

          < subjectDn > ::= < printable string > | "public" | "this"

          < familyOid > ::= < oid >

          <scope > ::= "entry"  | "subtree"

          < dnType > ::= "access-id" | "role" | "group" | "subtree"
                       | "ipAddress" | "kerberosID"
                       | <printableString>

          < kerberosID > ::= < userID > + '@' + < realm >

          < userID > ::= < printableString >

          < realm > ::= < printableString >

          < rights > ::= "grant" + ';' + <permissions> + ';'+<attr>
             | "deny" + ';' + <permissions> + ';'+<attr> |
             "grant"+';'+<permissions>+';'+"deny"+';'+<permissions>+';'+<attr>

          < permissions > ::= [ ] | [ <permission>



          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 10]






          Internet-Draft      Access Control Model       10 March 2000



                              + [ ',' + <permission> ] ]*

          < attr > ::= ["collection" + ':' + [ "[all]" | "[entry]"
                            | <printableString>] ]
                            | ["attribute" + ':' <printableString>]

          < permission > ::= "a" | "d" | "r" | "s" | "w" |
                             "c" | "e" | "b"

          These are the permissions defined for the IETF LDAP family
          OID.
               "a" corresponds to add
               "d" corresponds to delete
               "r" corresponds to read
               "s" corresponds to search
               "w" corresponds to write
               "c" corresponds to compare
               "e" corresponds to editDN
               "b" corresponds to browseDN


          6.2  Other Defined Parameters

             This section defines additional parameters that are used
             in the two attributes that address access control
             information.


          6.2.1  Families and Rights

             The familyOID tells what permission set etc. will follow
             in the string. This allows a different permission set,
             scope etc.,  but with the same syntax.

             The following family is defined:
                  IETF-LDAPv3     <OID to be assigned>

             Other families can be defined (by OID).  It is the
             responsibility of those parties to provide the definition
             and OID.


          6.2.1.1  IETF-LDAPv3 Family

             Access rights can apply to an entire object or to



          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 11]






          Internet-Draft      Access Control Model       10 March 2000



             attributes of the object.  Each of the LDAP access rights
             are discrete. One permission does not imply another
             permission.  The rights which apply to attributes and the
             entry parallel the type of ldap operations that can be
             performed.

             Rights which apply to attributes:

                r   Read     Read attribute values
                w   Write    Write attribute values
                s   Search   Search entries with specified attributes
                c   Compare  Compare attributes

             Rights that apply to an entire entry:

                a    Add      Add an entry below this entry
                d    Delete   Delete this entry
                e    EditDN   Edit an entry's DN
                b    BrowseDN Browse an entry's DN

             When searching, the ldap search filter specifies the
             returned set of attributes.  To do the search, browse (b)
             must be set for the entry (you can search only entries
             that you have permission to search so you can't discover
             things you don't have permission to) and search (s) must
             be set for all attributes used in the filter if you are
             testing for existence, otherwise search (s) and read (r)
             must be set for all attributes used in the filter because
             the filter specifies a test for other than existence.
             For a search to return attribute names only, search (s)
             must be set for the attribute.  For a search to return
             attribute names and values, search (s) and read (r) must
             be set for the attribute.  Search (s) implies knowledge
             of the attribute; read (r) implies knowledge of the
             value.


          6.2.2  DN Types

             The following DN Types strings are defined and MUST be
             supported:

                - access-id





          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 12]






          Internet-Draft      Access Control Model       10 March 2000



                - group

                - role

             The following DN Types strings are defined and SHOULD be
             supported:

                - ipAddress

                - kerberosID

             An access-id is a non-collection (non-group and non-role
             objects) DN that can be authenticated.

             groupOfNames and groupOfUniqueNames (or subclasses from
             those object classes) must be recognized as a collection
             object.  This aids in interoperability during
             replication.


             Other parties can (and will) define other DN Types.  It
             is the responsibility of those parties to provide the
             definition.

          6.3  Basic ACI Attribute (ldapACI)

              (<OID to be assigned>
                NAME      'ldapACI'
                DESC      'ldap access control information'
                EQUALITY  caseIgnoreMatch
                SYNTAX    directoryString
                USAGE     directoryOperation
              )

             Within the access control syntax, the family OID
             describes the permissions, dnType, subjectDn and scope
             that will be found in the following string. If the OID
             within the ldapACI attribute is listed as other than the
             IETF-LDAPv3 family OID, the syntax is the same, but one
             or more of the scope, dnType, subjectDn or permissions
             may vary from the defined syntax.

             Within the access control syntax, there is a string which
             describes the rights. This is a composite of the
             permissions and resources to which the subject is being



          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 13]






          Internet-Draft      Access Control Model       10 March 2000



             granted or denied access. The set of permissions is
             fixed. Either or both of the actions "grant" | "deny"
             may be used when creating or updating ldapACI.

             <attr> describes either an attribute name or an attribute
             collection.  The keyword attribute indicates that the
             following printable string refers to an attribute name.
             If the string refers to an attribute not defined in the
             given server's schema, the server SHOULD report an error.
             The keyword "collection" indicates that the string that
             follows describes a group of attributes.  The method for
             grouping attributes is server specific.  Another option
             for the collection printable string is "[entry]". This is
             provided to describe permissions which apply to an entire
             object. This could mean actions such as delete the
             object, or add a child object. The third option for a
             collection is "[all]" which means the permission set
             should apply to all attributes.  Even if the server does
             not support attribute grouping, it MUST recognize the
             "[all]" and "[entry]" keywords.  If the server receives
             an unrecognized attribute collection name, the server
             SHOULD return an error.  If the server supports grouping,
             the grouping is server and implementation specific.

             If the keyword "[all]" and another attribute are both
             specified within an aci, the more specific permission set
             for the attribute overrides the less specific permission
             set for "[all]".

             All permissions (for grant and deny) for an attribute and
             a given DN MUST be contained within one ldapACI value,
             i.e. (in abbreviated form)

              ldapACI:  ...grant attr1 DN1
              ldapACI:  ...deny attr1 DN1

             must be ldapACI:  ...grant ... deny... attr1 DN1

             Using the defined BNF it is possible for the permission
             string to be empty. The ACI

              ldapACI: 1.2.3.4#subtree#grant;;
                         attribute:attr1#group#cn=Dept XYZ,c=US

              ldapACI: 1.2.3.4#subtree#grant;r,s;



          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 14]






          Internet-Draft      Access Control Model       10 March 2000



                         collection:[all]#group#cn=Dept XYZ,c=US

             means that this group (Dept XYZ) is granted permission to
             read and search all attributes except attr1 because attr1
             is more specific than "[all]".


          6.3.1  LDAP Operations

             The attributes which are defined for access control
             interchange may be used in all LDAP operations.

             Within the ldapmodify-delete operation, the entire acl
             may be deleted by specifying

              dn: cn = some Entry
              changetype: modify
              delete: ldapACI

             In this case, the entry would then inherit its ACI from
             some other node in the tree depending on the server
             inheritance model.

             Similarly, if all values of ldapACI are deleted, then the
             access control information for that entry is defined by
             that implementation's inheritance model.


          6.3.2  Grant/Deny Evaluation Rules

             More specific policies must override less specific ones
             (e.g. individual user entry in ACI takes precedence over
             group entry).

             Deny takes precedence over Grant. When there are
             conflicting ACI values, deny takes precedence over grant.
             Deny is the default when there is no access control
             information.

             Precendence of Scope Types (highest to lowest)

                - entry

                - subtree




          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 15]






          Internet-Draft      Access Control Model       10 March 2000



             Precedence of Privilege Attribute dnTypes within a scope
             (highest to lowest):

                - ipAddress

                - access-id, kerberosID (both same precedence)

                - group

                - role

                - subtree

             Although other types can be defined given the BNF, use of
             the well-known types aids in interoperability and
             operational consistency.


          6.4  Policy Owner Attribute (policyOwner)

              (<OID to be assigned>
                 NAME      'policyOwner'
                 DESC      'Policy Owner Access Control Information'
                 EQUALITY  caseIgnoreMatch
                 SYNTAX    directoryString
                 USAGE     directoryOperation
              )

             Policy ownership controls administrative subdomains. It
             can also control who has permission to set / change acls
             for implementations that do not have ACI controlling
             access to itself.   If there are multiple policy owners
             it is implementation specific as to the behavior of
             whether policy owner #1 can override policy owner # 2.

             The syntax for policyOwner includes the 'scope' flag.
             Servers which do not support inheritance must expand the
             policyOwner inheritance similar to the expansion of the
             ACI.  The scope and any inheritance hierarchy for policy
             ownership is distinct from any inheritance hierarchy
             defined for ACI values.

             If the policy owner is not specified for any object in
             the tree, behavior is implementation defined. For
             instance, if no object anywhere in the tree has a policy



          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 16]






          Internet-Draft      Access Control Model       10 March 2000



             owner, then the server could simply assert that the 'root
             DN' is considered the policy owner for all objects. An
             alternate approach might be that the implementation
             defines the entryDN to be the policy owner.


          6.5  ACI Examples

             The examples use a family OID = 1.2.3.4


          6.5.1  Attribute Definition

             The following two examples show an administrative
             subdomain being established. The first example shows a
             single user being assigned the policyOwner for the entire
             domain. The second example shows a group of IDs assigned
             to the policy Owner.

             policyOwner: 1.2.3.4#subtree#access-id#cn=Hoyt

             policyOwner: 1.2.3.4#subtree#group#cn=System
             Owners,o=Company

             The next example shows a ldapACI attribute where a group
             "cn=Dept XYZ, c=US" is being given permissions to read,
             search and compare attribute attr1. The permission
             applies to the entire subtree below the node containing
             this ACI.

              ldapACI:1.2.3.4#subtree#grant;r,s,c;
                   attribute:attr1#group#cn=Dept XYZ,c=US

             The next example shows an ACI attribute where a role
             "cn=SysAdmins,o=Company"  is being given permissions to
             add objects below this node and read, search, and compare
             attributes attr2 and attr3. The permission applies to the
             entire subtree below the node containing this ACI.

              ldapACI: 1.2.3.4#subtree#grant;a;
                         collection:[entry]#role#cn=SysAdmins,o=Company

              ldapACI: 1.2.3.4#subtree#grant;r,s,c;
                         attribute:attr2#role#cn=SysAdmins,o=Company




          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 17]






          Internet-Draft      Access Control Model       10 March 2000



              ldapACI: 1.2.3.4#subtree#grant;r,s,c;
                 attribute:attr3#role#cn=SysAdmins,o=Company


          6.5.2  Modifying the ldapACI Values

          Modify-Replace works as defined in the ldap oepration
          modify. If the attribute value does not exist, create the
          value. If the attribute does exist, replace the value.  If
          the ldapACI value is replaced, all ldapACI values are
          replaced.

          A given ldapACI for an entry:

           ldapACI: 1.2.3.4#subtree#deny;r,w;
                      collection:[all]#group#cn=Dept ABC

           ldapACI: 1.2.3.4#subtree#grant;r;
                      attribute:attr1#group#cn=Dept XYZ

          perform the following change:

            dn: cn=someEntry
            changetype: modify
            replace: ldapACI
            ldapACI: 1.2.3.4#subtree#grant;r,w;
                       collection:[all];#group#cn=Dept LMN

          The resulting ACI is:

          ldapACI: 1.2.3.4#subtree#grant;r,w;
                     collection:[all];#group#cn=Dept LMN

          ( ldapACI values for Dept XYZ and ABC are lost through the
          replace )

          During an ldapmodify-add, if the ACI does not exist, the
          create the ACI with the specific ldapACI value(s).  If the
          ACI does exist, then add the specified values to the given
          ldapACI.  For example a given ACI:

          ldapACI: 1.2.3.4#subtree#grant;r,w;
                     collection:[all]#group#cn=Dept XYZ

          with a modification:



          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 18]






          Internet-Draft      Access Control Model       10 March 2000



            dn: cn=someEntry
            changetype: modify
            add: ldapACI
            ldapACI: 1.2.3.4#subtree#grant;r;
                   attribute:attr1#group#cn=Dept XYZ

          would yield an multi-valued aci of:

           ldapACI: 1.2.3.4#subtree#grant;r,w;
                      collection:[all]#group#cn=Dept XYZ

           ldapACI: 1.2.3.4#subtree#grant;r;
                      attribute:attr1#group#cn=Dept XYZ

          To delete a particular ACI value, use the regular ldapmodify
          - delete syntax

          Given an ACI of:

           ldapACI: 1.2.3.4#subtree#grant;r,w;
                      collection:[all]#group#cn=Dept XYZ
           ldapACI: 1.2.3.4#subtree#grant;r;
                      attribute:attr1#group#cn=Dept XYZ

            dn: cn = some Entry
            changetype: modify
            delete: ldapACI
            ldapACI: 1.2.3.4#subtree#grant;r;
                       attribute:attr1#group#cn=Dept XYZ

          would yield a remaining ACI on the server of

          ldapACI: 1.2.3.4#subtree#grant;r,w;
                     collection:[all]#group#cn=Dept XYZ


          6.5.3  Evaluation

             These examples assume that the ldapACI entries listed in
             each example are the only ACI which applies to the entry
             in question; if backing-store ACI also exists, the
             effective policy may be different from that listed in
             each example.  See section 7 for a discussion of the
             semantics of ldapACI entries when backing-store ACI
             administration is also used.



          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 19]






          Internet-Draft      Access Control Model       10 March 2000



             Assume cn=jsmith is a member of group cn=G1.  Assume
             cn=jsmith is a member of group cn=G2.

              Example #1
              dn: o=XYZ, c=US
              ldapACI: 1.2.3.4#subtree#grant;r;attribute:attr1;
                         #access-id#cn=jsmith,ou=ABC,o=XYZ,c=US
              ldapACI: 1.2.3.4#subtree#grant;w;attribute:attr1;
                         #group#cn=G1,ou=ABC,o=XYZ,c=US

              What rights does cn=jsmith have to attr1 of o=XYZ,c=US?
              Read (r) access; access-id is higher precedence than
              group.


              Example #2
              dn: o=XYZ, c=US
              ldapACI: 1.2.3.4#subtree#grant;r;attribute:attr2;
                         #group#cn=G1,ou=ABC,o=XYZ,c=US
              ldapACI: 1.2.3.4#subtree#grant;w;attribute:attr2;
                         #group#cn=G2,ou=ABC,o=XYZ,c=US

              What rights does cn=jsmith have to attr2 of o=XYZ,c=US?
              Read-write (r,w) access; ACI is combined because both
              dnTypes (group) have same precedence.


              Example #3
              dn: o=XYZ, c=US
              ldapACI: 1.2.3.4#subtree#grant;r,w;attribute:attr3;
                         #group#cn=G1,ou=ABC,o=XYZ,c=US
              ldapACI: 1.2.3.4#subtree#deny;w;attribute:attr3;
                         #group#cn=G2,ou=ABC,o=XYZ,c=US

              What rights does cn=jsmith have to attr3 of o=XYZ, c=US?
              Read access; write is denied (deny has precedence over
              grant).


              Example #4
              dn: o=XYZ, c=US
              ldapACI: 1.2.3.4#subtree#grant;w;attribute:attr4;
                         #access-id#cn=jsmith,ou=ABC,o=XYZ,c=US
              ldapACI: 1.2.3.4#subtree#grant;r;attribute:attr4;
                         #subtree#ou=ABC,ou=XYZ,c=US



          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 20]






          Internet-Draft      Access Control Model       10 March 2000



              What rights does cn=jsmith have to attr4 of o=XYZ, c=US?
              Write (w); rights given to an access-id take precedence
              over those given to a subtree.




          7.  Operational Semantics of Access Control Operations

             The semantics of access control operations described in
             this document are defined operationally in terms of
             "histories".  A history is a sequence of actions (x1, x2,
             ..., xN).


          7.1  Types of actions

             We consider five types of actions:

                - LDAP Access Control Policy Update actions:
                  invocations of ldap modify when used to add, delete,
                  or replace the aci attribute; invocations of ldap
                  add when used to add an entry with an aci attribute.
                  A LDAP Access Control Policy Update action may
                  replace the policy (by completely replacing the aci
                  attribute with new policy information) or it may
                  grant or deny specific rights while leaving others
                  unaffected.

                - LDAP Access Control Policy Query operations:
                  invocations of ldap search when used to retrieve the
                  aci attribute; invocations of ldap search with the
                  getEffectiveRightsRequest control; invocations of
                  the ldapGetEffectiveRightsRequest extended
                  operation.

                - Datastore Access Control Policy Update Actions: any
                  operation implemented by the server which LDAP is
                  using as its datastore which changes the access
                  policy enforced with respect to attempts to access
                  LDAP directory entries and their attributes.

                - LDAP Access Request operations: invocations of LDAP
                  entry or attribute access operations (Read, Update,
                  Search, Compare, etc...).



          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 21]






          Internet-Draft      Access Control Model       10 March 2000



                - Other operations: anything else, including Datastore
                  operations which do not change the access policy
                  enforced by the server.


          7.2  Semantics of Histories

             The semantics of histories are defined as follows:

                - LDAP Update (Replace), LDAP Query

                  The Query will show that the subject has all rights
                  granted by the Update operation, and no rights not
                  granted by the Update operation.

                - LDAP Update (Grant), LDAP Query

                  The Query will show that the subject has all rights
                  granted by the Update operation.  The Query may show
                  that the subject also has other rights not granted
                  by the Update operation, depending on the policy in
                  force before the Update operation.

                - LDAP Update (Deny), LDAP Query

                  The Query will show that the subject does not have
                  any right denied by the Update operation.  The Query
                  may show that the subject has rights not denied by
                  the Update operation, depending on the policy in
                  force before the Update operation.

                - LDAP Update (Replace), LDAP Access Request

                  The Request will succeed if it requires only rights
                  granted to the requesting subject by the Update
                  operation.  The Request will fail if it requires any
                  right not granted by the Update operation.

                - LDAP Update (Grant), LDAP Access Request

                  The Request will succeed if it requires only rights
                  granted to the requesting subject by the Update
                  operation.  The Request may succeed if it requires
                  rights not granted by the Update operation,
                  depending on the policy in force before the Update



          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 22]






          Internet-Draft      Access Control Model       10 March 2000



                  operation.

                - LDAP Update (Deny), LDAP Access Request

                  The Request will fail if it requires any right
                  denied to the requesting subject by the Update
                  operation.  If the Request requires only rights
                  which were not denied by the Update operation, it
                  may succeed, depending on the policy in force before
                  the Update operation.

                - LDAP Update (Replace), Other, LDAP Query

                  The Query will show that the subject has all rights
                  granted by the Update operation, and no rights not
                  granted by the Update operation.

                - LDAP Update (Grant), Other, LDAP Query

                  The Query will show that the subject has all rights
                  granted by the Update operation.  The Query may show
                  that the subject also has other rights not granted
                  by the Update operation, depending on the policy in
                  force before the Update operation.

                - LDAP Update (Deny), Other, LDAP Query

                  The Query will show that the subject does not have
                  any right denied by the Update operation.  The Query
                  may show that the subject has rights not denied by
                  the Update operation, depending on the policy in
                  force before the Update operation.

                - LDAP Update (Replace), Other, LDAP Access Request

                  The Request will succeed if it requires only rights
                  granted to the requesting subject by the Update
                  operation.  The Request will fail if it requires any
                  right not granted by the Update operation.

                - LDAP Update (Grant), Other, LDAP Access Request

                  The Request will succeed if it requires only rights
                  granted to the requesting subject by the Update
                  operation.  The Request may succeed if it requires



          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 23]






          Internet-Draft      Access Control Model       10 March 2000



                  rights not granted by the Update operation,
                  depending on the policy in force before the Update
                  operation.

                - LDAP Update (Deny), Other, LDAP Access Request

                  The Request will fail if it requires any right
                  denied to the requesting subject by the Update
                  operation.  If the Request requires only rights
                  which were not denied by the Update operation, it
                  may succeed, depending on the policy in force before
                  the Update operation.

                - LDAP Update (Replace), Datastore Policy Update, LDAP
                  Query

                  The result of the Query is not defined.

                - LDAP Update (Grant), Datastore Policy Update, LDAP
                  Query

                  The result of the Query is not defined.

                - LDAP Update (Deny), Datastore Policy Update, LDAP
                  Query

                  The result of the Query is not defined.

                - LDAP Update (Replace), Datastore Policy Update, LDAP
                  Access Request

                  The result of the Access Request is not defined.

                - LDAP Update (Grant), Datastore Policy Update, LDAP
                  Access Request

                  The result of the Access Request is not defined.

                - LDAP Update (Deny), Datastore Policy Update, LDAP
                  Access Request

                  The result of the Access Request is not defined.






          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 24]






          Internet-Draft      Access Control Model       10 March 2000



          8.  Access Control Parameters for LDAP Controls & Extended
          Operations

             This section defines the parameters used in the access
             control LDAP controls and extended operations in this
             document.

             targetDN specifies the initial directory entry in DN
             syntax on which the control or extended operation is
             performed.

             whichObject specifies whether the access control
             information (in the get effective rights control) which
             is retrieved is for the target directory entry (ENTRY) or
             the target directory entry and its subtree (SUBTREE).

             family specifies the family OID that will be retrieved
             for the get effective rights control or extended
             operation performed.  A family has a defined set of
             rights, among other things.

             rights in the get effective rights control or extended
             operation response is of the form specified in the BNF
             for <rights>.

             dnType speficies the type of subject security attribute.
             Defined types are specified in the BNF.

             subjectDN is a LDAP string that defines the subject or
             value of the dnType.  The subjectDN may be a DN or
             another string such as IPAddress (dotted-decimal string
             representation) on which access control is get/set.  If
             the subject is an entry in the directory, then the syntax
             of the LDAP string is DN.  The well-known subjectDNs
             strings are defined

                - public - meaning public access for all users

                - this - meaning the user whose name matches the entry
                  being accessed

                - *  - meaning everyone who has access to the entry






          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 25]






          Internet-Draft      Access Control Model       10 March 2000



          9.  Access Control Information (ACI) Controls

             The access control information controls provide a way to
             manipulate access control information in conjunction with
             a LDAP operation.  One LDAP control is defined.  This
             control allows access control information to be get/set
             while manipulating other directory information for that
             entry.  The control is:

                - getEffectiveRights to obtain the effective rights
                  for a given directory entry(s) for a given subject
                  during a ldap_search operation

          9.1  getEffectiveRights Control


          9.1.1  Request Control

             This control may only be included in the ldap_search
             message as  part of the controls  field  of the
             LDAPMessage, as  defined in  Section  4.1.12 of [LDAPv3].

             The controlType is set to <OID to be assigned>. The
             criticality MAY be either TRUE or FALSE (where absent is
             also equivalent to FALSE) at the client's option.  The
             controlValue is an OCTET STRING, whose value is the BER
             encoding of a value of the following SEQUENCE:

              getEffectiveRightsRequest ::= SEQUENCE {
                effectiveRightsRequest   SEQUENCE OF SEQUENCE {
                    family        LDAPOID | "*",
                    whichObject   ENUMERATED {
                                  LDAP_ENTRY (1),
                                  LDAP_SUBTREE (2)
                                  },
                    dnType        "access-id"|"group"|"role"|
                                    "ipAddress"|"kerberosID"|
                                    <printableString> | "*",
                    subjectDN     LDAPString | "public" |
                                    "this" |  "*"
                    }
              }

             The effectiveRightsRequest is a set of sequences that
             state the whichObject (entry or entry plus subtree) and



          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 26]






          Internet-Draft      Access Control Model       10 March 2000



             specifics of the control request to be performed.  One or
             more family can be be obtained for a given subjectDN ad
             dnType.  A "*" in the family field indicates that the
             rights for all families defined for the subjectDN /
             dnType are to be returned.  A "*" in the dnType field
             specifies that all DN types are to be used in returning
             the effective rights.  This control is applied to the
             filter and scope set by the ldap_search operation, i.e.
             base, one-level, subtree.  So the attributes/values
             returned are defined by the ldap_search operation.

          9.1.2  Response Control

             This control is included in the ldap_search_response
             message as part of the controls field of the LDAPMessage,
             as defined in Section 4.1.12 of [LDAPv3].

             The controlType is set to <OID to be assigned>. There is
             no need to set the criticality on the response.  The
             controlValue is an OCTET STRING, whose value is the BER
             encoding of a value of the following SEQUENCE:

              getEffectiveRightsResponse ::= {
                result  ENUMERATED {
                   success                       (0),
                   operationsError               (1),
                   unavailableCriticalExtension (12),
                   noSuchAttribute              (16),
                   undefinedAttributeType       (17),
                   invalidAttributeSyntax       (21),
                   insufficientRights           (50),
                   unavailable                  (52),
                   unwillingToPerform           (53),
                   other                        (80)
                   }
              }

             The effective rights returned are returned with each
             entry returned by the search result.  The control
             response for ldap_search is:

              PartialEffectiveRightsList ::= SEQUENCE OF SEQUENCE {
                 family        LDAPOID,
                 rights        <see <rights> in BNF>,
                 whichObject   ENUMERATED {



          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 27]






          Internet-Draft      Access Control Model       10 March 2000



                                   LDAP_ENTRY (1),
                                   LDAP_SUBTREE (2)
                                   },
                 dnType        "access-id"|"group"|
                                "role"|"ipAddress"|
                                "kerberosID"|
                                <printableString> |
                                "*",
                 subjectDN     LDAPString | "public" |
                                    "this" | "*"
              }

             Although this extends the search operation, there are no
             incompatibilities between versions.  LDAPv2 cannot send a
             control, hence the above structure cannot be returned to
             a LDAPv2 client.  A LDAPv3 client cannot send this
             request to a LDAPv2 server.  A LDAPv3 server not
             supporting this control cannot return the additional
             data.

          9.1.3  Client-Server Interaction

             The getEffectiveRightsRequest control requests the rights
             that MUST be in effect for requested directory
             entry/attribute based on the subject DN.  The server that
             consumes the search operation looks up the rights for the
             returned directory information based on the subject DN
             and returns that rights information.

             There are six possible scenarios that may occur as a
             result of the getEffectiveRights control being included
             on the search request:


               1.  If the server does not support this control and the
                   client specified TRUE for the control's criticality
                   field, then the server MUST return
                   unavailableCriticalExtension as a return code in
                   the searchResponse message and not send back any
                   other results.  This behavior is specified in
                   section 4.1.12 of [LDAPv3].

               2.  If the server does not support this control and the
                   client specified FALSE for the control's
                   criticality field, then the server MUST ignore the



          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 28]






          Internet-Draft      Access Control Model       10 March 2000



                   control and process the request as if it were not
                   present.  This behavior is specified in section
                   4.1.12 of [LDAPv3].

               3.  If the server supports this control but for some
                   reason such as cannot process specified family and
                   the client specified TRUE for the control's
                   criticality field, then the server SHOULD do the
                   following: return unavailableCriticalExtension as a
                   return code in the searchResult message.

               4.  If the server supports this control but for some
                   reason such as cannot process specified family and
                   the client specified FALSE for the control's
                   criticality field, then the server should process
                   as 'no rights returned for that family' and include
                   the result Unavailable in the
                   getEffectiveRightsResponse control in the
                   searchResult message.

               5.  If the server supports this control and can return
                   the rights per the family information, then it
                   should include the getEffectiveRightsResponse
                   control in the searchResult message with a result
                   of success.

               6.  If the search request failed for any other reason,
                   then the server SHOULD omit the
                   getEffectiveRightsResponse control from the
                   searchResult message.

             The client application is assured that the correct rights
             are returned for scope of the search operation if and
             only if the getEffectiveRightsResponse control returns
             the rights.  If the server omits the
             getEffectiveRightsResponse control from the searchResult
             message, the client SHOULD assume that the control was
             ignored by the server.

             The getEffectiveRightsResponse control, if included by
             the server in the searchResponse message, should have the
             getEffectiveRightsResult set to either success if the
             rights are returned or set to the appropriate error code
             as to why the rights could not be returned.




          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 29]






          Internet-Draft      Access Control Model       10 March 2000



             The server may not be able to return a right because it
             may not exist in that directory object's attribute; in
             this case, the rights request is ignored with success.


          10.  Access Control Extended Operation

             An extended operation, get effective rights, is defined
             to obtain the effective rights for a given directory
             entry for a given subject.  This operation may help with
             the management of access control information independent
             of manipulating other directory information.


          10.1  LDAP Get Effective Rights Operation

             ldapGetEffectiveRightsRequest ::= [APPLICATION 23]
             SEQUENCE {
                requestName      [0] <OID to be assigned>,
                requestValue     [1] OCTET STRING OPTIONAL }

                where

                requestValue ::= SEQUENCE {
                   targetDN  LDAPDN,
                   updates   SEQUENCE OF SEQUENCE {
                               family        LDAPOID | "*",
                               whichObject   ENUMERATED {
                                               LDAP_ENTRY (1),
                                               LDAP_SUBTREE (2)
                                               },
                               attr SEQUENCE {
                                  attr   <see <attr> in BNF >
                                  },
                               dnType        "access-id"|"group"|
                                               "role"|"ipAddress"|
                                               "kerberosID"|
                                               <printableString> |
                                               "*",
                               subjectDN     LDAPString | "public" |
                                               "this" | "*"
                               }
                   }





          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 30]






          Internet-Draft      Access Control Model       10 March 2000



             The requestName is a dotted-decimal representation of the
             OBJECT IDENTIFIER corresponding to the request. The
             requestValue is information in a form defined by that
             request, encapsulated inside an OCTET STRING.

             The server will respond to this with an LDAPMessage
             containing the ExtendedResponse which is a rights list.

             ldapGetEffectiveRightsResponse ::= [APPLICATION 24]
             SEQUENCE {
                COMPONENTS OF LDAPResult,
                responseName     [10] <OID to be assigned> OPTIONAL,
                effectiveRights  [11] OCTET STRING OPTIONAL }

                where

                effectiveRights ::= SEQUENCE OF SEQUENCE {
                   family        LDAPOID,
                   rights        <see <rights> in BNF>,
                   whichObject   ENUMERATED {
                                    LDAP_ENTRY (1),
                                    LDAP_SUBTREE (2)
                                    },
                   dnType        "access-id"|"group"|"role"|
                                    "ipAddress"|"kerberosID"|
                                    <printableString>,
                   subjectDN     LDAPString | "public" | "this"
                }

             If the server does not recognize the request name, it
             MUST return only the response fields from LDAPResult,
             containing the protocolError result code.



          11.  Security Considerations

             This document proposes protocol elements for transmission
             of security policy information.  Security considerations
             are discussed throughout this draft.  Because subject
             security attribute information is used to evaluate
             decision requests, it is security-sensitive information
             and must be protected against unauthorized modification
             whenever it is stored or transmitted.




          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 31]






          Internet-Draft      Access Control Model       10 March 2000



          12.  References

             [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight
             Directory Access Protocol (v3)", RFC 2251, December 1997.

             [ECMA] ECMA, "Security in Open Systems: A Security
             Framework" ECMA TR/46, July 1988

             [REQTS] Stokes, Byrne, Blakley, "Access Control
             Requirements for LDAP", INTERNET-DRAFT <draft-ietf-
             ldapext-acl-reqts-03.txt>, February 2000.

             [ATTR] M.Wahl, A, Coulbeck, T. Howes, S. Kille,
             "Lightweight Directory Access Protocol (v3)": Attribute
             Syntax Definitions, RFC 2252, December 1997.

             [UTF] M. Wahl, S. Kille, "Lightweight Directory Access
             Protocol (v3)": A UTF-8 String Representation of
             Distinguished Names", RFC 2253, December 1997.

             [Bradner97] Bradner, Scott, "Key Words for use in RFCs to
             Indicate Requirement Levels", RFC 2119.


          AUTHOR(S) ADDRESS

              Ellen Stokes                       Bob Blakley
              IBM                                Dascom
              11400 Burnet Rd                    5515 Balcones Drive
              Austin, TX 78758                   Austin, TX 78731
              USA                                USA
              mail-to: stokes@austin.ibm.com     mail-to: blakley@dascom.com
              phone: +1 512 838 3725             phone: +1 512 458 4037  ext 5012
              fax:   +1 512 838 8597             fax:   +1 512 458 237


              Debbie Byrne
              IBM
              11400 Burnet Rd
              Austin, TX 78758
              USA
              mail-to: djbyrne@us.ibm.com
              phone: +1 512 838 1960
              fax:   +1 512 838 8597




          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 32]






          Internet-Draft      Access Control Model       10 March 2000



















































          Stokes, Byrne, Blakley   Expires 10 September 2000         [Page 33]










                                    CONTENTS


           1.  Introduction.......................................   2

           2.  Overview...........................................   2

           3.  Terminology........................................   4

           4.  The Model..........................................   6
               4.1   Access Control Information Model.............   6

           5.  Access Control Mechanism Attributes................   8
               5.1   Root DSE Attribute for Access Control
                     Mechanism....................................   8
               5.2   Subschema Attribute for Access Control
                     Mechanism....................................   8

           6.  Access Control Information Attributes..............   9
               6.1   The BNF......................................  10
               6.2   Other Defined Parameters.....................  11
                     6.2.1  Families and Rights  11
                     6.2.2  DN Types  12
               6.3   Basic ACI Attribute (ldapACI)................  13
                     6.3.1  LDAP Operations  15
                     6.3.2  Grant/Deny Evaluation Rules  15
               6.4   Policy Owner Attribute (policyOwner).........  16
               6.5   ACI Examples.................................  17
                     6.5.1  Attribute Definition  17
                     6.5.2  Modifying the ldapACI Values  18
                     6.5.3  Evaluation  19

           7.  Operational Semantics of Access Control
               Operations.........................................  21
               7.1   Types of actions.............................  21
               7.2   Semantics of Histories.......................  22

           8.  Access Control Parameters for LDAP Controls &
               Extended Operations................................  25

           9.  Access Control Information (ACI) Controls..........  26
               9.1   getEffectiveRights Control...................  26
                     9.1.1  Request Control  26
                     9.1.2  Response Control  27
                     9.1.3  Client-Server Interaction  28



                                     - i -











          10.  Access Control Extended Operation..................  30
               10.1  LDAP Get Effective Rights Operation..........  30

          11.  Security Considerations............................  31

          12.  References.........................................  32










































                                     - ii -











          Full Copyright Statement

          Copyright (C) The Internet Society (1999).<2E> All Rights
          Reserved.

          This document and translations of it may be copied and
          furnished to others, and derivative works that comment on or
          otherwise explain it or assist in its implementation may be
          prepared, copied, published and distributed, in whole or in
          part, without restriction of any kind, provided that the
          above copyright notice and this paragraph are included on
          all such copies and derivative works.<2E> However, this
          document itself may not be modified in any way, such as by
          removing the copyright notice or references to the Internet
          Society or other Internet organizations, except as needed
          for the purpose of developing Internet standards in which
          case the procedures for copyrights defined in the Internet
          Standards process must be followed, or as required to
          translate it into languages other than English.

          The limited permissions granted above are perpetual and will
          not be revoked by the Internet Society or its successors or
          assigns.

          This document and the information contained herein is
          provided on an "AS IS" basis and THE INTERNET SOCIETY AND
          THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
          WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
          ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
          INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
          MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

















                                    - iii -