Subject: RE: ACM permission

From: "Skovgaard, Erik" <[email-masked]>
Date: Fri, 6 Jul 2001 09:11:08 -0700

Mark,

I think you will need at least a Filter Matching permission for attributes
as well.  A classical way to break security in a directory is to search for
entries with userPassword=*joan* (or whatever...).

Should there be a permission for Compare operations as well?  Denying
compare on operational information could be used to keep curious users from
poking at the ACIs themselves.

Cheers,                    ....Erik.

Erik Skovgaard
Siemens Meta-Directory Solutions
Phone: +1 604-204-0750
Fax:   +1 604-204-0760

-----Original Message-----
From: Mark Davidson [mailto:[email-masked]]
Sent: Friday, July 06, 2001 05:44
To: [email-masked]
Subject: ACM permission

I have been thinking about simplifying the permissions 
in the ACM and also adding permissions for controls. How
about:

permissions for attributes: read, modify, create, delete
permissions for entries: read, modify, create, delete

and add control OID ass a possible target with a permission
of use

so:

    ACI = rights "#" target "#" generalSubject

    permission = "r" / ; read
                 "m" / ; modify
                 "c" / ; create
                 "d" / ; delete
                 "u"   ; use
    ; permission u can only be used on controls

    target = "[all]" / "[entry]" / (attribute *("," attribute)) /
         "[controls]" / (controlType *("," controlType))

    controlType is defined in RFC2251

Granting these permissions allows:

Entry read - allows access to DN
Entry modify - can change DN
Entry create - can create an entry below this entry
Entry delete - can delete this entry

Attribute read - can read attribute 
Attribute modify - can modify replace attribute values
Attribute delete - can modify delete attribute values
Attribute create - can modify add attribute values

Control use - can use control where aci is active (this
              replaces the g permission in a more
              general way)

This does not give quite the same detailed level of
control as the current scheme, but is much easier
to understand from an administration point of view,
rather that a protocol point of view.

Mark

---

From: Mark Davidson <[email-masked]>
Date: Fri, 06 Jul 2001 17:31:31 +0100

> poking at the ACIs themselves.

You could cover all this with the attribute level read. I kow this is
not as
fine grained as the permissions in the current draft, but it is alot
less
complex to admin. So in the cases you have mentioned:

deny:r#OID.userPassword,OID.subtreeACI,OID.entryACI#authnLevel:none:public:

Mark

---

From: "Skovgaard, Erik" <[email-masked]>
Date: Fri, 6 Jul 2001 09:48:30 -0700

Mark,

Would your example prevent me from using the Compare operation?

Cheers,                ....Erik.

Erik Skovgaard

-----Original Message-----
From: Mark Davidson [mailto:[email-masked]]
Sent: Friday, July 06, 2001 09:32
To: Skovgaard, Erik
Cc: [email-masked]
Subject: Re: ACM permission

Mark

---

From: Mark Davidson <[email-masked]>
Date: Mon, 09 Jul 2001 10:01:47 +0100

> Would your example prevent me from using the Compare operation?

Yes, as read access would cover all examination of the attribute. so
without read attribute you could not get the value, compare the value
or use the value in a filter etc.

Mark

---

From: "Skovgaard, Erik" <[email-masked]>
Date: Tue, 10 Jul 2001 14:00:27 -0700

Kurt,

I have applications that use the compare operation on the userPassword for
authentication.

BTW, a BIND may result in a compare operation if you use chaining on the
back end of the server.  Has anyone considered that?

Cheers,                  ....Erik.

Erik Skovgaard

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Monday, July 09, 2001 13:17
To: Skovgaard, Erik
Cc: 'Mark Davidson'; [email-masked]
Subject: RE: ACM permission

At 09:25 AM 7/9/2001, Skovgaard, Erik wrote:
>That would be a problem.  A lot of us still use the userPassword for
>authentication.  It must be possible to protect the password (including
>performing filter matching) yet be able to use the compare operation on the
>attribute.

I'm not sure how permissions for compare relate to authentication.
The only operation which performs LDAP authentication is the
bind and its not controlled, per the I-D, by any permissions.

This said, I support having separate "assert" (compare/search
filter) permissions from read permissions as it is often useful
to allow one to assert a value but not allow them to read all
values.  The example (which I believe someone else gave) is
that there may a group where one is allowed to assert that
an entity is a member but not allowed to see the member list.

Kurt

---

From: "Volpers, Helmut" <[email-masked]>
Date: Thu, 12 Jul 2001 11:13:15 +0200

Hi Erik,

It's not the normal way to use a compare operation on the password for
authentication.
Why not use the bind and you have no problems with AccessControl.

I am not sure whether you want to make a chained bind, but if you do it it
is
a chained bind and not a compare operation on the userPassword.

Helmut 

> From: Skovgaard, Erik [mailto:[email-masked]]
> Sent: Dienstag, 10. Juli 2001 23:00
> To: 'Kurt D. Zeilenga'

---

From: "Skovgaard, Erik" <[email-masked]>
Date: Thu, 12 Jul 2001 06:36:58 -0700

Helmut,

I am working with at least two products that use the compare operation to
validate a password.  Agreed, that is not the best way, but the point here
is that the Directory was certainly intended to support this authentication
method and we should not preclude it.

I am not aware of any chained Bind operation, but my latest X.518 document
date back to 1993.  Are you telling me that the operation has been added in
later versions?

Cheers,                   ....Erik.

Erik Skovgaard

-----Original Message-----
From: Volpers, Helmut [mailto:[email-masked]]
Sent: Thursday, July 12, 2001 02:13
To: 'Skovgaard, Erik'; 'Kurt D. Zeilenga'
Cc: 'Mark Davidson'; [email-masked]
Subject: RE: ACM permission

Hi Erik,

Helmut

---

From: "Volpers, Helmut" <[email-masked]>
Date: Thu, 12 Jul 2001 16:00:38 +0200

Hi Erik,

> Sent: Donnerstag, 12. Juli 2001 15:37
> To: Volpers, Helmut; Skovgaard, Erik; 'Kurt D. Zeilenga'

I agree that application use this to validate a password, but I don't think 
that any LDAPServer handle this as an authentication.
> date back to 1993.  Are you telling me that the operation has 

No. But if you want to use chaining for authentication (what I don't like)
why not doing it with a bind instead of a compare. 

Helmut

---

From: "Skovgaard, Erik" <[email-masked]>
Date: Thu, 12 Jul 2001 07:43:27 -0700

Helmut,

It works with DirX!

I am talking about authentication for an application, not the Directory
itself.  To clarify: If I have the entry in another DSA, but access some
other DSA, a Compare operation will be propagated as a chained compare to
the DSA that holds the entry I am trying to validate against.

It may not be the best solution from a security perspective, but the Model
allows for it.

Cheers,                  ....Erik.

Erik Skovgaard

-----Original Message-----
From: Volpers, Helmut [mailto:[email-masked]]
Sent: Thursday, July 12, 2001 07:01
To: 'Skovgaard, Erik'; 'Kurt D. Zeilenga'
Cc: 'Mark Davidson'; [email-masked]
Subject: RE: ACM permission

Hi Erik,

Helmut