[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: comments on draft-ietf-ldapext-ldapv3-tls-01.txt
> > 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.
> >
> > Jeff Hodges responded:
> > 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.
>
> Jonathan Trostle <jtrostle@cisco.com> pointed out:
> 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?
Good point, it's not protected if done before integrity and/or confidentiality
is ensured on the connection.
This topic has been recently discussed in terms of IMAP (see below). It seems
to me that we should consider adding another subsection to section 4, along
these lines...
---------
4.7 Refresh of Server Capabilities Information
The client SHOULD refresh any cached server capabilities information (e.g.
from the server's root DSE; see section 3.4 of [LDAPv3]) upon TLS session
establishment. This is necessary to protect against active-intermediary
attacks which may have altered any server capabilities information retrieved
prior to TLS establishment. The server MAY advertise different capabilities
after TLS establishment.
---------
Although draft-newman-tls-imappop-04.txt doesn't seem to indicate the
connotations of the last sentence "The server MAY advertise different
capabilities after TLS establishment." It seems that that could be taken to
mean that the server legitimately updated its capabilities information once
TLS is started for that client, or it could mean that an active attacker
mucked with the originally retrieved capabilities info. I suspect that Chris
is intending the former connotation, but I'm not sure.
Also, we could perhaps update the security considerations section of
draft-ietf-ldapext-ldapv3-tls-01.txt to reflect user interface assertions
similar to those in draft-newman-tls-imappop-04.txt's security considerations
section.
Also, the final sec. considerations paragraph says..
"Server implementors SHOULD allow for server administrators to elect
whether and when connection confidentiality is required."
..and I think we should consider enhancing it like so..
"Server implementors SHOULD allow for server administrators to elect
whether and when connection confidentiality is required, as well as elect
whether and when client authentication via TLS is required."
Jeff
--------------------------------------------