[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Authentication Methods for LDAP - last call
I really disagree with this notion of not mandating a particular mechanism.
I'd prefer to have the bar to high than not have one at all. I'm sure that
some won't believe it, but just having to implement CRAM-MD5 will be quite a
big deal for some folks.
> -----Original Message-----
> From: Jonathan Trostle [SMTP:jtrostle@cisco.com]
> Sent: Wednesday, August 05, 1998 10:06 AM
> To: howes@netscape.com; S.Kille@isode.com
> Cc: Chris.Newman@INNOSOFT.COM; ietf-ldapext@netscape.com
> Subject: Re: Authentication Methods for LDAP - last call
>
> I agree with Steve and John w.r.t. not mandating a particular mechanism.
> The
> market will ultimately decide the mechanisms needed for interoperability
> (e.g.,
> a web server needs to support SSL). The main benefit of using open
> standards for
> security is that the specification can be examined by many people and
> obvious
> security holes can be discovered.
>
> Jonathan
>
> > X-SMAP-Received-From: outside
> > Resent-Date: Wed, 5 Aug 1998 00:43:05 -0700 (PDT)
> > From: Steve Kille <S.Kille@isode.com>
> > To: Tim Howes <howes@netscape.com>
> > Cc: Chris Newman <Chris.Newman@INNOSOFT.COM>, ietf-ldapext@netscape.com
> > Subject: Re: Authentication Methods for LDAP - last call
> > Date: Wed, 5 Aug 1998 02:44:51 -0500 (Central Daylight Time)
> > X-Authentication: none
> > MIME-Version: 1.0
> > Resent-Message-ID: <"KFAjs1.0.vH6.7q0or"@glacier>
> > Resent-From: ietf-ldapext@netscape.com
> > X-Mailing-List: <ietf-ldapext@netscape.com> archive/latest/619
> > X-Loop: ietf-ldapext@netscape.com
> > Resent-Sender: ietf-ldapext-request@netscape.com
> >
> > Tim,
> >
> > I'd like to respond briefly to your summary. To me, John Strassner's
> > rebuttal of Chris Newman's message sets out clearly the case against a
> > single mandtory authentication mechanism.
> >
> > Basic LDAP client/server interoperability can be and is achieved
> > without authententication. I cannot see what specifying this single
> > mandatory mechanism achieves.
> >
> > If I had to pick a single mechanism it would be X.509 based. Kerberos
> > would be better than CRAM-MD5.
> >
> > Making CRAM-MD5 mandatory will promote an approach which a lousy choice
> > for many many environments.
> >
> > To me the clear conclusion is that there should not be a mandatory
> > mechansism.
> >
> >
> > Steve Kille
> >
> >