[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Compromise Authentication Proposal
Chris & John,
Well, I am beginning to lean towards TLS. Aside from the scalability, it
also provides me with Confidentiality services; i.e. the Client-server
session is encrypted. This is not only useful, but I could argue that it
is *required* for any administrator's client.
With TLS, it would seem to me, we are gaining:
1. A scalable and solid authentication mechansm.
2. COnfidentiality on the link between the client and server.
We may need this for replication protocols as well, so there is a good
reason for implementing it for clients.
Cheers, ....Erik.
At 11:27 05/10/98 -0700, Chris Newman wrote:
>On Fri, 2 Oct 1998, John C. Strassner wrote:
>> I fail to see how this is a compromise.
>>
>> Furthermore, for those sites/vendors that don't choose to implement the
>> mandatory-to-implement mechanism, what exactly are we accomplishing, other
>> than ensuring that such sites are not in conformance?
>
>Sites which choose not to _use_ the mandatory to implement mechanism have
>always been just fine. In doing so, they restrict their choice of clients
>and servers to those which implement the mechanism they do choose. No way
>to get around this regardless of what we do since there is no such thing
>as a one-size-fits-all authentication mechanism.
>
>Vendors which choose not to _implement_ the mandatory to implement
>mechanism are not compliant with the LDAP base spec, but may be compliant
>with the "LDAP applicability statement for large-scale-distribution
>sites". But given the mandatory to implement mechanism is so simple
>(probably about 1/100th the code necessary to implement X.509), I doubt
>many implementors will have a compelling need to avoid it.
>
>Vendors which choose to implement both the mandatory-to-implement
>mechanism and the profile for large-scale-distribution sites, will have an
>additional selling point which some customers may look for explicitly.
>I've seen customers give a list of RFCs for which they want support, thus
>having the profile for large-scale-distribution of LDAP in a separate RFC
>will help such customers.
>
>> What exactly was wrong with my compromise?
>
>You're proposing that all server vendors be required to implement TLS with
>full-strength encryption and client certs. The main problem I have with
>this is that client certs haven't proven to be generally useful in the
>field yet. Despite the fact most web browsers support client certs, few
>people use them -- cleartext passwords seem to be much more useful in
>practice even with the Internet-wide scope of web servers. Given the
>complexity of implementing client certs, I think that makes it premature
>to make them mandatory-to-implement, even for servers. There's also the
>export restriction issue, although it could be argued that's a good thing
>since it puts pressure on governments if the software companies in that
>country can't export compliant LDAP servers.
>
>Personally I think TLS is best at a SHOULD level for LDAP. There are a
>lot of compelling reasons both to implement it and not to implement it,
>but implementors really SHOULD if they can.
>
> - Chris
>
>
>