Re: [RFR] English debconf templates for nss-pam-ldapd

[Justin B Rye <jbr@edlug.org.uk>]

Arthur de Jong wrote:
> Justin B Rye wrote:
>>>   * none: no authentication;
>>>   * simple: simple clear text binddn/password;
>>>   * SASL: one of the Simple Authentication and Security Layer
>>>           mechanisms.
>> 
>> Does it really mean "cleartext"?  It can't be "clear text" (asking for
>> a text password instead of... what?), and if it really means "stored
>> without encryption" it should say so more directly.  And what's
>> "binddn/password"?  Should it perhaps be:
> 
> It means that the password is sent to the LDAP server in plain text (as
> opposed to the challenge-response mechanisms that are available in
> SASL). A side-effect of this is that the password also needs to be
> stored in plain text on the client side.
> 
> A binddn is basically a user name in LDAP speak. binddn/password is
> meant to refer to the combination (like username/password).

So "binddn and password" might be clearer.  Or is it bind DN, or
BindDN, or what?  The term seems a rather gratuitous piece of LDAPese
for what could equally well just be referred to as a "login".  After
all, it makes no difference to users whether the username is stored
in a field labelled "BINDDN", "nom", or "VictimID" - what matters is
just that it functions as a username (and the password to go with it
is unencrypted). 

And even if I choose SASL, does that mean that there won't be a
BindDN?  If the LDAP database still uses one and just delegates the
login authentication, that makes mentioning BindDNs as a way of
distinguishing authentication types a red herring.

> Some Google searches suggest "stored in plain text" is the most popular
> of the variations (I generally prefer the democratic spelling). RFC 4616
> calls PLAIN "a simple clear-text user/password Simple Authentication and
> Security Layer (SASL) mechanism".
> 
> Should I change all "clear text" to "plain text"?

Please don't.  It's true that people confuse "cleartext", "clear
text", "plaintext", and "plain text", but see for instance
http://en.wikipedia.org/wiki/Plaintext:

        This article is about cryptography. For the computing term
	meaning the storage of textual material that is (largely)
	unformatted, see plain text.

	In cryptography, plaintext is information a sender wishes to
	transmit to a receiver. Cleartext is, confusingly, often used
	as a synonym. Before the computer era, plaintext most commonly
	meant message text in the language of the communicating
	parties. Plaintext has reference to the operation of
	cryptographic algorithms, usually encryption algorithms, and
	is the input upon which they operate. Cleartext, by contrast,
	refers to data that is transmitted or stored unencrypted (that
	is, 'in the clear').

We don't want to tell users that the password is mimetype text/plain,
or that they should enter it as plaintext; in principle we don't even
mean that it necessarily travels as cleartext (see below).  So at
present I'm thinking the best option is something like:

   * simple: basic password authentication (stored unencrypted);

>>>   * LOGIN: deprecated in flavor of PLAIN;
>>>   * PLAIN: simple cleartext password mechanism;
>> 
>> s/cleartext/unencrypted/
> 
> I think unencrypted is confusing because you can still use SSL to
> encrypt the network traffic which is separate from the login mechanism.

Well, if you use SSL it doesn't travel as cleartext, does it?  Still,
if we've gone to the trouble of explaining "simple" authentication as
"stored unencrypted" in ldap-auth-type I suppose we're entitled to say
just "cleartext" here if we like.

>>> Template: nslcd/ldap-sasl-realm
[...]
>>>  If empty, the GSSAPI mechanism will use information from the Kerberos
>>>  credential cache. Others mechanisms may need @<REALM> suffixing sasl_authcid
>>>  and sasl_authzid.
>>>  .
>>>  The realm is appended to authentication and authorisation identities.
>> 
>> Unfortunately I'm having trouble rewriting that paragraph because I
>> just don't understand the second sentence at all.  Other mechanisms
>> may need... what?
> 
> I've removed the second paragraph and added the Kerberos note as a third
> paragraph which should be a bit clearer (but I must say I'm no expert in
> the fields of SASL, GSSAPI and Kerberos).

"For GSSAPI this can be left blank to use information from the
Kerberos credential cache."  Yes, fair enough.
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package