Subject: [ldapext] comment control, dummy request, no-response request

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 22 Feb 2005 23:30:55 +0100

"Comment" control:

It can be useful to attach a comment to an LDAP request.
The intent would be to log the comment with the request in
the server log, to help analyze the logs.

Does a spec for such a control exist?  If not I'd like to
define and implement it.

I'm not sure how to define the controlValue, though.  Usually an
LDAPString would be natural, but sometimes one may want to attach data
with no defined or known character set.  So a plain OCTET STRING might
be better, to be interpreted at the server admin's discretion.
Or one could mix both to make pretty logging a bit simpler in the
case it is an UTF-8 string:

   CHOICE {
     text    [0] LDAPString,
     octets  OCTET STRING,
     ...
   }

"Dummy" extended operation:

Has anyone defined a dummy extended operation, which does nothing except
whatever the attached extensions say?  If not, would anyone else like to
see it defined?

A client can want do issue a request solely for the sake of the attached
controls.  To enter a note in the log with the "comment" control.  To
test if the currently bound user can proxy for a given authorization ID
with the Proxy Authorization Control (draft-weltman-ldapv3-proxy-12.txt).
To use the "assert" control (draft-zeilenga-ldap-assert-05.txt) if one
wants to check an entry against a filter and the compare operation is
insufficient.  Using "assert" instead of baseobject search avoids one
returned PDU.  I suppose such an operation could at times also be useful
to keep the server from timing out the LDAP connection.

ExtendedRequest.requestValue, if present, would be an LDAPDN packed in
the requestValue OCTET STRING, so that controls that act on a DN will
know which DN to act on.

"No-response, dummy" operation:

This one is pretty marginal.  I could define such an operation too if
anyone feels a need for it, but otherwise I won't bother.

For use with the comment control, it could be convenient with a dummy
operation which did not return a response.  I can't think of other
instances to desire a dummy no-response operation at the moment.

ExtendedRequest does not support no-response operations.  One could
define a new request type, or fake it with abandon of an unused message
ID (e.g. msgID 0), or define a critical control which cancels the effect
of Abandon.  Kurt's "noop" control could be extended to be used with
Abandon, but that would probably only be useful with no-effect controls
like "comment".  So that usage seems even more marginal.

Comments?

-- 
Hallvard

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 24 Feb 2005 08:51:16 -0800

>It can be useful to attach a comment to an LDAP request.

For what purpose?  Tracing or other?

>the server log, to help analyze the logs.

Sounds like tracing to me.

(The point of me asking the above question is to have you
narrow the purpose of the control to one thing.)

>Does a spec for such a control exist?  If not I'd like to

I'm not aware of such.  I suggest you call it the "trace"
control (a control which provides "trace information).
I can see providing trace information useful in a number
of applications, namely in testing.

>I'm not sure how to define the controlValue, though.

I would suggest the controlValue as holding an LDAPString
providing arbitrary trace information.

>Usually an
>with no defined or known character set.

Hmmm... if more information than a character string is desirable,
I'd argue that the application being served likely should use
a different control specifically designed for its needs. 

>So a plain OCTET STRING might

I rather say that the information provided is to only be used
for trace purposes and is not to be otherwise interpreted or
used.

>whatever the attached extensions say? If not, would anyone else like to

I am not sure this makes sense, which I will illustrate below.

>with the Proxy Authorization Control (draft-weltman-ldapv3-proxy-12.txt).

Well, say there was an operation which did nothing.  A server
might allow anyone to do nothing, and allow anyone to proxy as
anyone as long as nothing was being done.  That is, the authorization
model may only have an impact when something is being done,
or some piece of information is being accessed.

And, in particular, the user cannot assume simply because:
        nothing+proxied(u:foo)
was successful that:
        something+proxied(u:foo)
will not fail (with any error specific to the proxied authorization
control, or otherwise).  That is, one cannot (in general)
reliably use the results of one operation to predicate the outcome
of another operation.  A notable exception (with limitations and
caveats) is an operation with noop v. that operation less no-op.

>the requestValue OCTET STRING, so that controls that act on a DN will

Why not just use a compare(dn,ObjectClass,"top")?

But note that compare+proxied(authzid) success does not imply
that some other operation (including other compares) +proxied(authzid)
will not fail with a proxy authorization failure.

>ExtendedRequest does not support no-response operations.

A specification is free to utilize ExtendedRequest in design
of a no-response operation.  It would not be an "Extended Operation"
as defined in [Protocol], as that described as having a response.
But there is no text in [Protocol] that precludes the use of
ExtendedRequest in design of response-less operations.

To put it another way, the LDAP TS does not limit the scope
and/or nature of extensions to LDAP.

>One could

I think it generally unwise to attach semantics onto
operations created through use of controls which are not
consistent with the base operation.   Seem you'd need a
new operation here.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 24 Feb 2005 20:31:45 +0100

> For what purpose?  Tracing or other?

That's the use which prompted this suggestion, yes.

> (...)

I was thinking in just the opposite way: Make the wording reasonably
general and not a "just for me" control, as long as it's basically a
no-op:-)

