Subject: java api startTLS() method

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 03 Apr 2001 15:13:45 -0700

A few more questions regarding startTLS().

Does the startTLS() taking any action due to any outstanding
operations within the session it may be aware of?

During the processing of the startTLS() call, are there any
restrictions placed upon the connection and its clones?  In
particular, how would a call to issue some other to be handled?

How are referrals returned in response to the startTLS operation
handled?

> If the server does not support the transition to a TLS session,
> an LDAPException is thrown with the error code UNWILLING_TO_PERFORM.

I would think the API would return whatever non-success
result code was returned by the server in the LDAPexception.

Kurt

---

From: Rob Weltman <[email-masked]>
Date: Wed, 04 Apr 2001 09:02:40 -0700

> operations within the session it may be aware of?

  RFC 2830 says that a client MUST NOT attempt startTLS if there are any LDAP operations outstanding on the connection. If there are outstanding LDAP operations on the connection, an LDAPException is thrown (I see that 4.6.42 is missing the exception in its signature, although it is mentioned in the following description).

> restrictions placed upon the connection and its clones?

  No other operations may be issued on the connection during the processing of the call. An LDAPException is thrown if another operation is requested during the startTLS establishment.

  Clones are independent. Issuing startTLS dissociates a connection from its siblings.

>  In

  I'm not sure what that means. Maybe it is answered above.

> How are referrals returned in response to the startTLS operation

  RFC 2830 says:

   "If the server does not support TLS (whether by design or by current
   configuration), it MUST set the resultCode to protocolError (see
   section 4.1.1 of [LDAPv3]), or to referral. The server MUST include
   an actual referral value in the LDAP Result if it returns a
   resultCode of referral. The client's current session is unaffected if
   the server does not support TLS. The client MAY proceed with any LDAP
   operation, or it MAY close the connection."

  If the servere returns a referral, then startTLS returns an LDAPReferralException if the application is chasing its own referrals. If the API implementation is chasing referrals, it will do so also with a startTLS referral.

> result code was returned by the server in the LDAPexception.

  Yes.

Rob

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 04 Apr 2001 11:04:19 -0700

At 09:02 AM 4/4/01 -0700, Rob Weltman wrote:
>  RFC 2830 says that a client MUST NOT attempt startTLS if there are any LDAP operations outstanding on the connection.

Yes.  But the I-D did not make it clear whether this requirement
was the responsibility of the application, the API, or shared
between the two.

>If there are outstanding LDAP operations on the connection, an LDAPException is thrown (I see that 4.6.42 is missing the exception in its signature, although it is mentioned in the following description).

Okay, so the API takes on this responsibility.  That is reasonable
(but was not all that clear in the current I-D).

>  Clones are independent. Issuing startTLS dissociates a connection from its siblings.

I thought clones were only dissociated on disconnect().  Anyways,
why would the API dissociate upon startTLS and not SASL bind?  Both
can establish security associations and protections.

---

From: Rob Weltman <[email-masked]>
Date: Wed, 04 Apr 2001 11:55:52 -0700

> can establish security associations and protections.

  True. On bind, all clones are affected as if they were threads operating on the same connection object:

   "Reauthenticating in a clone, 
   however, is a global operation which will affect the source object 
   and all associated clones, because it applies to the single shared 
   physical connection. Any request by an associated object after one 
   has reauthenticated will carry the new identity."

Rob