Return to q-secdes.tex CVS log

Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / manual

Annotation of 43BSDReno/contrib/isode-beta/doc/manual/q-secdes.tex, revision 1.1

1.1     ! root        1: % run this through LaTeX with the appropriate wrapper
        !             2: 
        !             3: \section{Models}
        !             4: 
        !             5: \subsection{Access Control}
        !             6: 
        !             7: QUIPU uses access control lists to represent access rights; the subjects
        !             8: are DUA's (represented by DN's) and the objects are entries in the DIT,
        !             9: attributes of entries, and the child-of relation for each entry (all represented
        !            10: by DN's, and, in the case of attributes, the attribute type as well).
        !            11: 
        !            12: Furthermore, objects can be {\em containers} that hold other objects. To access
        !            13: an object within an container, it is necessary to have access rights both to
        !            14: the object and the container that holds it. In particular, entries in the DIT
        !            15: are containers. The attributes of the entry and the list of its children
        !            16: are contained within the entry. The children themselves are {\em not} contained
        !            17: within the parent.
        !            18: 
        !            19: The possible levels of access are as follows: {\em none}, {\em detect}, 
        !            20: {\em compare}, {\em read}, {\em add} and {\em write}.
        !            21: 
        !            22: \subsection{Security Domains}
        !            23: 
        !            24: The DIT is a global database, maintained by many separate organisations.  
        !            25: It is possible for the manager of DSA to change its interpretation of the 
        !            26: access control rules, in order to fraudulently obtain access to information
        !            27: held by other DSAs. 
        !            28: 
        !            29: As a result, data in a DSA may need to be protected from the managers of other
        !            30: DSA's, as well as from users. This means that special checks must be performed
        !            31: on DSP operations that come from untrusted DSA's.
        !            32: 
        !            33: In order to decide to trust a DSA, it is necessary to be able to authenticate it
        !            34: and to know that it should be trusted. QUIPU 6.0 can do neither of these, and
        !            35: so assumes that {\em all} DSA's are untrusted.
        !            36: 
        !            37: 
        !            38: \section{Representation in the DIT}
        !            39: 
        !            40: \subsection{Simple Authentication}
        !            41: 
        !            42: DUA's which use simple authentication have their password stored in the
        !            43: {\em userPassword} attribute of their entry.
        !            44: 
        !            45: \subsection{Protected Simple Authentication}
        !            46: 
        !            47: QUIPU represents both passwords (the $K_{A}$'s) and authenticators by the
        !            48: ASN.1 type {\em ProtectedPassword}.
        !            49: 
        !            50: When this structure represents a password,
        !            51: {\em algorithm} indicates which one-way function is being used and
        !            52: {\em password} is the (unencrypted) password. The other fields are
        !            53: not supplied.
        !            54: 
        !            55: When this structure represents an authenticator, {\em password}
        !            56: is the hash value 
        !            57: \begin{math}
        !            58: f_{1}(K_{A}, t_{1}, q_{1})
        !            59: \end{math},
        !            60: where $t_{1}$ is {\em time1}, $q_{1}$ is {\em random1} and 
        !            61: $K_A$ is the password. {\em algorithm} is not supplied.
        !            62: 
        !            63: A relation $\geq$ can be defined on the set of passwords and
        !            64: authenticators as follows : If $a$ is a password, $b$ is an authenticator,
        !            65: and $a$ matches $b$, then $a \geq b$. (Also, $a \geq a$). It can be shown
        !            66: that this relation
        !            67: is a partial ordering of the set, justifying our use of the symbol `$\geq$'.
        !            68: We could have defined an attribute syntax for which the above relation corresponded
        !            69: to `greater than or equal' without violating any of the implied semantics
        !            70: of X.500. However, the DAP {\em compare} operation cannot be used to test 
        !            71: `greater than or equal', only `equal', and we wanted an easy way to ask the
        !            72: Directory to check this relation. To achieve this, we made the relation
        !            73: correspond to `equals' for the {\em ProtectedPassword} attribute syntax.
        !            74: 
        !            75: \tagrind{protected}{ProtectedPassword}{protected-py}
        !            76: 
        !            77: \subsection{Access Control Lists}
        !            78: 
        !            79: The access control list for an entry is held in that entry's
        !            80: {\em accessControlList} attribute.
        !            81: 
        !            82: \subsection{Security Policies}
        !            83: 
        !            84: The {\em entrySecurityPolicy} attribute of an entry is used to indicate the
        !            85: amount of care that should be taken to preserve the integrity and
        !            86: confidentiality of that entry. While the {\em accessControlList} indicates
        !            87: who should have access to the entry, the {\em entrySecurityPolicy} indicates
        !            88: which steps should be taken to prevent unauthorized access.
        !            89: 
        !            90: The {\em dsaDefaultSecurityPolicy} attribute of a DSA indicates which
        !            91: precautions the DSA will take when dealing with entries that do not have
        !            92: an {\em entrySecurityPolicy} attribute.
        !            93: 
        !            94: The {\em dsaPermittedSecurityPolicy} attribute of a DSA indicates which
        !            95: security policies the DSA is prepared to enforce. A DSA may not support a
        !            96: security policy either because it lacks the necessary software or
        !            97: because its manager wishes to forbid use of that policy.
        !            98: 
        !            99: \subsection{Labels}
        !           100: 
        !           101: Security labels are one means of enforcing rule-based access control
        !           102: (sometimes referred to as mandatory access control). QUIPU does not
        !           103: provide mandatory access control in any form.
        !           104: 
        !           105: \section{Distributed Operations}
        !           106: \label{des-auth}
        !           107: 
        !           108: \subsection{(Protected) Simple Authentication}
        !           109: 
        !           110: If the responding DSA holds the initiator's entry, then it may check the
        !           111: password directly. Otherwise, the responder will formulate a DSP compare
        !           112: operation to check it. If the result is {\em true}, the bind will be
        !           113: accepted.
        !           114: 
        !           115: This approach can only be used to check a DAP bind; If it were used in DSP,
        !           116: there would be a danger of livelock. Hence, QUIPU will not attempt to
        !           117: verify the password in a DSP bind.
        !           118: 
        !           119: \subsection{Strong Authentication}
        !           120: 
        !           121: In strong authentication, it is necessary to build a certification path
        !           122: for the originator that will be believed by the recipient. From the standpoint
        !           123: of the protocol, the originator builds the certification path and sends it to
        !           124: the recipient. However, the originator does not know for certain which CA's
        !           125: the recipient trusts, and so cannot be sure of constructing a valid path.
        !           126: 
        !           127: QUIPU solves this problem by treating the presented certification path
        !           128: as a hint. The recipient tries to build an acceptable certification path
        !           129: out of the components of the presented path and the certificates it has cached.
        !           130: 
        !           131: \subsection{Restricting Read Access}
        !           132: 
        !           133: To maintain the confidentiality of data, results from read, search etc. must
        !           134: not be passed to another DSA unless that DSA has rights to them.
        !           135: 
        !           136: QUIPU 6.0 solves this problem in the following way :
        !           137: 
        !           138: When a DUA requests private data via an untrusted DSA, QUIPU checks whether
        !           139: any of the requested information can be seen by the DUA but not by the DSA.
        !           140: If it can, the security error `inappropriate authentication' is sent to
        !           141: the untrusted DSA. (Otherwise, the data can be safely sent over DSP).
        !           142: 
        !           143: QUIPU DSAs will understand this error to mean that they are not trusted, and
        !           144: pass a referral back to the DUA. (Other DSA's may behave differently ---
        !           145: X.500 ought to be clarified in this area).
        !           146: 
        !           147: The DUA will chase the referral, and repeat its query directly to the DSA
        !           148: holding the data. The DSA will then give the DUA the results.
        !           149: 
        !           150: \subsection{Restricting Write Access}
        !           151: 
        !           152: To maintain the integrity of the data, requests to modify data over DSP must
        !           153: not be accepted unless they are signed or can be performed by anyone.
        !           154: 
        !           155: QUIPU 6.0 solves this problem as above, by returning a security error.
        !           156: When strong authentication is added to QUIPU, modify requests will be
        !           157: accepted over DSP provided that they are signed by the DUA.
        !           158: 
        !           159: As an optimisation, QUIPU DSA's never chain modify requests unless they are
        !           160: signed. (The operation will probably be rejected, so it's quicker to
        !           161: give a referral to the DUA immediately, rather than trying to chain).
        !           162: 
        !           163: \subsection{Caching}
        !           164: \label{dsp-acl}
        !           165: 
        !           166: DSA's try to improve performance by caching the results of DSP operations.
        !           167: Caching interferes with access control in two ways :
        !           168: 
        !           169: \begin{enumerate}
        !           170: \item
        !           171: The cached data may be incomplete.
        !           172: 
        !           173: The DUA that requested it may not have had
        !           174: rights to all the data, or the DSA that held the data may not have been
        !           175: prepared to send all of it over DSP.
        !           176: \item
        !           177: Caching can prevent access control.
        !           178: 
        !           179: The original data may have been subject to access controls which the holder of
        !           180: the cache is unaware of.
        !           181: \end{enumerate}
        !           182: 
        !           183: QUIPU has a special solution that only works between QUIPU DSA's (using the
        !           184: QUIPU DSP application context) : The ACL is sent along with the data across
        !           185: DSP.
        !           186: 
        !           187: QUIPU DSAs will only cache data if they have the ACL to go with it. This ensures
        !           188: that the same access controls will be applied to a cache as to the master copy.
        !           189: It also enables a DSA to tell if the cache is complete. The required information
        !           190: is checked against the ACL in the cache; if any of it is not publicly readable,
        !           191: then it might not have been returned over DSP and the cache cannot be used.
        !           192: 
        !           193: \subsection{Replicated Data}
        !           194: 
        !           195: The mechanism originally envisaged for replicating data was ``reliable ROS''
        !           196: --- Remote operations carried by X.400(88). DSA's could use the security
        !           197: mechanisms in X.400(88) to provide both integrity and confidentiality
        !           198: for the EDB updates.
        !           199: This would make the slave updates the only place in QUIPU where cryptographic 
        !           200: techniques are used to provide confidentiality, as opposed to integrity. The
        !           201: provision of confidentiality here is justified in view of the sensitivity of
        !           202: entire entry data blocks; many of them will contain user's passwords, for
        !           203: example.
        !           204: 
        !           205: However, X.400(88) is not yet widespread, and hence cannot be used as the
        !           206: primary means of replicating data. In the interim, the {\em getEDB} mechanism
        !           207: is used. This does provides neither confidentiality nor integrity, and is
        !           208: not even subject to access control (as DSP is unauthenticated).
        !           209: 

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.