> (...) I suggest you call it the "trace" control (a control which
> provides "trace information).  I can see providing trace information
> useful in a number of applications, namely in testing.

Right.  Will do.  In fact, I grumbled over the name "comment" because
that didn't quite say what I wanted.

>> Usually an LDAPString would be natural, but sometimes one may
>> want to attach data with no defined or known character set.
>

I disagree with that, but after writing up the reason I ended up
agreeing with LDAPString anyway:-)

I disagree because one wants to log enough data to analyze what's going
on.  In my case I expect to log web search number, anonymized user ID,
user IP address and search string.  That can of course be encoded as an
LDAPString, but it is really data, not just text.  Or one might want to
log the exact user input for a search with its original character
encoding.  Transforming to an UTF-8 LDAPString can lose information.

However, after all a log is normally textual, so the trace info must be
represented as text in the log.  The client could just as well make it
textual as the server, e.g. base64-encode any raw data.  That keeps it
simple, and doesn't leave the server implementor wondering if it would
be good to sometimes log the trace info in base64 instead of as a
string, or whatever.

> for trace purposes and is not to be otherwise interpreted or

While I'd like to say somehow that the trace info is to have no "real"
effect (your "not otherwise...used"), I'm a bit leery of that.  I was
thinking more of something like "is not intended to be otherwise
interpreted or used".

E.g. the server itself could do some of the testing you mentioned and
react to the results.  Though in that case I don't suppose it's a
problem when a server during testing doesn't act quite according to the
spec.

After the talk about dummy operation + access controls, I've realized
that there should be configurable restrictions on this control, maybe a
form of access controls.  Otherwise anyone could spam the log with
massive trace info.  Normal access contols are no help, since failed
operations should still log the trace info.

> or some piece of information is being accessed.

I don't see the problem with that when it does nothing.

If it does something due to attached controls, those controls should be
subject to access controls.  But that's true for the controls if they
are attached to other operations as well, so it doesn't seem different.

Except there might be controls that do something which does not fit the
server's access control model, so one can only prevent them by
preventing all operations they are appropriate for.  StartTLS could have
the same problem, since that doesn't act on any entry either.  If so,
one could suggest that servers may use access restrictions on the dummy
operation if they want, e.g. "detect" access if that is implemented, and
use some arbitrary DN configured by the server for access control if no
DN is provided with the request.

> control, or otherwise).
> That is, one cannot (in general) reliably use the results of one
> operation to predicate the outcome of another operation.
> A notable exception (with limitations and caveats) is an operation
> with noop v. that operation less no-op.

True enough.  The noop control can test if a particular operation will
work, an authorization test can indicate that a group of operations will
surely fail.  And the user may know the particular directory well enough
to be aware that if the test doesn't fail, he should have access to the
other operations.

> Why not just use a compare(dn,ObjectClass,"top")?

Mostly just for clarity (e.g. in the log) and efficiency, though one
might lack access to compare objectClass or the entry itself.  Just as
I've seen searches for "(objectClass=*)" find nothing where "(&)"
succeeded.

(For the Trace control, compare(dn="", attr="1.1", val="") might be
preferable if there is no dummy operation: It's clearly not trying to
do anything sensible.  Or abandon(msgid=0), as I mentioned before.)

> ExtendedRequest in design of response-less operations.

Not that I can see.  RFC 2251 says:

   The server will respond to this with an LDAPMessage containing the
   ExtendedResponse.

>> One could define a new request type, or fake it with abandon of an
>> unused message ID (e.g. msgID 0), or define a critical control which
>> cancels the effect of Abandon.  Kurt's "noop" control could be
>> extended to be used with Abandon, but that would probably only be
>> useful with no-effect controls like "comment".  So that usage seems
>> even more marginal.
>
> consistent with the base operation.

True enough.

> Seem you'd need a new operation here.

Only if anyone sees a greater need for it than I do:-)

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 27 Feb 2005 09:17:26 -0800

>general and not a "just for me" control, as long as it's basically a

I prefer to limit its use to tracing. I rather it not be used
in support of other applications (as that demises its usefulness
in tracing).  That is, I rather servers not attach semantics
to the information (as they likely would if it the data was
structured).

I note that we likely want to allow multiple instances of the
control to be attached to a message.

>be good to sometimes log the trace info in base64 instead of as a

Keeping the structure out of the protocol is good as it implies
servers (themselves) should not take actions based upon content of
the information.  They should just provide it to consumers of the
trace information (via whatever mechanism suites them).

>thinking more of something like "is not intended to be otherwise

Something like:
        The trace information has no semantical value in the
        protocol.  That is, this control does not change the
        meaning of the message it is attached to.

>operations should still log the trace info.

Basically, if the trace information is logged to a consumable
resource, unrestricted logging can easily lead to denial of
service.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 27 Feb 2005 20:13:00 +0100

> to the information (as they likely would if it the data was

OK.  Makes sense.

> control to be attached to a message.

"The order of multiple trace controls in a request SHOULD be preserved."

>         meaning of the message it is attached to.

Nice.

s/semantical/semantic/, I think.

-- 
Hallvard