Re: draft minutes from Chicago meeting

[Phil Pinkerton <phil%jade@wg.icl.co.uk>]

This is a reasonable approach Ed and simple enough for clients to implement
but surely the performance overhead is excessive if all that is required is
strong authentication and not data confidentiality.

Regards, Phil


-----Original Message-----
From: Ed Reed <ED_REED@novell.com>
To: ietf-ldapext@netscape.com <ietf-ldapext@netscape.com>;
phil%jade@wg.icl.co.uk <phil%jade@wg.icl.co.uk>
Date: 30 September 1998 17:49
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