![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to q-secdes.tex CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / manual|
Return to q-secdes.tex CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / manual |
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.