Re: comments on draft-ietf-ldapext-ldapv3-tls-01.txt

[Jonathan Trostle <jtrostle@cisco.com>]

> X-SMAP-Received-From: outside
> Resent-Date: Thu, 23 Jul 1998 13:00:59 -0700 (PDT)
> Subject: Re: comments on draft-ietf-ldapext-ldapv3-tls-01.txt 
> To: Helmut.Baumgaertner@mch.sni.de (Helmut Baumgaertner)
> cc: "ietf-ldapext@netscape.com LDAPEXT" <ietf-ldapext@netscape.com>
> X-UIDL: 901237341.172
> From: Jeff.Hodges@stanford.edu
> X-Office: Pine Hall Rm 161; +1-650-723-2452
> Mime-Version: 1.0
> Content-Transfer-Encoding: quoted-printable
> Date: Thu, 23 Jul 1998 13:00:46 -0700
> Resent-Message-ID: <"rztwW1.0.vb5.vPvjr"@glacier>
> Resent-From: ietf-ldapext@netscape.com
> X-Mailing-List: <ietf-ldapext@netscape.com> archive/latest/533
> X-Loop: ietf-ldapext@netscape.com
> Resent-Sender: ietf-ldapext-request@netscape.com
> 
> Thanks for the comments Helmut.
> 
> Helmut.Baumgaertner@mch.sni.de said:
> > Any particular reason for not using authMethodNotSupported as the
> > resultCode in case the  LDAP server does not support TLS and cannot
> > return a referral.   
> 
> Yes, the reasons we designed it like this are that..
> 
> - TLS isn't necessarily an authentication method. It of course ~can~ be, but 
> isn't by default.
> 
> - the client may be trying to send the operation to an LDAPv2 server, and it 
> will hopefully respond with a protocolError -- so we're trying to keep the 
> semantics consistent.
> 
> Plus, a v3-capable client may ascertain whether the server it is talking with 
> supports StartTLS by querying the server's root DSE for the supportedExtension 
> attribute and checking to see that StartTLS is listed.
> 

Presumably the client wants to use TLS because the wire is not trusted; how is 
the querying of the server's root DSE for the supportedExtension attribute and 
checking for StartTLS protected?

Jonathan