Subject: IP/DNS subjects - draft-ietf-ldapext-acl-model-08.txt

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 02 Jul 2001 19:29:42 -0700

As we've gone around a couple of times on this issue previously,
I will just note my continued objection to the inclusion of
IP address and DNS based subjects as they are easily spoofed.
I especially dislike that they are NOT RECOMMENDED but MUST
be implemented.  I also note that their semantics require
numerous special cases such as abnormal precedence (subjects
w/ ranges, wildcards, and otherwise matching multiple entities
are less specific than authzId based subjects) and grant/deny
semantics.

As the specification allows extension of subject forms, I recommend
that IP address and DNS based subjects be introduce in a document
extending the LDAP ACM specification.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 02 Jul 2001 19:46:36 -0700

As I note in my auth-lvls I-D, one must be careful not to
confuse the strength of the authentication mechanism itself
and the strength of a security association.  In particular,
while a strong mechanism resists active attack, if data
integrity is not provided over the duration of the security
association, that association is subject to hijack attack.

I note that the current ACM does not support the strength
of data integrity or data confidential services as access
control factors.  This should be noted as well.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 02 Jul 2001 20:35:04 -0700

I would like to voice my general opinion that the ACM is
may be overly complex.  I believe the ACM should
be much simpler.

I offer for (re)consideration:

- instead of defining permissions which parallel LDAP
  operations, define permissions based upon the type
  of access being made.  That is, "write" permission
  would be needed by subject to update a particular
  target irregardless of what operation was used to
  to request the update.

- return to one ACI attribute and handle entry/subtree
  semantics via target scope in the value.  This scope
  would be more easily extended to support non-entry
  and non-subtree scopes (such as one-level, children,
  etc.).

- eliminate one of the syntax variants.  I suggest using
  just a ASN.1 described syntax to be ";binary" transferred.
  (a string representation of this could be separately defined
  for presentation to users, if desired).

- remove all mention of ldapACIsubentry from the I-D and
  generalize the out-of-scope statement to "prescriptive
  ACIs and scoping via subenties is beyond the scope of
  this document".

- remove ipAddress and DNS subjects as they require special
  semantics (as well as for the security considerations
  separately noted).

- remove authnLevel.  Don't add integrity/confidentiality
  factors.

- don't require recursive expansion of roles and groups
  (implementation complexity).

Kurt

---

From: Ryan Moats <[email-masked]>
Date: Thu, 5 Jul 2001 15:01:26 -0500

Finally having my arm twisted to read the latest ACI
draft and seeing these comments shortly after, here

>   target irregardless of what operation was used to

I don't have a problem with this as I'm beginning to
be concerned that and administrator will be confused
with the ACI.

>   and non-subtree scopes (such as one-level, children,

I'll have to think about this some more.

>   for presentation to users, if desired).

My reading of the document is that only string is MUST and
ASN.1 is MAY.  I disagree that string should only be separately
defined as administrators will have much greater difficulty
understanding the ASN.1 rather than the string representation.

>   ACIs and scoping via subenties is beyond the scope of

Again I have to think about this some more.

>   semantics (as well as for the security considerations

While I'd like to, I believe that there are implementations
that are *already* using them.  This makes such a removal
difficult.

> - remove authnLevel.  Don't add integrity/confidentiality

Having read the draft, either the authnLevel should be
removed or just auth mechanisms listed.  The current proposed
bucketization of authnLevel is a receipe for interoperability
nightmares.

>   (implementation complexity).

No.  do require them as not expanding leads to administrative
complexity.  There will be a *lot* more administrators using
this than developers writing code and I'd rather add the
complexity in the branch that will be less utilized (here
implementation rather than administration)

Ryan

---

From: Mark Davidson <[email-masked]>
Date: Fri, 06 Jul 2001 11:09:14 +0100

> bucketization of authnLevel is a receipe for interoperability

I disagree that this is an interop nightmare. When an admin
is constructing an ACI using an authnLevel, they are interested
in the probability that an authenticated user is who they claim
to be.
Two systems may allow different mechanisms, but the mechanisms
can be mapped onto the different strengths, so I think it would
aid interop.
The strength level 'buckets' also help when a mechanism is depricated
for some reason (eg Cram-MD5 would not have been categorized as
weak a few years ago), or when a new mechanism is added to the server.

Mark

---

From: Ryan Moats <[email-masked]>
Date: Fri, 6 Jul 2001 09:01:58 -0500

> in the probability that an authenticated user is who they claim

Sure, but that's going to depend on what the directory is used
for.

> can be mapped onto the different strengths, so I think it would

I couldn't disagree more.  The problem is when two different
mechanisms are mapped into the *same* strength level.  An (admittly
skewed) example is that one system has simple/passwd classified as
*strong* because, for its uses, it qualifies.  Now, (through
M&A say) a second system is added administered by a *different* administrator
who decided that strong would only be SASL/<whatever>.  Once replication
starts, strange things are going to happen.

> weak a few years ago), or when a new mechanism is added to the server.

