Dear all,
I was reading doc/devel/todo and RFC3112, and did a grep ;-)
I see that the following files contain authPassword info:
schema_init.c schema_prep.c slap.h
Does this mean it's implemented, as it still says it's not in slappasswd(8)
Thanks.
Dear all,
I was reading doc/devel/todo and RFC3112, and did a grep ;-)
I see that the following files contain authPassword info:
schema_init.c schema_prep.c slap.h
Does this mean it's implemented, as it still says it's not in slappasswd(8)
AFAIK, the attribute and so is recognized, but it's not implemented (nor won't, as it is no longer needed).
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 Email: pierangelo.masarati@sys-net.it ---------------------------------------
<quote who="Pierangelo Masarati">
Dear all,
I was reading doc/devel/todo and RFC3112, and did a grep ;-)
I see that the following files contain authPassword info:
schema_init.c schema_prep.c slap.h
Does this mean it's implemented, as it still says it's not in slappasswd(8)
AFAIK, the attribute and so is recognized, but it's not implemented (nor won't, as it is no longer needed).
ok, so it can be removed from the todo list and removed from slappasswd(8)?
Gavin.
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 Email: pierangelo.masarati@sys-net.it
Pierangelo Masarati writes:
AFAIK, the attribute and so is recognized, but it's not implemented (nor won't, as it is no longer needed).
If it's no longer needed - what has changed? I thought it was invented because the existing scheme of '{hash method}' in userPassword broke the LDAP standard. Which it still does. Not that six years of none of us bothering to implement RFC 3112 gives much hope of that changing.
On Jul 15, 2007, at 6:59 AM, Hallvard B Furuseth wrote:
Pierangelo Masarati writes:
AFAIK, the attribute and so is recognized, but it's not implemented (nor won't, as it is no longer needed).
If it's no longer needed - what has changed?
The technical needs haven't changed. Folks now seem to be finally getting that they have a choice between: a) stronger (than PLAIN) authentication mechanisms (e.g., DIGEST-MD5, SCRAM, YAP, SRP, etc.) (and a single clear text password) or b) PLAIN.
I thought it was invented because the existing scheme of '{hash method}' in userPassword broke the LDAP standard. Which it still does. Not that six years of none of us bothering to implement RFC 3112 gives much hope of that changing.
-- Regards, Hallvard
Kurt Zeilenga writes:
On Jul 15, 2007, at 6:59 AM, Hallvard B Furuseth wrote:
Pierangelo Masarati writes:
AFAIK, the attribute and so is recognized, but it's not implemented (nor won't, as it is no longer needed).
If it's no longer needed - what has changed?
The technical needs haven't changed. Folks now seem to be finally getting that they have a choice between: a) stronger (than PLAIN) authentication mechanisms (e.g., DIGEST-MD5, SCRAM, YAP, SRP, etc.) (and a single clear text password) or b) PLAIN.
I don't quite see the connection. Those are protocol matters, while {MD5} & co are about how the secret is stored on the server side. There are good reasons to use both variants, including security reasons. Simple Auth and PLAIN do not require data to be stored on the server side which is enough to authenticate to the server, short of a brute force search. Which admittedly is a *lot* cheaper now than a few years ago. DIGEST-MD5 and YAP (I think) do. I think SRP and SCRAM do not, but SCRAM is unfinished and the SRP SASL draft seems to have expired.
Hallvard B Furuseth wrote:
If it's no longer needed - what has changed? I thought it was invented because the existing scheme of '{hash method}' in userPassword broke the LDAP standard. Which it still does.
Simply no-one cares.
BTW: IIRC RFC 3112 also lacks a definition of charset encoding for textual strings. This was kinda solved for userPassword by an implementation hint in RFC 4519 requiring SASLprep/UTF-8 but not for the authPasswordSyntax.
http://www.openldap.org/lists/ietf-ldapbis/200110/msg00008.html
Ciao, Michael.
On Jul 15, 2007, at 2:49 PM, Michael Ströder wrote:
Hallvard B Furuseth wrote:
If it's no longer needed - what has changed? I thought it was invented because the existing scheme of '{hash method}' in userPassword broke the LDAP standard. Which it still does.
Simply no-one cares.
For multiple reasons, yes.
BTW: IIRC RFC 3112 also lacks a definition of charset encoding for textual strings. This was kinda solved for userPassword by an implementation hint in RFC 4519 requiring SASLprep/UTF-8 but not for the authPasswordSyntax.
In due time the other specifications will be appropriately updated.
The client is to use SASLprep/UTF-8 when using simple bind. When a client updates the password, whether by LDAP Password Modify or by LDAP Modify (of userPassword (hashed or not) or authPassword), they should also apply SASLprep/UTF-8.
http://www.openldap.org/lists/ietf-ldapbis/200110/msg00008.html
Ciao, Michael.
-
Gavin Henry -
Hallvard B Furuseth -
Kurt Zeilenga -
Michael Ströder -
Pierangelo Masarati