Re: increasing complexity - draft-ietf-ldapext-acl-model-08.txt

[Ryan Moats <rmoats@lemurnetworks.net>]

On Fri, Jul 06, 2001 at 03:19:05PM +0100, Mark Davidson wrote:
> 
> > 
> > > Two systems may allow different mechanisms, but the mechanisms
> > > can be mapped onto the different strengths, so I think it would
> > > aid interop.
> > 
> > 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.
> 
> 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.

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.
> 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. 

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
> 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.

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.

> 
> 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.

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

> > > The strength level 'buckets' also help when a mechanism is deprecated
> > > 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.
> > 
> > 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

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