Listing the mechanisms solves the deprication question as well.

Ryan

---

From: Mark Davidson <[email-masked]>
Date: Fri, 06 Jul 2001 15:19:05 +0100

> starts, strange things are going to happen.

Strength depends on environment. Suppose you have a system where simple 
passwords can be regarded as strong because there is some extra physical
security (guards with big dogs etc) that means that simple passwords
really 
are strong. Now suppose they want to set up replication with a server in
a 
university where the only mechanism that is likely to be strong is
Kerberos etc.
If you use mechanisms to define authnLevel then entries protected by
'simple/passwd' on the system with the guards are now wide open at the
university. Also, entries protected by Kerberos at the university
are inaccessible by users of the system with the guards because they
don't have (or need) kerberos. However, if levels are used then those
users on both system who have authenticated with a 'Strong' (on their
system) mechanism will have access.

If however both systems are in the same environment then it is a
procedural
operation for both admins to agree on authnLevel strengths and what type
of threats they are trying to counter with their ACIs.

> > The strength level 'buckets' also help when a mechanism is deprecated
> Listing the mechanisms solves the deprecation question as well.

But is horrible when you add a mechanism and conveys little meaning
of what security admin meant. Also if a mechanism is unavailable on
one of the servers, but an equally strong (or stronger) method is, 
then everything still works using the level method.

Mark

---

From: Ryan Moats <[email-masked]>
Date: Fri, 6 Jul 2001 12:00:59 -0500

On Fri, Jul 06, 2001 at 03:19:05PM +0100, Mark Davidson wrote:
> really are strong.

It could also be considered strong because the applications using it do
not require greater security.  That was may point.

> Now suppose they want to set up replication with a server in
> a university where the only mechanism that is likely to be strong is
> Kerberos etc.
> university. 

My point is that the converse is true.  If replication is being
done in both directions, then entries from the university's system
that are protected by "strong" (i.e. Kerberos) auth will be accessible
by folks using simple/passwd auth on the initial system.

> Also, entries protected by Kerberos at the university

My point above is that (IMHO) that is a Bad Thing.  If I protect
entries with a "strong" acl and then by replicating to a server where
simple/passwd is a "strong" authMeth have a situation where the entry
gets changed on the secondary server, when the changes get replicated
back to my server I see a security hole; plain and simple.

> procedural operation for both admins to agree on authnLevel strengths
> and what type of threats they are trying to counter with their ACIs.

Sure, but the standard has to work when the systems *aren't* in the
same envrionment.

> then everything still works using the level method

I don't see it as being horrible, as I see adding/removing mechanisms
not being a common occurance. As to your second thought, I actually *like*
blocking because a mecanism isn't available, because it makes sense.
If you want the "new" strong/stronger method to be usable, you add it
to the ACI.  IMHO, that's easier than trying to map between authLevels.

Ryan

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 18 Jul 2001 22:12:59 -0700

The draft says:
  The following topics are deemed interesting and useful for
  future work, but are also beyond the scope of this model:
   - Use of prescriptive ACIs and scoping via use of a ldapACISubEntry

and then goes on to describe ldapACISubentry.

I suggest the above bullet be reworded:
	- Specification of prescriptive ACIs [X.501]

and then to drop all mention of ldapACIsubentry, ldapSubentry,
subentry, and references to the ldap subentry I-D.

I also believe the document should note that subentry ACIs are
beyond the scope of the document.

Kurt

---

From: Ellen Stokes <[email-masked]>
Date: Thu, 19 Jul 2001 10:16:16 -0500

Kurt,

The authors came to this conclusion last week (we just hadn't stated
this on the mailing list yet) and in the next draft (09) all references
and text to subentry (and its children) is being removed.  We believe
that this is beyond the scope of the document.

Ellen