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

From: Mark Davidson <[email-masked]>
Date: Fri, 06 Jul 2001 10:54:12 +0100

I've been looking into the ACM recently and seeing some 
comments on -08 here are my thoughts.

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

There do seem to be a lot of possible permissions now.
Either reducing them as Kurt suggests or perhaps grouping
them so that a client (or admin interface) writer could
simplify the interface would be good.

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

The entry/subtree split is very useful for finding ACIs
that control more than one entry, which is very useful
for caching. Also it is quite a simple scheme, I would like
to keep it as it is.

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

It took some time to understand what the draft was doing
with ldapACIsubentry, and I still do not see much of
a use for it.

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

I would quite like to see these optional, but understand that
they are already in use.
 
> - remove authnLevel.  Don't add integrity/confidentiality
>   factors.

I liked the new 'buckets', the use of none, weak, limited and
strong would make an administrator think more about security,
while also allowing an implementation to assign specific levels
to specific mechanisms. authnLevel is security information that
the server has, and if it is used, it should be used all the time
as in -08.
 
> - don't require recursive expansion of roles and groups
>   (implementation complexity).

I can see that this is a problem in implementation, but recursive
expansion is what you would expect if you added one group to
another group.

Mark

---

From: "Steinitz, Dominic J" <[email-masked]>
Date: 06 Jul 2001 15:02:52 Z

We prefer authentication method to authentication strength. This allows different organisations to make their own choice about what is acceptable for a particular application.

Why force authentication methods to have strengths relative to each other? For example, I may wish to say that voice authentication is ok for application A, fingerprint for application B,  voice and fingerprint for application C and voice or fingerprint for application D.

This is a general security question not one that is just applicable to ldap. Experience has shown us that giving each authentication method a strength is unnecessarily constraining. It is better to leave an organisation to make the decision about which methods are acceptable.

I am not convinced by the deprecated argument. Again, I suggest individual organisations should be left to make a decision about whether a given method is still acceptable for a given application.

Dominic.

[email-masked] on 06/07/2001 11:13:00
To:	ietf-ldapext
cc:	
bcc:	Dominic Steinitz
Subject:	Re: increasing complexity - draft-ietf-ldapext-acl-model-08.txt

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

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

-------------------------------------------------------------------------------------------------
21st century air travel     http://www.britishairways.com

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 06 Jul 2001 08:44:50 -0700

My suggestion the ACM not support authentication level nor mechanism.
We've going through this discussion multiple times now and its seems
that we're not going to reach consensus as to which to support in
the ACM.

        Kurt

>We prefer authentication method to authentication strength. This allows different organisations to make their own choice about what is acceptable for a particular application.

What does SIMPLE mean plain simple bind or simple bind over TLS?
What does SASL mean?
What does EXTERNAL mean?
What does DIGEST-MD5 mean?  (auth only?  auth-int? auth-conf?)
What does GSSAPI mean?  w/ pre-auth?  w/o pre-auth?

>Why force authentication methods to have strengths relative to each other? 

We're categorizing uses of methods (not that method strength
depends on use) based upon what attacks they are prone to.

>This is a general security question not one that is just applicable to ldap.

But answers may not be.

>Experience has shown us that giving each authentication method a strength is unnecessarily constraining.

Experience has shown us that users (or administrators) do not
understand the complexity of security.

>It is better to leave an organisation to make the decision about which methods are acceptable.

Users do not have a clue of what methods they are using let alone
which methods they should be using (and most admins don't either).

Kurt