3:59 p.m.
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.
--
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/
3:26 a.m.
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(a)sys-net.it
---------------------------------------
3:43 a.m.
<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(a)sys-net.it
---------------------------------------
6:59 a.m.
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.
--
Regards,
Hallvard
7:48 a.m.
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
9:46 a.m.
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
2:49 p.m.
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.
3:41 p.m.
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.
5805
days inactive
5806
days old
7 comments
5 participants
participants (5)
-
Gavin Henry -
Hallvard B Furuseth -
Kurt Zeilenga -
Michael Ströder -
Pierangelo Masarati