ACL evaluation on ADD operations (ITS#4556)
by Quanah Gibson-Mount
Currently, ACL evaluation doesn't behave the way people always expect on
ADD operations (see ITS#4556). This has been fixed in HEAD, but not
currently applied to RE24. I'm currently working on 2.4.13, and wanted to
gather general feedback on whether or not it is thought this change should
be included. It is a distinct change in behavior, and will break expected
behavior for some folks.
Thanks,
Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 10 months
Re: commit: ldap/libraries/libldap deref.c Makefile.in
by Quanah Gibson-Mount
--On Tuesday, November 11, 2008 12:26 AM +0100 Pierangelo Masarati
<ando(a)sys-net.it> wrote:
I've gone ahead and moved it out from #LDAP_DEVEL, along with the
WHATFAILED control.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 10 months
Re: commit: ldap/libraries/libldap deref.c Makefile.in
by Pierangelo Masarati
quanah(a)OpenLDAP.org wrote:
> Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap
>
> Modified Files:
> Tag: OPENLDAP_REL_ENG_2_4
> Makefile.in 1.79.2.6 -> 1.79.2.7
> Added Files:
> Tag: OPENLDAP_REL_ENG_2_4
> deref.c NONE -> 1.2.2.1
>
> Log Message:
> ITS#5768
This commit breaks 2.4 because LDAP_CONTROL_X_DEREF is only defined when
LDAP_DEVEL is, but it is used in libldap/deref.c without #ifdef.
Probably, the macro declaration should be moved outside #ifdef
LDAP_DEVEL. I don't want to intervene while you're consolidating 2.4,
though.
Cheers, p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
14 years, 10 months
Re: commit: ldap/doc/drafts draft-masarati-ldap-whatfailed-xx.txt draft-masarati-ldap-whatfailed.xml
by Pierangelo Masarati
quanah(a)OpenLDAP.org wrote:
> Update of /repo/OpenLDAP/pkg/ldap/doc/drafts
>
> Added Files:
> Tag: OPENLDAP_REL_ENG_2_4
> draft-masarati-ldap-whatfailed-xx.txt NONE -> 1.4.2.1
> draft-masarati-ldap-whatfailed.xml NONE -> 1.4.2.1
>
> Log Message:
> ITS#5784
Probably, you should not release the .xml code. It's there because it's
the source of the textual form.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
14 years, 10 months
Fw: [x500standard] Important resolutions out of Montreux
by Gavin Henry
Would an x500 password policy influence our LDAP one?
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
Suretec Systems is a limited company registered in Scotland. Registered
number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie,
Aberdeenshire, AB51 4FP.
-----Original Message-----
From: "Erik Andersen" <era(a)x500.eu>
Date: Sun, 9 Nov 2008 10:05:31
To: Directory list<x500standard(a)freelists.org>
Subject: [x500standard] Important resolutions out of Montreux
Hi Folks,
The ISO/IEC JTC1/SC6 meeting in Montreux has ended. It resulted in a new
working draft for Password Policy.
Among resolutions for the directory works (WG8) the following are quite
important
Resolution 6.8.4 Advance Authorisation for Project Subdivision
SC 6 approves the split of Project 47.05.23, Directory Communication support
enhancements under the condition that ITU-T Study Group 17 in its coming
meeting approves further work in this area. The work will then continue to
allow for further communication enhancements to the new edition.
Resolution 6.8.6 Scope of Project 47.06.22
SC 6 recognises that Password Policy is a part of Identity Management and
that the Password Policy project may include related Identity Management
aspects.
The first resolution allows us to continue work on for communication
enhancement. This may mean enhancing the X.500 communications support and
make communication enhancement supporting for other type of specifications,
e.g. tag-based applications.
The second resolution allows us the add support for well defined requirement
for Identity Management.
Regards,
Erik Andersen
Andersen's L-Service
Elsevej 48, DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
email: era(a)x500.eu
www.x500.eu
www.x500standard.com
14 years, 10 months
Filtering for entryDN
by Pierangelo Masarati
There's an application that "bombs" slapd filtering for equality on
entryDN. I know it sounds like a nonsense, but that's how it is.
Would it make sense to use the dn2id index as the default entryDN key
database for equality on entryDN, instead of explicitly configuring (and
maintaining) an index on entryDN?
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
14 years, 10 months
Controls and criticality
by Pierangelo Masarati
I see some inconsistency and possibly some misunderstanding (probably
mostly at my side) on controls and criticality. This has been discussed
many times, but probably slapd did not converge yet.
The specs (RFC4511) say that controls CAN be critical or non-critical.
Implementations (DSAs) MAY or MAY NOT recognize controls. I see many
cases; some of them are trivial, but other are not.
Let's consider a matrix, where columns represent criticality (FALSE,
TRUE) and rows represent implementation (FALSE, TRUE).
implemented \ criticality | FALSE | TRUE |
----------------------------+--------+--------+
FALSE | F,F | F,T |
----------------------------+--------+--------+
TRUE | T,F | T,T |
----------------------------+--------+--------+
The specs state that if a control is not implemented, criticality
determines whether the control is ignored (crit == FALSE) or the
operation fails (crit == TRUE). If the control is implemented, then
criticality determines whether, in case the control cannot be applied,
whether the control is ignored (crit == FALSE) or the operation fails
(crit == TRUE).
It should be clear that the criticality field is already overloaded: in
the first case the implementation does not know the control, while in
the second case it knows the control so much that it can determine
whether or not it can be applied.
Let's now add a third, fuzzy dimension: control semantics. In fact, in
many specs, the control semantics tries to bend the meaning of
criticality towards common sense.
The specs say that all four combinations F,F; F,T; T,F; T,T are
perfectly legitimate, and describe how a DSA MUST behave in all cases
(or CAN, when an arbitrary behavior is legitimate).
Let me start with intuitive considerations: there are cases in which
some of the four possible behaviors should (lowercase "should") not be
allowed by common sense. However, this seems to violate a strict
interpretation of the specs. I'll bring examples shortly. But in any
case, I believe slapd should behave:
1) consistently
2) biased towards security
Examples:
a) RFC4370, proxied authorization control, states that "Clients MUST
include the criticality flag and MUST set it to TRUE. Servers MUST
reject any request containing a Proxy Authorization Control without a
criticality flag or with the flag set to FALSE with a protocolError
error." and explains why: "These requirements protect clients from
submitting a request that is executed with an unintended authorization
identity." This is just common sense, and is part of the control's
semantics, but it disagrees with RFC4511, which is normative.
Currently, slapd does not follow this common sense advice, and allows
non-critical proxied authorization requests. Please note the first
"MUST" (for the DUA) and the second "MUST" (for the DSA; this is in
violation of RFC4511).
b) <draft-zeilenga-ldap-dontusecopy-04> (a work in progress) states that
"The criticality MUST be TRUE. There is no corresponding response
control." This again is common sense, since if the control is not
recognized, the operation's semantics would be totally different, as
(out of sync) copies could be used instead of the original data, which
is the purpose of the control. Please note the "MUST" (uppercase; for
the DUA).
Currently, slapd follows the advice of this work in progress, but it'll
probably need to be changed in order to be published as an RFC, because
as it is now it does not comply with RFC4511 (see ITS#5785).
Note that RFC4511 provides a sentence, about what controls
specifications are to provide, that sounds a little bit ambiguous:
"[...] direction as to what value the sender should provide for the
criticality field (note: the semantics of the criticality field are
defined above should not be altered by the control's specification)".
In the end, the responsibility for getting into trouble is all placed on
the DUA; the specs "are to" (lowercase, no "MUST") provide what the
sender "should" (lowercase, no "SHOULD") provide for the criticality field.
I believe that this is absolutely correct, but as a DSA implementor, and
not only a DUA implementor, I also believe that it is the responsibility
of the DSA to make sure its integrity and security is not compromised by
a poorly behaving DUA. I recommend we take two actions:
1) make sure slapd behaves consistently in all those cases, no matter
whether we choose to follow the letter of RFC4511 or to tend towards the
security and integrity side
2) act in direction of a modification of RFC4511 that somehow allows the
semantics of a control to override those of the criticality field. I
believe the criticality field is a mandatory mechanism to promote
interoperability when it comes to extensions. However, there are cases
where either interoperability exists or doesn't. In those cases, we
cannot simply delegate security and integrity to the DUA, as the DSA is
responsible of both in the end.
I believe the main consequence of allowing the DSA to reject (as
something closely related to a protocol violation) a control whose
criticality does not conform with that control's specification in terms
of semantics would be that in the case of criticality set to FALSE two
implementations would behave differently depending on whether that
control is implemented or not. But this degree of arbitrarity does not
differ much from that implicitly allowed by clients when they set
criticality to FALSE.
Sending dontUseCopy with FALSE is an error. RFC4511 says we should
return possibly outdated data in response. Receiving an error in
response to an error, instead of incorrect data because the control was
ignored, seems more appropriate. Not per se, but rather because it
brings less harm than it could by behaving according to RFC4511.
This is my 2c (well, reading back, it looks like more than just 2 :)
p.
14 years, 10 months
Fwd: [x500standard] Password attribute
by Gavin Henry
----- Forwarded Message -----
From: "David Chadwick" <d.w.chadwick(a)kent.ac.uk>
To: x500standard(a)freelists.org
Sent: Monday, 3 November, 2008 3:56:46 PM GMT +00:00 GMT Britain, Ireland, Portugal
Subject: [x500standard] Password attribute
Hi All
In the new version of X.500 that we are working on, we are creating
password policies, grace periods, password expiration times and the like.
Currently the password attribute in X.509 is defined semantically to be
SINGLE valued, but syntactically to be multi-valued.
We are considering changing the syntax to agree with the semantic
definition, since this will significantly simplify the password
management text.
DOES ANYONE HAVE ANY OBJECTIONS TO THE PASSWORD ATTRIBUTE BECOMING
SINGLE VALUED, and if so could they say why
thanks
David
--
*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick(a)kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5
*****************************************************************
-----
www.x500standard.com: The central source for information on the X.500 Directory Standard.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
Suretec Systems is a limited company registered in Scotland. Registered
number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie,
Aberdeenshire, AB51 4FP.
14 years, 10 months
