Subject: unsolicited controls (Was: I-D ACTION:draft-weltman-ldapv3-auth-response-01.txt)

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 09 Feb 2000 10:08:22 -0800

I like to voice a general concern about unsolicited response
controls.  That is, controls provided by servers without the
client implicit or explicit solicitating the control.

I believe we should discourage unsolicited controls in responses.

As the number of such controls increase, which is inevidable,
clients and networks will be overloaded with unneeded information.
It would prudent, IMO, to provide and encourage use of client
solicatation of desired information.  That is, our general
protocol model is one of client request/server response.  I
see no overriding reason why this particular control should
not be sent without solicitation.

I suggest that this response control be explicitly solicited
by the client via a request control.

	Kurt

---

From: [email-masked] (David Boreham)
Date: Wed, 09 Feb 2000 10:11:02 -0800

Examples ?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 09 Feb 2000 10:53:19 -0800

>Examples ?

draft-weltman-ldapv3-auth-response-01.txt
draft-behera-ldap-password-policy-00.txt

I feel the client should be required to take some explicit
action before the returns any response not described by
the core specifications.  This act may be an explicit
request control, a control upon bind enabling the behavior
for the "session", an extended operation enabling the behavior,
or some other form of solicitation.

I feel a server should not respond with controls and/or
extended responses not detailed by the core specifications
without such solicitation.

That is, the client should
	1) discover what protocol extensions are supported by the server
	2) enable desired extensions

A server should:
	1) published supported extensions
	2) disable all extensions until enabled by the client

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 09 Feb 2000 10:58:51 -0800

I suggest noting explicitly in Security Considerations that the
control is not protected by the SASL privacy or integrity
protection negotiated by the BIND process returning this control.
A client requiring such protection must rely on independent
services, such as TLS or IPSEC, or use some operation after
negotiating SASL protection services.

Because of this consideration, I can see the need for an extended
operation to obtain authorization information post BIND.

BTW, what's the intended track of this document?  I suggest
adding a note to the draft indicating your intent.

---

From: [email-masked] (Rob Weltman)
Date: Wed, 09 Feb 2000 11:11:55 -0800

Per previous messages: I originally proposed something more along the lines of what you have suggested - a control or extended operation which could be issued at any time to query the authentication identity of a connection. Mark Wahl had a strong argument at the time (a year ago) for why it would be better to have an unsolicited control returned on bind. I don't remember what that strong argument was... Maybe Mark can add to this discussion.

> negotiating SASL protection services.

  That could be added, but note that the information being returned in the control is not a password, but just the identity (DN) of the authenticated connection.

> adding a note to the draft indicating your intent.

  It depends a little on the interest among participants on this list.

Thanks,
Rob

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 09 Feb 2000 11:25:55 -0800

>  That could be added, but note that the information being returned in the control is not a password, but just the identity (DN) of the authenticated connection.

I am specifically concerned that the DN returned may be modified
in transit or by man in the middle and the client may assume
incorrectly that the information is protected by services
negotiated during the bind operation.

I believe any specification of a control passed in a Bind
Request or Response should have a explicit security consideration
statement that control is not protected by services which the
Bind may or may not negotiate.

---

From: [email-masked] (Mark C Smith)
Date: Wed, 09 Feb 2000 14:25:32 -0500

> adding a note to the draft indicating your intent.

Good point.  You raised this before but we neglected to address it.  I
think this should be a standards track document, i.e., if a server is
going to return authentication information this is how it should do it
(subject to revision and debate about issues such as whether the client
must request the information, etc. of course).  My point is that we
should have one way of returning this information so that if a server or
client needs this feature they can count on it being implemented in just
one way from a protocol perspective.

-- 
Mark Smith
Directory Product Development / iPlanet E-Commerce Solutions
My words are my own, not my employer's.            Got LDAP?

---

From: [email-masked] (Rob Weltman)
Date: Wed, 09 Feb 2000 11:30:29 -0800

> Bind may or may not negotiate.

I see. Thanks for pointing that out. The response is returned before any session protection takes effect, so it is more exposed than any other data-carrying LDAP response.

Rob

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 09 Feb 2000 15:14:40 -0800

RFC 2251, 4.4 (unsolicited notifications) says:
   It [an unsolicited notification] is used to signal an
   extraordinary condition in the server or in the connection
   between the client and the server

I believe the same should apply to unsolicited controls:
  An unsolicited response control is used to signal an
  extraordinary condition with the operation.

That is, the fact that an identity is authorized is by a
operation bind is quite ordinary and hence a client shouldn't
be notified of the identity unless explicitly requested.

Kurt