[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: draft minutes from Chicago meeting
Tthis was also my (possibly misinformed) interpretation as well. While
I applaud the evolution of security in LDAP, I am still concerned about
my operational requirement to restrict access rights to information
(both user and operation) by roles.
Specifically, I will need to have (remote) ability to manage data by an
administrator (navigational context, DSA credentials, user data) and,
have separation for the modification (again remotely) for audit
information by an authorized agent.
I would really like to see the TLS functionality supported, and, the
authentication for role-based access controls included.
Sandi
>----------
>From: Ed Reed[SMTP:ED_REED@novell.com]
>Sent: Wednesday, September 30, 1998 12:06 PM
>To: ietf-ldapext@netscape.com; phil%jade@wg.icl.co.uk
>Subject: Re: draft minutes from Chicago meeting
>
>Sorry, no. The Mandatory to implement mechanism involving TLS does not,
>I believe, require there to be any such user certificate. Rather, startTLS
>simply indicates that the transport stream over which LDAP protocol data
>units are sent and received be switched onto a confidential (anonymous)
>connection provided by TLS, over which a simple bind (including user
>id and password) may be sent. The TLS provides anonymous confidentiality
>and ongoing connection data integrity, and nothing more...
>
>or am I mistaken?
>
>----------------------
>Ed Reed, Technologist
>Novell, Inc.
>+1 801 861-3320
>
>>>> "Phil Pinkerton" <phil%jade@wg.icl.co.uk> 09/30/1998 01:46:40 >>>
>Surely making TLS mandatory to implement as a SASL authentication mechanism
>implies that if this is all the server supports then all human clients
>wishing to be strongly authenticated must have a certificate (and private
>key) which, although maybe a future expectation, certainly isn't the case
>today.
>
>I suspect that most human clients today would be happy with an encrypted
>password technique like CRAM-MD5 to provide strong authentication. This
>could be combined with an encrypted, but not client authenticated, TLS
>session if full data confidentiality and integrity is required. Therefore,
>I would suggest that CRAM-MD5 (or its equivalent) is a more realistic SASL
>mechanism to mandate in real-world terms.
>
>Phil Pinkerton, ICL
>
>
>