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

> > [email protected] 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 <[email protected]> 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

		--------------------------------------------

Date: Wed, 15 Jul 1998 17:39:03 -0700
From: John Gardiner Myers <[email protected]>
To: [email protected]
Subject: Re: Unsolicited CAPABILITY response

If the client and server negotiate a SASL security layer, it is
important for the client to discard its information about server
capabilities and re-issue the CAPABILITY command.  Otherwise, an active
attacker could fool the client by inserting or modifying a CAPABILITY
response before authentication completes.  For this reason, the STARTTLS
extension in draft-newman-tls-imappop-04.txt explicitly modifies the
don't-change-CAPABILITIES requirement of the base IMAP specification.


		--------------------------------------------

Date: Thu, 16 Jul 1998 15:59:18 -0700 (PDT)
From: Chris Newman <[email protected]>
To: [email protected]
Subject: Re: Unsolicited CAPABILITY response

On Wed, 15 Jul 1998, John Gardiner Myers wrote:
> If the client and server negotiate a SASL security layer, it is
> important for the client to discard its information about server
> capabilities and re-issue the CAPABILITY command.  Otherwise, an active
> attacker could fool the client by inserting or modifying a CAPABILITY
> response before authentication completes.  For this reason, the STARTTLS
> extension in draft-newman-tls-imappop-04.txt explicitly modifies the
> don't-change-CAPABILITIES requirement of the base IMAP specification.

That draft only waives the requirement after the "STARTTLS" command is
issued:

      Once TLS has been started, the client SHOULD discard cached
      information about server capabilities and re-issue the CAPABILITY
      command.  This is necessary to protect against man-in-the-middle
      attacks which alter the capabilities list prior to STARTTLS.  The
      server MAY advertise different capabilities after STARTTLS.

Since the purpose of STARTTLS is to protect against active attacks, it
would defeat the purpose if the client trusted information from before the
STARTTLS command.  The last sentence is added incentive to do the right 
thing.  Incidentally, this language needs to be put in the base spec for
the case where a security layer is negotiated by SASL, for the same
reason.

		- Chris

		--------------------------------------------