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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 12:23 PM 9/8/00 -0600, Steve Sonntag wrote:
> 
>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.

Don't chase would be the most secure default.

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

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.


>3. AuthenticationMethod: Is it the same as the originating connection,
>    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.

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

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