Subject: implicit bind - I-D java-api-11

From: "Steve Sonntag" <[email-masked]>
Date: Fri, 08 Sep 2000 12:23:01 -0600

I think the draft should describe more fully the
semantics of the implicit bind w/r automatic referral following:

I will describe what the I-D describes and where
I have questions:

1. Authentication - uses anonomyous credentials unless
   LDAPRebind specified in LDAPConstraints.

2. Protocol Version ?? - Does it use the same protocol
    version as the LDAPConnection receiving the referral or is it
    always V2??  I vote for the having it the same as the originating
    connection.

3. AuthenticationMethod: Is it the same as the originating connection,
    or is it "simple" - I assume simple is used.

4. Does it use the LDAPSocketFactory if specified on the
    originating connection.  I am not sure what to do here.
    It seems better to use it if available, then an encrypted
    connection can be established and thus prevent
    clear text password transmittion on the wire.  I just
    talked myself into it - it should be used.

-Steve

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 08 Sep 2000 12:16:05 -0700

>    talked myself into it - it should be used.

5. StartTLS ?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 08 Sep 2000 12:50:06 -0700

>   LDAPRebind specified in LDAPConstraints.

Don't chase would be the most secure default.

>    always V2??  I vote for the having it the same as the originating

If you got a referral/continuation, the originating server should
be LDAPv3 (unless this API supports LDAPv2+).  The referral/continuation
should be chased using LDAPv3 to avoid incompatible results issues.
Else the API need to provide either a) a mechanism to allow application
to determine the protocol used to obtain each result (which apps
are not likely to use) or b) convert to a common result format
(which requires schema knowledge).

In my opinion, mixing LDAPv2 and LDAPv3 just doesn't make sense.
The charset issues alone kill any chance of interoperability /
compatibility.  I suggest all mention/support for LDAPv2 be
axed.

>    or is it "simple" - I assume simple is used.

Yikes!  Simple authentication should not be used automatically.  I
suggest that no automatic chasing be allowed if the originating
connection used simple authentication.  I suggest that new session
MUST use same or better authentication method/mechanism.

>    talked myself into it - it should be used.

Use of non-TCP socket factories (e.g: ldaps://) should be out
of scope of this document.  No assumptions to the services
(other than a reliable byte stream) provided by the socket
factory should be assumed.  The 4.6.24 example should not
mention TLS.  It should state that socketFactory can be
used to support other transport services as allowed by
RFC2251, 5.2, but make no specific meantion of what these
might be (as there is no such Standard Track mapping defined).

Also, on the subject of TLS (in regards to Start TLS), some
discussion regarding behavior upon handling of TLS alerts
should be detailed.  It is also likely the application may
need accessor methods to obtain information from the TLS
layer.

Kurt