Draft:  draft-ietf-ldapbis-authmeth-18.txt
Reviewer: Spencer Dawkins [spencer@mcsr-labs.org]
Review Date: Sunday 1/8/2006 12:13 AM CST
LC Date: 1/20/2006

Summary: This document is almost ready for publication as Proposed Standard. 
I might also add that it is unusually well written and well organized (nice 
work! I wish all drafts were this well-prepared at Last Call time). I have a 
few questions, but only the 6.2 question below seems important.


Details:
--------

3.1.3. Server Identity Check

   If the server identity check fails, user-oriented clients SHOULD
   either notify the user (clients may give the user the opportunity to
   continue with the LDAP session in this case) or close the transport
   connection and indicate that the server's identity is suspect.
   Automated clients SHOULD close the transport connection and then
   return or log an error indicating that the server's identity is
   suspect or both.

On each of these SHOULDs, it would be nice to add a sentence explaining why 
the requirement is not a MUST (in what circumstances might a client take 
another action appropriately?).

3.1.4. Discovery of Resultant Security Level

   After a TLS layer is established in an LDAP session, both parties
   are to each independently decide whether or not to continue based on
   local policy and the security level achieved.  If either party
   decides that the security level is inadequate for it to continue, it
   SHOULD remove the TLS layer immediately after the TLS
   (re)negotiation has completed (see [Protocol] section 4.14.3 and
   section 3.2 below).  Implementations may reevaluate the security
   level at any time and, upon finding it inadequate, should remove the
   TLS layer.

OK, I am not skilled in the art of TLS, but am wondering how why 3.1.3 
"closes the transport connection", 3.1.4 "removes the TLS layer", and 3.3 
"closes the TLS layer". Are these each separate choices, or are any two of 
them synonyms? (If they are all different, I'd like to understand why three 
different actions were chosen for what look like fairly similar situations; 
if any two of them are synonyms, I'd like for the terminology to be the 
same).

5.1.2. Unauthenticated Authentication Mechanism of Simple Bind

This section uses the term "empty password", which is qualified in both 
5.1.1 (the previous section) and 5.1.3 (the following section as something 
like "an OCTET STRING password value of non-zero length" - but it's not 
qualified in 5.1.2. It would be nice to qualify precisely in 5.1.2 as well.

6.2. StartTLS Security Considerations

   Clients SHOULD by default either warn the user when the security
   level achieved does not provide an acceptable level of data
   confidentiality and/or data integrity protection, or be configured
   to refuse to proceed without an acceptable level of security.

It seemed odd that this is a SHOULD (when is it appropriate to continue with 
unacceptable confidentiality/integrity protection without either warning the 
user or refusing to proceed?).

Editorial (NOT part of the technical review):

1. Introduction

   Threats (1), (4), (5), (6), (7) are (8) are active attacks.  Threats
   (2) and (3) are passive attacks.

s/) are (/) and (/