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

[RL Bob Morgan <Bob.Morgan@Stanford.EDU>]

> ---------
> 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.

I think that the "MAY advertise different capabilities" phrase is intended
to permit the server to modify its advertised capabilities depending on
whether the client has established TLS (or any other security state,
ultimately) or not, despite this assertion in the main IMAP protocol doc:

      The CAPABILITY command requests a listing of capabilities that the
      server supports.  The server MUST send a single untagged
      CAPABILITY response with "IMAP4rev1" as one of the listed
      capabilities before the (tagged) OK response.  This listing of
      capabilities is not dependent upon connection state or user.  It
      is therefore not necessary to issue a CAPABILITY command more than
      once in a connection.

I think the corresponding text from 2251 is:

   3.4. Server-specific Data Requirements

   An LDAP server MUST provide information about itself and other
   information that is specific to each server.  This is represented as
   a group of attributes located in the root DSE (DSA-Specific Entry),
   which is named with the zero-length LDAPDN.  These attributes are
   retrievable if a client performs a base object search of the root
   with filter "(objectClass=*)", however they are subject to access
   control restrictions.

So LDAP already permits the server to modify the root DSE search results
depending on connection state, so I don't think any text to this effect is
needed in the ldapext-tls doc.

> 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.

I strongly agree that consistency between the IMAP/POP/ACAP spec for use
of TLS and the LDAP spec for use of TLS is a good thing.

> ..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."

Yup.

 - RL "Bob"