[x500standard] Re: Password variants
- From: David Wilson <David.Wilson@xxxxxxxxx>
- To: x500standard@xxxxxxxxxxxxx
- Date: Tue, 22 Sep 2009 16:03:41 +0100
On Tue, 2009-09-22 at 14:17 +0100, David Chadwick wrote:
> Please let us have your comments on the above
I'm not sure if the 'Compare' column relates only to the need to chain a
compare when verifying the credentials for authentication in a bind, or
more general use of the compare operation to verify passwords?
Is case (2) actual encrypted passwords (i.e. there is a key involved),
or just hashed passwords?
I'm not sure what actual mechanism is implied by (4). The OTP mechanism
defined in RFC 2289 starts with a challenge from the server. This
includes the sequence number of the OTP to be generated. I.e. the state
of the password sequence is held in the server, and there is more state
for this than just the password. If the server does not communicate to
the client the state of the generator, then the client needs to keep
that information (and it will be different for each server to which it
connects).
Or is (4) basically a hashed password where the salt is changed each
time? (In which case the server needs to track all nonces used, to avoid
replay of captured credentials).
Is (6) assuming that the Kerberos server is also the DSA? My
understanding of Kerberos is that A wishing to talk to B sends a message
to that effect to the Kerberos server. The server sends back a token
which A then sends to B. The token is encrypted with the server's key
(so the server can unwrap it). So, rather than B verifying A's identity,
it trusts the Kerberos server (partly by being able to decrypt something
encrypted with the secret shared with that server).
The Kerberos server obviously needs access to both of the passwords for
this. However, with Kerberos there is no need to chain for
authentication, as the server is communicating not with other DSAs but
with the Kerberos server for this. I'm not sure how Compares would work,
if only the Kerberos server has the password.
For LDAP, SASL is the means for extended authentication schemes. Those
that use passwords generally need access to the password (or password
equivalent). So, some discussion of SASL would be appropriate in this
context.
A separate question is how SASL could be used when using X.500 over the
full OSI stack, when the bind and bind response are not operations as
such.
-----
www.x500standard.com: The central source for information on the X.500 Directory
Standard.
Other related posts:
