From ldapext-bounces@ietf.org Mon Feb 21 01:47:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29628 for ; Mon, 21 Feb 2005 01:47:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D36k0-0000lJ-Ca; Mon, 21 Feb 2005 01:08:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D36eq-00079S-3O for ldapext@megatron.ietf.org; Mon, 21 Feb 2005 01:03:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26652 for ; Mon, 21 Feb 2005 01:02:54 -0500 (EST) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D370x-0006ZQ-RZ for ldapext@ietf.org; Mon, 21 Feb 2005 01:25:52 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Sun, 20 Feb 2005 23:02:21 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta Date: Sun, 20 Feb 2005 23:02:02 -0700 From: "Jim Sermersheim" To: Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec Cc: Kurt@OpenLDAP.org, ldapext@ietf.org Subject: [ldapext] Re: Comments to X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0817132932==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0817132932== Content-Type: multipart/alternative; boundary="=__Part0023564A.0__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part0023564A.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Thanks for the feedback, I've updated the I-D and will submit. I think I addressed everything except the question about criticality. For criticality, the instructions in 4.1.11 of http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-30.txt. Basically, if the server understands the control, the criticality is ignored and the control is honored. If the control is not understood, then criticality determines whether the control is ignored or causes the operation to fail. Jim >>> Pierangelo Masarati 1/25/05 3:03:05 PM >>> Jim, I'm currently implementing the (now expired) version 02 of in OpenLDAP based on the "chain" overlay as first implemented by Howard Chu and subsequently extended by myself. What follows is a collection of considerations that emerged from the implementation and that, perhaps owing to my lack of understanding of some details, I think require a clarification and might be useful for the continuation of the work on the draft. The comments are quite unsorted. 1. Comments 1.1. Return code renaming I suggest to change the name of "chainingRequired" into "requiresChaining" to avoid confusion and symbol clashes with the "requiresChaining" value in the "Behavior" enumeration. 1.2. Return code usage clarification I think you should clarify when the special return codes related to the control need be returned. For instance, if behavior is "chainingRequired" and the operation would return a referral that cannot be chased, I'd return "cannotChain", but for any other "Behavior" case returning a referral is acceptable, and returning a referral is not an error: lists "referral" as a non-error result code in Appendix A.1, so I don't see an application for the other error code you indicate ("chainingRequired"). I suggest you clarify your intentions. 1.3 OPTIONAL values and defaults In the draft, both "Behavior" fields are marked as OPTIONAL. My point is: what's the reason for not providing any? For instance, the "chain" overlay in OpenLDAP's slapd by default acts as if both "Behavior" were "chainingPreferred". If the control is present, but no values are given, I see no point in using the control. Unless you mean that the default behavior of the DSA may differ if the control is present or not; e.g. if no control is present, default to "referralsRequired", while if the control is present, default to "chainingPreferred" (OpenLDAP's slapd without and with the "chain" overlay), and in any case both defaults are left to the implementor. If this is the case, I suggest it is clarified. [technical note: it is not clear to me if, in case none of the values is provided, the crtls_value of the control structure should be empty or null]. 1.4 Operations. It appears from the draft that the control applies to all operations, except "abandon, unbind, and StartTLS"; the second value applies only to search continuations, and may apply to future operations. Should the presence of the second value in other operations among those already defined that do not require it be treated as an error? I think this should be clarified. 1.5 Behavior 1.5.1. "chainingPreferred" and "referralsPreferred" don't present any issue; 1.5.2. "chainingRequired" might be an issue if, in case it cannot be honored, no intermediate results should be returned at all (I'm talking about searches). In fact, unless caching all intermediate results locally upon completion, it is very likely that a referral is met after some entries/other intermediate results have already been returned. If the referral cannot be chased, the operation should be terminated and "cannotChain" be returned. I think it should be clarified if this behavior is acceptable or not. 1.5.3 "referralsRequired" should never fail, because that's the regular behavior in case no chaining capabilities are available; I don't see any issue that might prevent a DSA from returning a referral. Can you clarify why this option is ever supposed to fail? 1.6. Criticality I think the behavior should be discussed in view of the criticality of the control. Would it be correct to simply ignore the "Behavior" in case the control is not critical? It is my understanding that only the "chainingRequired" behavior may suffer from the criticality field being set when referrals cannot be chased; the other options should pose no issues. How should the behavior differ in this case based on the value of the criticality flag? 2. Few notes on the implementation. 2.1. Approach The "chain" overlay in OpenLDAP's slapd uses the LDAP backend to chase referrals in case they're being returned by the underlying backend (or at the frontend level, if used as a global overlay). Credits for both the overlay and the underlying LDAP backend essentially go to Howard Chu. 2.2. Authorization and Security As such, it can exploit the identity assertion capabilities of back-ldap to proxyAuthz the identity of the client while chasing the referral; this provides features like SASL bind, authorization policies based on pattern matching, grouping and so both at the local and at the remote site. The connection can be wrapped in a TLS layer (use ldaps:// referral URIs, or StartTLS over regular ldap:// URIs). 2.3. Relationship with other extensions Interaction with the "manageDSAit" control as described in the draft, although not intended, seems to work as described in the draft. Of course it may need further testing. 2.4. Missing features and possible development I plan to introduce: 2.4.1. authorization based on referral suffix (e.g. only chain requests rooted at ) 2.4.2. authorization based on the referral URI (host/port portion) 2.4.3. authorization based on the protocol scheme (e.g. only ldaps://) 2.4.4. authorization based on some ssf 2.4.5. to allow chaining of multiple DSAs, back-ldap's identity assertion must be modified to allow authentication identity selection based on the DSA that is being chained (now a single identity can be specified, since back-ldap is intended to contact a single URI). 2.4.6. it is not clear yet how the control could interact with further referral chasing operated at the client library's level by the LDAP backend (proxyAuthz and so). 2.4.7 there's yet no provisions to check for loops and so. 2.5. Specific numbers and #defines I'm currently using OIDs and return codes under OpenLDAP's/private space; the macros and the numbers are(from OpenLDAP's HEAD ldap.h): /* LDAP Chaining Behavior Control *//* work in progress */ /* ; * see also LDAP_REQUIRES_CHAINING, LDAP_CANNOT_CHAIN */ #ifdef LDAP_DEVEL #define LDAP_CONTROL_X_CHAINING_BEHAVIOR "1.3.6.1.4.1.4203.666.11.3" #define LDAP_CHAINING_PREFERRED 0 #define LDAP_CHAINING_REQUIRED 1 #define LDAP_REFERRALS_PREFERRED 2 #define LDAP_REFERRALS_REQUIRED 3 #endif /* for the Chaining Behavior control (consecutive result codes requested; * see ) */ #ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR #define LDAP_REQUIRES_CHAINING 0x4110 #define LDAP_CANNOT_CHAIN 0x4111 #endif I hope the discussion above, and the quick overview on the current implementation and its todo list, may be of help in stabilizing and completing the draft. Sincerely, p. SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497 --=__Part0023564A.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the feedback,
 
I've updated the I-D and will submit. I think I addressed everything = except the question about criticality. For criticality, the instructions = in 4.1.11 of http://www.ietf.org/internet-drafts/draft-ietf-ldapbis= -protocol-30.txt. Basically, if the server understands the control, = the criticality is ignored and the control is honored. If the control is = not understood, then criticality determines whether the control is ignored = or causes the operation to fail.
 
Jim

>>> Pierangelo Masarati <ando@sys-net.it> = 1/25/05 3:03:05 PM >>>
Jim,

I'm currently implementing = the (now expired) version 02 of
<draft-sermersheim-ldap-chaining>= in OpenLDAP based on the "chain"
overlay as first implemented by = Howard Chu and subsequently extended by
myself. What follows is a = collection of considerations that emerged
from the implementation and = that, perhaps owing to my lack of
understanding of some details, I = think require a clarification and might
be useful for the continuation = of the work on the draft. The comments
are quite unsorted.

1. = Comments

1.1. Return code renaming
I suggest to change the name = of "chainingRequired" into
"requiresChaining" to avoid confusion and = symbol clashes with the
"requiresChaining" value in the "Behavior" = enumeration.

1.2. Return code usage clarification
I think you = should clarify when the special return codes related to the
control = need be returned. For instance, if behavior is
"chainingRequired" and = the operation would return a referral that cannot
be chased, I'd = return "cannotChain", but for any other "Behavior" case
returning a = referral is acceptable, and returning a referral is not an
error: = <draft-ietf-ldapbis-protocol> lists "referral" as a non-error =
result code in Appendix A.1, so I don't see an application for the = other
error code you indicate ("chainingRequired"). I suggest you = clarify
your intentions.

1.3 OPTIONAL values and defaults
In = the draft, both "Behavior" fields are marked as OPTIONAL. My point
is: = what's the reason for not providing any? For instance, the "chain" =
overlay in OpenLDAP's slapd by default acts as if both "Behavior" were =
"chainingPreferred". If the control is present, but no values are =
given, I see no point in using the control. Unless you mean that the =
default behavior of the DSA may differ if the control is present or = not;
e.g. if no control is present, default to "referralsRequired", = while if
the control is present, default to "chainingPreferred" = (OpenLDAP's slapd
without and with the "chain" overlay), and in any = case both defaults are
left to the implementor. If this is the case, I = suggest it is clarified.
[technical note: it is not clear to me if, in = case none of the values is
provided, the crtls_value of the control = structure should be empty or null].

1.4 Operations.
It appears = from the draft that the control applies to all operations,
except = "abandon, unbind, and StartTLS"; the second value applies only to =
search continuations, and may apply to future operations. Should the =
presence of the second value in other operations among those already =
defined that do not require it be treated as an error? I think this =
should be clarified.

1.5 Behavior
1.5.1. "chainingPreferred" = and "referralsPreferred" don't present any
issue;
1.5.2. "chainingRe= quired" might be an issue if, in case it cannot be
honored, no = intermediate results should be returned at all (I'm talking
about = searches). In fact, unless caching all intermediate results
locally = upon completion, it is very likely that a referral is met after
some = entries/other intermediate results have already been returned. If
the = referral cannot be chased, the operation should be terminated and =
"cannotChain" be returned. I think it should be clarified if this =
behavior is acceptable or not.
1.5.3 "referralsRequired" should = never fail, because that's the
regular behavior in case no chaining = capabilities are available; I don't
see any issue that might prevent a = DSA from returning a referral. Can
you clarify why this option is ever = supposed to fail?

1.6. Criticality
I think the behavior should = be discussed in view of the criticality of
the control. Would it be = correct to simply ignore the "Behavior" in
case the control is not = critical? It is my understanding that only the
"chainingRequired" = behavior may suffer from the criticality field being
set when = referrals cannot be chased; the other options should pose no
issues. = How should the behavior differ in this case based on the value
of the = criticality flag?

2. Few notes on the implementation.

2.1. = Approach
The "chain" overlay in OpenLDAP's slapd uses the LDAP backend = to chase
referrals in case they're being returned by the underlying = backend (or
at the frontend level, if used as a global overlay). = Credits for both
the overlay and the underlying LDAP backend essentiall= y go to Howard Chu.

2.2. Authorization and Security
As such, it = can exploit the identity assertion capabilities of back-ldap
to = proxyAuthz the identity of the client while chasing the referral;
this = provides features like SASL bind, authorization policies based on =
pattern matching, grouping and so both at the local and at the remote =
site. The connection can be wrapped in a TLS layer (use ldaps:// =
referral URIs, or StartTLS over regular ldap:// URIs).

2.3. = Relationship with other extensions
Interaction with the "manageDSAit" = control as described in the draft,
although not intended, seems to = work as described in the draft. Of
course it may need further = testing.

2.4. Missing features and possible development
I plan = to introduce:
2.4.1. authorization based on referral suffix (e.g. only = chain
requests rooted at <DN>)
2.4.2. authorization based on = the referral URI (host/port portion)
2.4.3. authorization based on the = protocol scheme (e.g. only ldaps://)
2.4.4. authorization based on some = ssf
2.4.5. to allow chaining of multiple DSAs, back-ldap's identity =
assertion must be modified to allow authentication identity selection =
based on the DSA that is being chained (now a single identity can be =
specified, since back-ldap is intended to contact a single URI).
2.4= .6. it is not clear yet how the control could interact with further =
referral chasing operated at the client library's level by the LDAP =
backend (proxyAuthz and so).
2.4.7 there's yet no provisions to = check for loops and so.

2.5. Specific numbers and #defines
I'm = currently using OIDs and return codes under OpenLDAP's/private
space; = the macros and the numbers are(from OpenLDAP's HEAD ldap.h):

/* = LDAP Chaining Behavior Control *//* work in progress */
/* <draft-ser= mersheim-ldap-chaining>;
* see also LDAP_REQUIRES_CHAINING, = LDAP_CANNOT_CHAIN */
#ifdef LDAP_DEVEL
#define LDAP_CONTROL_X_CHAININ= G_BEHAVIOR "1.3.6.1.4.1.4203.666.11.3"

#define LDAP_CHAINING_PREFERR= ED 0
#define LDAP_CHAINING_REQUIRED 1
#define LDAP_REFERRALS_PREFERRE= D 2
#define LDAP_REFERRALS_REQUIRED 3
#endif

/* for the = Chaining Behavior control (consecutive result codes requested;
* see = <draft-sermersheim-ldap-chaining> ) */
#ifdef LDAP_CONTROL_X_CHAIN= ING_BEHAVIOR
#define LDAP_REQUIRES_CHAINING 0x4110
#define LDAP_CANNO= T_CHAIN 0x4111
#endif


I hope the discussion above, and the = quick overview on the current
implementation and its todo list, may be = of help in stabilizing and
completing the draft.

Sincerely, = p.




SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 = Fax: +390382476497

--=__Part0023564A.0__=-- --===============0817132932== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0817132932==-- From ldapext-bounces@ietf.org Mon Feb 21 02:23:30 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23423 for ; Mon, 21 Feb 2005 02:23:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D37MG-0000Hr-Ci; Mon, 21 Feb 2005 01:47:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D372u-0003Zb-En for ldapext@megatron.ietf.org; Mon, 21 Feb 2005 01:27:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28407 for ; Mon, 21 Feb 2005 01:27:46 -0500 (EST) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D37P0-00077l-2i for ldapext@ietf.org; Mon, 21 Feb 2005 01:50:45 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Sun, 20 Feb 2005 23:27:12 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta Date: Sun, 20 Feb 2005 23:26:02 -0700 From: "Jim Sermersheim" To: Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Cc: Kurt@OpenLDAP.org, ldapext@ietf.org Subject: [ldapext] Re: Comments to X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0539864358==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0539864358== Content-Type: multipart/alternative; boundary="=__PartA784F1EA.0__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartA784F1EA.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I was just reviewing this again and I disagree with the current draft's statement about interaction with ManageDsaIT. I believe ManageDsaIT has the effect of disallowing chaining and disallowing referrals. It simply causes the local distributed knowledge information to be updated and interrogated. I will change the draft to reflect this, but welcome further feedback. Jim >>> Pierangelo Masarati 1/25/05 3:03:05 PM >>> Jim, I'm currently implementing the (now expired) version 02 of in OpenLDAP based on the "chain" overlay as first implemented by Howard Chu and subsequently extended by myself. What follows is a collection of considerations that emerged from the implementation and that, perhaps owing to my lack of understanding of some details, I think require a clarification and might be useful for the continuation of the work on the draft. The comments are quite unsorted. 1. Comments 1.1. Return code renaming I suggest to change the name of "chainingRequired" into "requiresChaining" to avoid confusion and symbol clashes with the "requiresChaining" value in the "Behavior" enumeration. 1.2. Return code usage clarification I think you should clarify when the special return codes related to the control need be returned. For instance, if behavior is "chainingRequired" and the operation would return a referral that cannot be chased, I'd return "cannotChain", but for any other "Behavior" case returning a referral is acceptable, and returning a referral is not an error: lists "referral" as a non-error result code in Appendix A.1, so I don't see an application for the other error code you indicate ("chainingRequired"). I suggest you clarify your intentions. 1.3 OPTIONAL values and defaults In the draft, both "Behavior" fields are marked as OPTIONAL. My point is: what's the reason for not providing any? For instance, the "chain" overlay in OpenLDAP's slapd by default acts as if both "Behavior" were "chainingPreferred". If the control is present, but no values are given, I see no point in using the control. Unless you mean that the default behavior of the DSA may differ if the control is present or not; e.g. if no control is present, default to "referralsRequired", while if the control is present, default to "chainingPreferred" (OpenLDAP's slapd without and with the "chain" overlay), and in any case both defaults are left to the implementor. If this is the case, I suggest it is clarified. [technical note: it is not clear to me if, in case none of the values is provided, the crtls_value of the control structure should be empty or null]. 1.4 Operations. It appears from the draft that the control applies to all operations, except "abandon, unbind, and StartTLS"; the second value applies only to search continuations, and may apply to future operations. Should the presence of the second value in other operations among those already defined that do not require it be treated as an error? I think this should be clarified. 1.5 Behavior 1.5.1. "chainingPreferred" and "referralsPreferred" don't present any issue; 1.5.2. "chainingRequired" might be an issue if, in case it cannot be honored, no intermediate results should be returned at all (I'm talking about searches). In fact, unless caching all intermediate results locally upon completion, it is very likely that a referral is met after some entries/other intermediate results have already been returned. If the referral cannot be chased, the operation should be terminated and "cannotChain" be returned. I think it should be clarified if this behavior is acceptable or not. 1.5.3 "referralsRequired" should never fail, because that's the regular behavior in case no chaining capabilities are available; I don't see any issue that might prevent a DSA from returning a referral. Can you clarify why this option is ever supposed to fail? 1.6. Criticality I think the behavior should be discussed in view of the criticality of the control. Would it be correct to simply ignore the "Behavior" in case the control is not critical? It is my understanding that only the "chainingRequired" behavior may suffer from the criticality field being set when referrals cannot be chased; the other options should pose no issues. How should the behavior differ in this case based on the value of the criticality flag? 2. Few notes on the implementation. 2.1. Approach The "chain" overlay in OpenLDAP's slapd uses the LDAP backend to chase referrals in case they're being returned by the underlying backend (or at the frontend level, if used as a global overlay). Credits for both the overlay and the underlying LDAP backend essentially go to Howard Chu. 2.2. Authorization and Security As such, it can exploit the identity assertion capabilities of back-ldap to proxyAuthz the identity of the client while chasing the referral; this provides features like SASL bind, authorization policies based on pattern matching, grouping and so both at the local and at the remote site. The connection can be wrapped in a TLS layer (use ldaps:// referral URIs, or StartTLS over regular ldap:// URIs). 2.3. Relationship with other extensions Interaction with the "manageDSAit" control as described in the draft, although not intended, seems to work as described in the draft. Of course it may need further testing. 2.4. Missing features and possible development I plan to introduce: 2.4.1. authorization based on referral suffix (e.g. only chain requests rooted at ) 2.4.2. authorization based on the referral URI (host/port portion) 2.4.3. authorization based on the protocol scheme (e.g. only ldaps://) 2.4.4. authorization based on some ssf 2.4.5. to allow chaining of multiple DSAs, back-ldap's identity assertion must be modified to allow authentication identity selection based on the DSA that is being chained (now a single identity can be specified, since back-ldap is intended to contact a single URI). 2.4.6. it is not clear yet how the control could interact with further referral chasing operated at the client library's level by the LDAP backend (proxyAuthz and so). 2.4.7 there's yet no provisions to check for loops and so. 2.5. Specific numbers and #defines I'm currently using OIDs and return codes under OpenLDAP's/private space; the macros and the numbers are(from OpenLDAP's HEAD ldap.h): /* LDAP Chaining Behavior Control *//* work in progress */ /* ; * see also LDAP_REQUIRES_CHAINING, LDAP_CANNOT_CHAIN */ #ifdef LDAP_DEVEL #define LDAP_CONTROL_X_CHAINING_BEHAVIOR "1.3.6.1.4.1.4203.666.11.3" #define LDAP_CHAINING_PREFERRED 0 #define LDAP_CHAINING_REQUIRED 1 #define LDAP_REFERRALS_PREFERRED 2 #define LDAP_REFERRALS_REQUIRED 3 #endif /* for the Chaining Behavior control (consecutive result codes requested; * see ) */ #ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR #define LDAP_REQUIRES_CHAINING 0x4110 #define LDAP_CANNOT_CHAIN 0x4111 #endif I hope the discussion above, and the quick overview on the current implementation and its todo list, may be of help in stabilizing and completing the draft. Sincerely, p. SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497 --=__PartA784F1EA.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I was just reviewing this again and I disagree with the current = draft's statement about interaction with ManageDsaIT. I believe ManageDsaIT= has the effect of disallowing chaining and disallowing referrals. It = simply causes the local distributed knowledge information to be updated = and interrogated.
 
I will change the draft to reflect this, but welcome further = feedback.
 
Jim

>>> Pierangelo Masarati <ando@sys-net.it> = 1/25/05 3:03:05 PM >>>
Jim,

I'm currently implementing = the (now expired) version 02 of
<draft-sermersheim-ldap-chaining>= in OpenLDAP based on the "chain"
overlay as first implemented by = Howard Chu and subsequently extended by
myself. What follows is a = collection of considerations that emerged
from the implementation and = that, perhaps owing to my lack of
understanding of some details, I = think require a clarification and might
be useful for the continuation = of the work on the draft. The comments
are quite unsorted.

1. = Comments

1.1. Return code renaming
I suggest to change the name = of "chainingRequired" into
"requiresChaining" to avoid confusion and = symbol clashes with the
"requiresChaining" value in the "Behavior" = enumeration.

1.2. Return code usage clarification
I think you = should clarify when the special return codes related to the
control = need be returned. For instance, if behavior is
"chainingRequired" and = the operation would return a referral that cannot
be chased, I'd = return "cannotChain", but for any other "Behavior" case
returning a = referral is acceptable, and returning a referral is not an
error: = <draft-ietf-ldapbis-protocol> lists "referral" as a non-error =
result code in Appendix A.1, so I don't see an application for the = other
error code you indicate ("chainingRequired"). I suggest you = clarify
your intentions.

1.3 OPTIONAL values and defaults
In = the draft, both "Behavior" fields are marked as OPTIONAL. My point
is: = what's the reason for not providing any? For instance, the "chain" =
overlay in OpenLDAP's slapd by default acts as if both "Behavior" were =
"chainingPreferred". If the control is present, but no values are =
given, I see no point in using the control. Unless you mean that the =
default behavior of the DSA may differ if the control is present or = not;
e.g. if no control is present, default to "referralsRequired", = while if
the control is present, default to "chainingPreferred" = (OpenLDAP's slapd
without and with the "chain" overlay), and in any = case both defaults are
left to the implementor. If this is the case, I = suggest it is clarified.
[technical note: it is not clear to me if, in = case none of the values is
provided, the crtls_value of the control = structure should be empty or null].

1.4 Operations.
It appears = from the draft that the control applies to all operations,
except = "abandon, unbind, and StartTLS"; the second value applies only to =
search continuations, and may apply to future operations. Should the =
presence of the second value in other operations among those already =
defined that do not require it be treated as an error? I think this =
should be clarified.

1.5 Behavior
1.5.1. "chainingPreferred" = and "referralsPreferred" don't present any
issue;
1.5.2. "chainingRe= quired" might be an issue if, in case it cannot be
honored, no = intermediate results should be returned at all (I'm talking
about = searches). In fact, unless caching all intermediate results
locally = upon completion, it is very likely that a referral is met after
some = entries/other intermediate results have already been returned. If
the = referral cannot be chased, the operation should be terminated and =
"cannotChain" be returned. I think it should be clarified if this =
behavior is acceptable or not.
1.5.3 "referralsRequired" should = never fail, because that's the
regular behavior in case no chaining = capabilities are available; I don't
see any issue that might prevent a = DSA from returning a referral. Can
you clarify why this option is ever = supposed to fail?

1.6. Criticality
I think the behavior should = be discussed in view of the criticality of
the control. Would it be = correct to simply ignore the "Behavior" in
case the control is not = critical? It is my understanding that only the
"chainingRequired" = behavior may suffer from the criticality field being
set when = referrals cannot be chased; the other options should pose no
issues. = How should the behavior differ in this case based on the value
of the = criticality flag?

2. Few notes on the implementation.

2.1. = Approach
The "chain" overlay in OpenLDAP's slapd uses the LDAP backend = to chase
referrals in case they're being returned by the underlying = backend (or
at the frontend level, if used as a global overlay). = Credits for both
the overlay and the underlying LDAP backend essentiall= y go to Howard Chu.

2.2. Authorization and Security
As such, it = can exploit the identity assertion capabilities of back-ldap
to = proxyAuthz the identity of the client while chasing the referral;
this = provides features like SASL bind, authorization policies based on =
pattern matching, grouping and so both at the local and at the remote =
site. The connection can be wrapped in a TLS layer (use ldaps:// =
referral URIs, or StartTLS over regular ldap:// URIs).

2.3. = Relationship with other extensions
Interaction with the "manageDSAit" = control as described in the draft,
although not intended, seems to = work as described in the draft. Of
course it may need further = testing.

2.4. Missing features and possible development
I plan = to introduce:
2.4.1. authorization based on referral suffix (e.g. only = chain
requests rooted at <DN>)
2.4.2. authorization based on = the referral URI (host/port portion)
2.4.3. authorization based on the = protocol scheme (e.g. only ldaps://)
2.4.4. authorization based on some = ssf
2.4.5. to allow chaining of multiple DSAs, back-ldap's identity =
assertion must be modified to allow authentication identity selection =
based on the DSA that is being chained (now a single identity can be =
specified, since back-ldap is intended to contact a single URI).
2.4= .6. it is not clear yet how the control could interact with further =
referral chasing operated at the client library's level by the LDAP =
backend (proxyAuthz and so).
2.4.7 there's yet no provisions to = check for loops and so.

2.5. Specific numbers and #defines
I'm = currently using OIDs and return codes under OpenLDAP's/private
space; = the macros and the numbers are(from OpenLDAP's HEAD ldap.h):

/* = LDAP Chaining Behavior Control *//* work in progress */
/* <draft-ser= mersheim-ldap-chaining>;
* see also LDAP_REQUIRES_CHAINING, = LDAP_CANNOT_CHAIN */
#ifdef LDAP_DEVEL
#define LDAP_CONTROL_X_CHAININ= G_BEHAVIOR "1.3.6.1.4.1.4203.666.11.3"

#define LDAP_CHAINING_PREFERR= ED 0
#define LDAP_CHAINING_REQUIRED 1
#define LDAP_REFERRALS_PREFERRE= D 2
#define LDAP_REFERRALS_REQUIRED 3
#endif

/* for the = Chaining Behavior control (consecutive result codes requested;
* see = <draft-sermersheim-ldap-chaining> ) */
#ifdef LDAP_CONTROL_X_CHAIN= ING_BEHAVIOR
#define LDAP_REQUIRES_CHAINING 0x4110
#define LDAP_CANNO= T_CHAIN 0x4111
#endif


I hope the discussion above, and the = quick overview on the current
implementation and its todo list, may be = of help in stabilizing and
completing the draft.

Sincerely, = p.




SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 = Fax: +390382476497

--=__PartA784F1EA.0__=-- --===============0539864358== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0539864358==-- From ldapext-bounces@ietf.org Wed Feb 23 21:21:37 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02294 for ; Wed, 23 Feb 2005 21:21:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3oDQ-0008LX-P1; Tue, 22 Feb 2005 23:33:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3oDO-0008LJ-Pm; Tue, 22 Feb 2005 23:33:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02703; Tue, 22 Feb 2005 23:33:22 -0500 (EST) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3oZq-0008Sd-VF; Tue, 22 Feb 2005 23:56:48 -0500 Received: from gypsy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j1N4XJdR098042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Feb 2005 04:33:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.0.14.0.20050222202934.02e6b608@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 22 Feb 2005 20:32:36 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ldapext@ietf.org, ldap-dir@ietf.org Subject: [ldapext] draft-zeilenga-ldap-x509 -> PS X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Please review and comment on the following individual submission: Lightweight Directory Access Protocol (LDAP) schema definitions for X.509 Certificates I intend to make a decision by the end of IETF#62 whether to recommend this revision for IESG consideration as a Proposed Standard. It is my hope that this document will be published at the same time as the revised LDAP TS being developed by the LDAPBIS WG. Please direct comments to the mailing list (or, if solely of an editorial nature, to me). Regards, Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 23 22:12:16 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21604 for ; Wed, 23 Feb 2005 22:12:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kl8-0005s0-VX; Tue, 22 Feb 2005 19:52:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3iYh-0007tj-9N for ldapext@megatron.ietf.org; Tue, 22 Feb 2005 17:31:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01692 for ; Tue, 22 Feb 2005 17:31:02 -0500 (EST) Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3ivA-00054l-Lf for ldapext@ietf.org; Tue, 22 Feb 2005 17:54:25 -0500 Received: from mail-mx2.uio.no ([129.240.10.30] ident=[U2FsdGVkX1/0QE1bmDqZGaA76Be++Cq9xSIOiKrm+co=]) by pat.uio.no with esmtp (Exim 4.43) id 1D3iYW-0005u6-Gy for ldapext@ietf.org; Tue, 22 Feb 2005 23:31:00 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.43) id 1D3iYR-0008Bo-8K for ldapext@ietf.org; Tue, 22 Feb 2005 23:30:55 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1D3iYR-0004Be-3A for ldapext@ietf.org; Tue, 22 Feb 2005 23:30:55 +0100 From: Hallvard B Furuseth Message-Id: To: ldapext@ietf.org Date: Tue, 22 Feb 2005 23:30:55 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-4.814, required 12, autolearn=disabled, AWL 0.19, UIO_MAIL_IS_INTERNAL -5.00) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [ldapext] comment control, dummy request, no-response request X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org "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 Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 23 22:40:35 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02267 for ; Wed, 23 Feb 2005 22:40:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D42wn-0002aK-6S; Wed, 23 Feb 2005 15:17:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D42wm-0002aF-AU for ldapext@megatron.ietf.org; Wed, 23 Feb 2005 15:17:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09090 for ; Wed, 23 Feb 2005 15:17:22 -0500 (EST) Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D43JW-00085u-DU for ldapext@ietf.org; Wed, 23 Feb 2005 15:40:55 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j1NKHDLU007341 for ; Wed, 23 Feb 2005 15:17:13 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1NKHDeR057636 for ; Wed, 23 Feb 2005 15:17:13 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1NKHDlR003918 for ; Wed, 23 Feb 2005 15:17:13 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.229.77]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1NKHD4s003903 for ; Wed, 23 Feb 2005 15:17:13 -0500 To: ldapext@ietf.org X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: John McMeeking Date: Wed, 23 Feb 2005 14:17:11 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 02/23/2005 02:17:12 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [ldapext] draft-behera-ldap-password-policy - last login time X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org I've had some recent requests for some sort of "last login time" attribute or a "unused account" policy so that accounts can be disabled if they have not been used for 6 months. Would either of these be appropriate for the password policy draft? John McMeeking _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 24 00:04:27 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01895 for ; Thu, 24 Feb 2005 00:04:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D49Sk-0003R2-8r; Wed, 23 Feb 2005 22:14:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D49Si-0003Pv-7d for ldapext@megatron.ietf.org; Wed, 23 Feb 2005 22:14:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22734 for ; Wed, 23 Feb 2005 22:14:45 -0500 (EST) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D49pW-0004Qh-Rq for ldapext@ietf.org; Wed, 23 Feb 2005 22:38:23 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 23 Feb 2005 20:14:38 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta Date: Wed, 23 Feb 2005 20:14:19 -0700 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Common typo: Lightweight Directory *Application* Protocol Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0273664863==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0273664863== Content-Type: multipart/alternative; boundary="=__PartEAC9B89B.0__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartEAC9B89B.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Strange, I fixed this and indeed it's fixed in the newly published I-D's, but the I-D ACTION messages have the old text. So if you see it in the I-D ACTION announcement, don't be alarmed. Jim >>> "Jim Sermersheim" 1/6/05 8:35:27 AM >>> Must have been daydreaming. Thanks for the catch. Jim >>> Hallvard B Furuseth 1/5/05 2:18:02 PM >>> I've just noticed that lots of places call LDAP the Lightweight Directory *Application* Protocol instead of *Access* protocol, including: - RFC 2820 (Access Control Requirements for LDAP), - draft-ietf-ldapext-acl-model-08.txt (Access Control Model for LDAPv3), - draft-sermersheim-ldap-subordinate-scope-01.txt (Subordinate Subtree Search Scope for LDAP), - draft-sermersheim-ldap-distproc-01.txt (Distributed Procedures for LDAP Operations). -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__PartEAC9B89B.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Strange, I fixed this and indeed it's fixed in the newly published = I-D's, but the I-D ACTION messages have the old text. So if you see it in = the I-D ACTION announcement, don't be alarmed.
 
Jim

>>> "Jim Sermersheim" <jimse@novell.com> = 1/6/05 8:35:27 AM >>>
Must have been daydreaming.  Thanks for the catch.
 
Jim

>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.= no> 1/5/05 2:18:02 PM >>>
I've just noticed that lots of = places call LDAP the Lightweight
Directory *Application* Protocol = instead of *Access* protocol,
including:

- RFC 2820 (Access = Control Requirements for LDAP),

- draft-ietf-ldapext-acl-model-08.tx= t (Access Control Model for LDAPv3),

- draft-sermersheim-ldap-subord= inate-scope-01.txt
(Subordinate Subtree Search Scope for LDAP),

-= draft-sermersheim-ldap-distproc-01.txt
(Distributed Procedures for = LDAP Operations).

--
Hallvard

___________________________= ____________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext<= /A>
--=__PartEAC9B89B.0__=-- --===============0273664863== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0273664863==-- From ldapext-bounces@ietf.org Thu Feb 24 00:30:41 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12237 for ; Thu, 24 Feb 2005 00:30:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4ANA-0003Q6-IW; Wed, 23 Feb 2005 23:13:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4AMX-0003AR-KC for ldapext@megatron.ietf.org; Wed, 23 Feb 2005 23:12:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13599 for ; Wed, 23 Feb 2005 23:12:26 -0500 (EST) Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4AjL-00025H-CM for ldapext@ietf.org; Wed, 23 Feb 2005 23:36:04 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.12.9/8.12.9) with ESMTP id j1O4CB4C006646; Wed, 23 Feb 2005 22:12:11 -0600 Message-ID: <421D5409.5080006@highlandsun.com> Date: Wed, 23 Feb 2005 20:11:53 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050111 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John McMeeking Subject: Re: [ldapext] draft-behera-ldap-password-policy - last login time References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit John McMeeking wrote: > I've had some recent requests for some sort of "last login time" attribute > or a "unused account" policy so that accounts can be disabled if they have > not been used for 6 months. Would either of these be appropriate for the > password policy draft? Both of those sound like good things to have, and it does seem to tie in to the rest of the password policy features. There would still be replication issues here. It seems to me that one solution to these replicated state attributes may be to define a second set of attributes - one that is DSA-specific, never implicitly replicated, and another one that serves as an aggregate for a collection of servers. Then one can specify policies for each set independently, e.g., "number of failed attempts" on a single DSA vs across the network. Sites that require total accountability could set a policy implementing counts across all replicas, other sites that want to avoid the overhead of maintaining centralized counts could set a policy using only dsa-specific attributes. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 24 00:32:28 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13279 for ; Thu, 24 Feb 2005 00:32:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D40QO-0005gZ-Ai; Wed, 23 Feb 2005 12:35:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D40QM-0005gK-4E for ldapext@megatron.ietf.org; Wed, 23 Feb 2005 12:35:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16685 for ; Wed, 23 Feb 2005 12:35:36 -0500 (EST) Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D40my-0001ut-FS for ldapext@ietf.org; Wed, 23 Feb 2005 12:59:09 -0500 Received: from mail-mx6.uio.no ([129.240.10.47] ident=[U2FsdGVkX1+mN6mRqMqGhACLUPvO5D6rbB2YDFQtQ0k=]) by pat.uio.no with esmtp (Exim 4.43) id 1D40QA-0001qT-6n for ldapext@ietf.org; Wed, 23 Feb 2005 18:35:34 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.43) id 1D40Q4-0002zr-LD for ldapext@ietf.org; Wed, 23 Feb 2005 18:35:28 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1D40Q4-0001Ai-DD for ldapext@ietf.org; Wed, 23 Feb 2005 18:35:28 +0100 From: Hallvard B Furuseth Message-Id: To: ldapext@ietf.org Date: Wed, 23 Feb 2005 18:35:28 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-4.618, required 12, autolearn=disabled, AWL 0.38, UIO_MAIL_IS_INTERNAL -5.00) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [ldapext] draft-zeilenga-ldap-assert-05 notes X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org draft-zeilenga-ldap-assert-05.txt says: > 3. The Assertion Control > > The control is appropriate for both LDAP interrogation and update > operations [Protocol] including Add, Compare, Delete, Modify, ModifyDN > (rename), and Search. It is inappropriate for Abandon, Bind nor > Unbind, and Start TLS operations. I expect "including..." means it's also appropriate for the Password Modify Extended Operation (RFC 3062)? Is Add intended to be part of the above list? Kurt stated in thread 'Assert I-D.', 22-23. jul 2003, that he would change the control to not be applicable to Add - since the entry is not yet present to be compared with. Though the thread can be read as keeping Add anyway and compare with the entry to be added. > 4. Security Considerations > > As with any general assertion mechanism, the mechanism can be used to > determine directory content. Hence, this mechanism SHOULD be subject > to appropriate access controls. I suggest to add something like: ... preferably the same access controls as search filters. The implementor might find the same access controls as for Compare natural, but the server admin might e.g. not want substring matching to be possible - and he could have written the Compare ACLs knowing that Compare can't do substring matching. Or one might mistakenly use the same ACLs as for the "basic" operation being performed, e.g. Modify. -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 24 00:42:54 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16819 for ; Thu, 24 Feb 2005 00:42:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3yJJ-0006gH-VQ; Wed, 23 Feb 2005 10:20:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3yJI-0006fy-BZ; Wed, 23 Feb 2005 10:20:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25455; Wed, 23 Feb 2005 10:20:11 -0500 (EST) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3yft-0004sX-Ox; Wed, 23 Feb 2005 10:43:43 -0500 Received: from gypsy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j1NFKBUX023049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Feb 2005 15:20:11 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.0.14.0.20050223071833.05ca2070@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 23 Feb 2005 07:19:26 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" In-Reply-To: <6.2.0.14.0.20050222202934.02e6b608@mail.openldap.org> References: <6.2.0.14.0.20050222202934.02e6b608@mail.openldap.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ldapext@ietf.org, ldap-dir@ietf.org Subject: [ldapext] Re: draft-zeilenga-ldap-x509 -> PS X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 08:32 PM 2/22/2005, Kurt D. Zeilenga wrote: >Please direct comments to the The correct address for the PKIX WG list is >mailing list (or, if solely of an editorial nature, >to me). _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 24 01:40:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07144 for ; Thu, 24 Feb 2005 01:40:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4CDq-00040Z-2c; Thu, 24 Feb 2005 01:11:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4CDo-000408-6e for ldapext@megatron.ietf.org; Thu, 24 Feb 2005 01:11:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26572 for ; Thu, 24 Feb 2005 01:11:35 -0500 (EST) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Cae-0006X7-B7 for ldapext@ietf.org; Thu, 24 Feb 2005 01:35:12 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 23 Feb 2005 23:11:26 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta Date: Wed, 23 Feb 2005 23:11:05 -0700 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] draft-behera-ldap-password-policy - last login time Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1347703041==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============1347703041== Content-Type: multipart/alternative; boundary="=__PartB192E3E9.1__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartB192E3E9.1__= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Regarding replication, I favor allowing implementations to solve their own = consistency problems. A highly usable implementation would allow for any = state attribute to be configured for different levels of replication = consistency (from "never replicated", to whatever the highest level of = consistency available is). This way the admin can decide how consistently = the state data is replicated. =20 I guess what I'm saying is that I see this as a replication problem in = general, and would rather not solve this level of replication problems in = the password policy I-D by defining multiple sets of attributes and = specifying different grades of replication requirements for each. I do = think it's reasonable to address problems of loose consistency * which is = what caused the use of time to be used for things like failure count. =20 Jim >>> Howard Chu 2/23/05 9:11:53 PM >>> John McMeeking wrote: > I've had some recent requests for some sort of "last login time" = attribute > or a "unused account" policy so that accounts can be disabled if they = have > not been used for 6 months. Would either of these be appropriate for the > password policy draft? Both of those sound like good things to have, and it does seem to tie = in=20 to the rest of the password policy features. There would still be=20 replication issues here. It seems to me that one solution to these replicated state attributes=20 may be to define a second set of attributes - one that is DSA-specific,=20 never implicitly replicated, and another one that serves as an aggregate=20= for a collection of servers. Then one can specify policies for each set=20 independently, e.g., "number of failed attempts" on a single DSA vs=20 across the network. Sites that require total accountability could set a=20 policy implementing counts across all replicas, other sites that want = to=20 avoid the overhead of maintaining centralized counts could set a policy=20 using only dsa-specific attributes. --=20 -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc=20 Symas: Premier OpenSource Development and Support _______________________________________________ Ldapext mailing list Ldapext@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ldapext=20 --=__PartB192E3E9.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Regarding replication, I favor allowing implementations to solve = their own consistency problems. A highly usable implementation would allow = for any state attribute to be configured for different levels of replicatio= n consistency (from "never replicated", to whatever the highest level of = consistency available is). This way the admin can decide how consistently = the state data is replicated.
 
I guess what I'm saying is that I see this as a replication problem = in general, and would rather not solve this level of replication problems = in the password policy I-D by defining multiple sets of attributes and = specifying different grades of replication requirements for each. I do = think it's reasonable to address problems of loose consistency =97 = which is what caused the use of time to be used for things like failure = count.
 
Jim

>>> Howard Chu <hyc@highlandsun.com> = 2/23/05 9:11:53 PM >>>
John McMeeking wrote:

> I've = had some recent requests for some sort of "last login time" attribute
&g= t; or a "unused account" policy so that accounts can be disabled if they = have
> not been used for 6 months. Would either of these be = appropriate for the
> password policy draft?

Both of those = sound like good things to have, and it does seem to tie in
to the rest = of the password policy features. There would still be
replication = issues here.

It seems to me that one solution to these replicated = state attributes
may be to define a second set of attributes - one = that is DSA-specific,
never implicitly replicated, and another one = that serves as an aggregate
for a collection of servers. Then one can = specify policies for each set
independently, e.g., "number of failed = attempts" on a single DSA vs
across the network. Sites that require = total accountability could set a
policy implementing counts across all = replicas, other sites that want to
avoid the overhead of maintaining = centralized counts could set a policy
using only dsa-specific = attributes.

--
-- Howard Chu
Chief Architect, Symas Corp. = Director, Highland Sun
http://www.s= ymas.com http://highlands= un.com/hyc
Symas: Premier OpenSource Development and Support
_______________________________________________
Ldapext mailing = list
Ldapext@ietf.org =
https://w= ww1.ietf.org/mailman/listinfo/ldapext
--=__PartB192E3E9.1__=-- --===============1347703041== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============1347703041==-- From ldapext-bounces@ietf.org Thu Feb 24 01:50:34 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10897 for ; Thu, 24 Feb 2005 01:50:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4CY9-0008Dx-CH; Thu, 24 Feb 2005 01:32:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4CY6-00088C-0Z for ldapext@megatron.ietf.org; Thu, 24 Feb 2005 01:32:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04470 for ; Thu, 24 Feb 2005 01:32:28 -0500 (EST) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Cuo-0000ZJ-HA for ldapext@ietf.org; Thu, 24 Feb 2005 01:56:05 -0500 Received: from gypsy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j1O6WNnV086885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Feb 2005 06:32:23 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.0.14.0.20050223215702.06a15670@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 23 Feb 2005 22:31:36 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: [ldapext] draft-zeilenga-ldap-assert-05 notes In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 09:35 AM 2/23/2005, Hallvard B Furuseth wrote: >draft-zeilenga-ldap-assert-05.txt says: > >> 3. The Assertion Control >> >> The control is appropriate for both LDAP interrogation and update >> operations [Protocol] including Add, Compare, Delete, Modify, ModifyDN >> (rename), and Search. It is inappropriate for Abandon, Bind nor >> Unbind, and Start TLS operations. > >I expect "including..." means it's also appropriate for the Password >Modify Extended Operation (RFC 3062)? I consider Password Modify Extended Operation to be an "other" operation, as in: Other documents may specify how this control applies to other LDAP operations. In doing so, they must state how the target entry is determined. I'll change the text to precisely state which requests the control is appropriate for. >Is Add intended to be part of the above list? I intend to remove Add from the list. >Kurt stated in thread >'Assert I-D.', 22-23. jul 2003, that he would change the control to not >be applicable to Add - since the entry is not yet present to be compared >with. Though the thread can be read as keeping Add anyway and compare >with the entry to be added. > >> 4. Security Considerations >> >> As with any general assertion mechanism, the mechanism can be used to >> determine directory content. Hence, this mechanism SHOULD be subject >> to appropriate access controls. > >I suggest to add something like: > > ... preferably the same access controls as search filters. Is there a search reason behind this preference? I rather not state a preference as part of a security considerations unless there is a good security related reason for that preference. >The implementor might find the same access controls as for Compare >natural, but the server admin might e.g. not want substring matching to >be possible - and he could have written the Compare ACLs knowing that >Compare can't do substring matching. Or one might mistakenly use the >same ACLs as for the "basic" operation being performed, e.g. Modify. It seems to be your statements depend greatly on what the access control model is... I can certainly envision models where that would not be a mistake. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 24 02:07:01 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21091 for ; Thu, 24 Feb 2005 02:07:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4C2I-0005Ww-91; Thu, 24 Feb 2005 00:59:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4C2G-0005Th-5e for ldapext@megatron.ietf.org; Thu, 24 Feb 2005 00:59:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22199 for ; Thu, 24 Feb 2005 00:59:36 -0500 (EST) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4CP5-0005Gg-Vt for ldapext@ietf.org; Thu, 24 Feb 2005 01:23:16 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 23 Feb 2005 22:59:30 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta Date: Wed, 23 Feb 2005 22:59:12 -0700 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] draft-behera-ldap-password-policy - last login time Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0054461859==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0054461859== Content-Type: multipart/alternative; boundary="=__Part7A592820.0__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part7A592820.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Occasionally we hear requests to add new policy to that draft which squarely lands in the realm of "login" policy, and other times we get requests to remove policy like intruder detection as it has more to do with logging in than management of passwords (though it kind of leaks into both areas). Usually though, consensus seems to point to putting login policy into a draft of its own. This could also contain things like maximum concurrent logins and allowed login times. If someone could author that I-D, we could possibly define intruder detection in a way that it could be consumed from a password modify perspective in the password policy I-D, and consumed from a password usage perspective in the login policy I-D. Or, maybe it would be best to glob everything into a single I-D (my feeling is this is worse). The problem I see currently is a lack of resources to push both of these areas of policy forward together in a coordinated way. Jim >>> John McMeeking 2/23/05 1:17:11 PM >>> I've had some recent requests for some sort of "last login time" attribute or a "unused account" policy so that accounts can be disabled if they have not been used for 6 months. Would either of these be appropriate for the password policy draft? John McMeeking _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__Part7A592820.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Occasionally we hear requests to add new policy to that draft which = squarely lands in the realm of "login" policy, and other times we get = requests to remove policy like intruder detection as it has more to do = with logging in than management of passwords (though it kind of leaks into = both areas).
 
Usually though, consensus seems to point to putting login policy into = a draft of its own. This could also contain things like maximum = concurrent logins and allowed login times.
 
If someone could author that I-D, we could possibly define intruder = detection in a way that it could be consumed from a password modify = perspective in the password policy I-D, and consumed from a password usage = perspective in the login policy I-D.
 
Or, maybe it would be best to glob everything into a single I-D (my = feeling is this is worse). The problem I see currently is a lack of = resources to push both of these areas of policy forward together in a = coordinated way.
 
Jim


>>> John McMeeking <jmcmeek@us.ibm.com> = 2/23/05 1:17:11 PM >>>




I've had some recent = requests for some sort of "last login time" attribute
or a "unused = account" policy so that accounts can be disabled if they have
not been = used for 6 months. Would either of these be appropriate for the
password= policy draft?


John McMeeking


_______________________= ________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldap= ext
--=__Part7A592820.0__=-- --===============0054461859== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0054461859==-- From ldapext-bounces@ietf.org Thu Feb 24 09:27:19 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24422 for ; Thu, 24 Feb 2005 09:27:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Jvr-0002Yq-Tr; Thu, 24 Feb 2005 09:25:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Jvq-0002T4-B5 for ldapext@megatron.ietf.org; Thu, 24 Feb 2005 09:25:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24188 for ; Thu, 24 Feb 2005 09:25:32 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4KIk-00074e-Va for ldapext@ietf.org; Thu, 24 Feb 2005 09:49:15 -0500 Received: from phys-gadget-2 ([129.156.85.172]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j1OEPWhn014380 for ; Thu, 24 Feb 2005 07:25:32 -0700 (MST) Received: from conversion-daemon.gadget-mail1.uk.sun.com by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ICF009016OPOL@gadget-mail1.uk.sun.com> (original mail from Ludovic.Poitou@Sun.COM) for ldapext@ietf.org; Thu, 24 Feb 2005 14:25:31 +0000 (GMT) Received: from [129.150.25.58] (vpn-129-150-25-58.SFBay.Sun.COM [129.150.25.58]) by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0ICF00ANZ6QH31@gadget-mail1.uk.sun.com>; Thu, 24 Feb 2005 14:25:31 +0000 (GMT) Date: Thu, 24 Feb 2005 15:25:29 +0100 From: Ludovic Poitou Subject: Re: [ldapext] draft-behera-ldap-password-policy - last login time In-reply-to: To: Jim Sermersheim Message-id: <421DE3D9.7090705@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: jmcmeek@us.ibm.com, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: QUOTED-PRINTABLE Jim, I tend to agree with you. But I also see the point of Howard. X.500 a= nd=20 LDAP both define different types of Operational Attributes: DSA Speci= fic=20 and Directory Operation with specific semantic with regards to the= =20 consistence of the attribute value in replicated systems. Defining an operational attribute and letting implementation (or=20 administrator) decide if it'll be replicated or not is actually messi= ng=20 with the distinctions between the various operational types. Ludovic. Jim Sermersheim wrote: > Regarding replication, I favor allowing implementations to solve th= eir=20 > own consistency problems. A highly usable implementation would allo= w=20 > for any state attribute to be configured for different levels of= =20 > replication consistency (from "never replicated", to whatever the= =20 > highest level of consistency available is). This way the admin can= =20 > decide how consistently the state data is replicated. > I guess what I'm saying is that I see this as a replication problem= in=20 > general, and would rather not solve this level of replication probl= ems=20 > in the password policy I-D by defining multiple sets of attributes = and=20 > specifying different grades of replication requirements for each. I= do=20 > think it's reasonable to address problems of loose consistency = =97 which=20 > is what caused the use of time to be used for things like failure c= ount. > Jim > > >>> Howard Chu 2/23/05 9:11:53 PM >>> > John McMeeking wrote: > > > I've had some recent requests for some sort of "last login time"= =20 > attribute > > or a "unused account" policy so that accounts can be disabled if= =20 > they have > > not been used for 6 months. Would either of these be appropriate = for the > > password policy draft? > > Both of those sound like good things to have, and it does seem to t= ie in > to the rest of the password policy features. There would still be > replication issues here. > > It seems to me that one solution to these replicated state attribut= es > may be to define a second set of attributes - one that is DSA-speci= fic, > never implicitly replicated, and another one that serves as an aggr= egate > for a collection of servers. Then one can specify policies for each= set > independently, e.g., "number of failed attempts" on a single DSA vs > across the network. Sites that require total accountability could s= et a > policy implementing counts across all replicas, other sites that wa= nt to > avoid the overhead of maintaining centralized counts could set a po= licy > using only dsa-specific attributes. > > --=20 > -- Howard Chu > Chief Architect, Symas Corp. Director, Highland Sun > _http://www.symas.com _=20 > _http://highlandsun.com/hyc_ > Symas: Premier OpenSource Development and Support > > _______________________________________________ > Ldapext mailing list > _Ldapext@ietf.org _ > _https://www1.ietf.org/mailman/listinfo/ldapext_ > >--------------------------------------------------------------------= ---- > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext > =20 > --=20 Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 24 11:54:38 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14890 for ; Thu, 24 Feb 2005 11:54:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4MDl-0006CD-QR; Thu, 24 Feb 2005 11:52:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4MDk-00068V-1s for ldapext@megatron.ietf.org; Thu, 24 Feb 2005 11:52:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14578 for ; Thu, 24 Feb 2005 11:52:04 -0500 (EST) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Maa-0003Rt-Bx for ldapext@ietf.org; Thu, 24 Feb 2005 12:15:49 -0500 Received: from gypsy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j1OGq3PM013061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Feb 2005 16:52:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.0.14.0.20050224080350.06bc6958@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 24 Feb 2005 08:51:16 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: [ldapext] comment control, dummy request, no-response request In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 02:30 PM 2/22/2005, Hallvard B Furuseth wrote: >"Comment" control: > >It can be useful to attach a comment to an LDAP request. For what purpose? Tracing or other? >The intent would be to log the comment with the request in >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 >define and implement it. 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 >LDAPString would be natural, but sometimes one may want to attach data >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 >be better, to be interpreted at the server admin's discretion. I rather say that the information provided is to only be used for trace purposes and is not to be otherwise interpreted or used. >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? I am not sure this makes sense, which I will illustrate below. >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). 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. >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. 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. >"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. 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 >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. 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. >Comments? > >-- >Hallvard > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 24 12:08:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16980 for ; Thu, 24 Feb 2005 12:08:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4MR8-0007Vk-EE; Thu, 24 Feb 2005 12:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4MR6-0007VC-MN for ldapext@megatron.ietf.org; Thu, 24 Feb 2005 12:06:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16450 for ; Thu, 24 Feb 2005 12:05:57 -0500 (EST) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Mo2-0003p7-5e for ldapext@ietf.org; Thu, 24 Feb 2005 12:29:42 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 24 Feb 2005 10:05:50 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta Date: Thu, 24 Feb 2005 10:05:25 -0700 From: "Jim Sermersheim" To: Subject: Re: [ldapext] draft-behera-ldap-password-policy - last login time Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: jmcmeek@us.ibm.com, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0828225686==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0828225686== Content-Type: multipart/alternative; boundary="=__Part785B2945.1__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part785B2945.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sure, but I still don't want to define two attributes for the same state information. If replicating it seems appropriate, then defining it as not-DSA Specific is the right thing to do, but beyond that, it feels like an implementation issue as to whether and how quickly it's replicated. >>> Ludovic Poitou 2/24/05 7:25:29 AM >>> Jim, I tend to agree with you. But I also see the point of Howard. X.500 and LDAP both define different types of Operational Attributes: DSA Specific and Directory Operation with specific semantic with regards to the consistence of the attribute value in replicated systems. Defining an operational attribute and letting implementation (or administrator) decide if it'll be replicated or not is actually messing with the distinctions between the various operational types. Ludovic. Jim Sermersheim wrote: > Regarding replication, I favor allowing implementations to solve their > own consistency problems. A highly usable implementation would allow > for any state attribute to be configured for different levels of > replication consistency (from "never replicated", to whatever the > highest level of consistency available is). This way the admin can > decide how consistently the state data is replicated. > I guess what I'm saying is that I see this as a replication problem in > general, and would rather not solve this level of replication problems > in the password policy I-D by defining multiple sets of attributes and > specifying different grades of replication requirements for each. I do > think it's reasonable to address problems of loose consistency which > is what caused the use of time to be used for things like failure count. > Jim > > >>> Howard Chu < hyc@highlandsun.com > 2/23/05 9:11:53 PM >>> > John McMeeking wrote: > > > I've had some recent requests for some sort of "last login time" > attribute > > or a "unused account" policy so that accounts can be disabled if > they have > > not been used for 6 months. Would either of these be appropriate for the > > password policy draft? > > Both of those sound like good things to have, and it does seem to tie in > to the rest of the password policy features. There would still be > replication issues here. > > It seems to me that one solution to these replicated state attributes > may be to define a second set of attributes - one that is DSA-specific, > never implicitly replicated, and another one that serves as an aggregate > for a collection of servers. Then one can specify policies for each set > independently, e.g., "number of failed attempts" on a single DSA vs > across the network. Sites that require total accountability could set a > policy implementing counts across all replicas, other sites that want to > avoid the overhead of maintaining centralized counts could set a policy > using only dsa-specific attributes. > > -- > -- Howard Chu > Chief Architect, Symas Corp. Director, Highland Sun > _http://www.symas.com < http://www.symas.com/ >_ > _http://highlandsun.com/hyc_ > Symas: Premier OpenSource Development and Support > > _______________________________________________ > Ldapext mailing list > _Ldapext@ietf.org < mailto:Ldapext@ietf.org >_ > _https://www1.ietf.org/mailman/listinfo/ldapext_ > >------------------------------------------------------------------------ > >_______________________________________________ >Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > > -- Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --=__Part785B2945.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sure, but I still don't want to define two attributes for the same = state information. If replicating it seems appropriate, then defining it = as not-DSA Specific is the right thing to do, but beyond that, it feels = like an implementation issue as to whether and how quickly it's replicated.=


>>> Ludovic Poitou <Ludovic.Poitou@Sun.COM> = 2/24/05 7:25:29 AM >>>
Jim,

I tend to agree with you. = But I also see the point of Howard. X.500 and
LDAP both define = different types of Operational Attributes: DSA Specific
and Directory = Operation with specific semantic with regards to the
consistence of = the attribute value in replicated systems.
Defining an operational = attribute and letting implementation (or
administrator) decide if = it'll be replicated or not is actually messing
with the distinctions = between the various operational types.

Ludovic.

Jim = Sermersheim wrote:

> Regarding replication, I favor allowing = implementations to solve their
> own consistency problems. A highly = usable implementation would allow
> for any state attribute to be = configured for different levels of
> replication consistency (from = "never replicated", to whatever the
> highest level of consistency = available is). This way the admin can
> decide how consistently the = state data is replicated.
> I guess what I'm saying is that I see = this as a replication problem in
> general, and would rather not = solve this level of replication problems
> in the password policy = I-D by defining multiple sets of attributes and
> specifying = different grades of replication requirements for each. I do
> think = it's reasonable to address problems of loose consistency which
> is = what caused the use of time to be used for things like failure count.
&g= t; Jim
>
> >>> Howard Chu < hyc@highlandsun.com > 2/23/05 9:11:53 PM = >>>
> John McMeeking wrote:
>
> > I've had = some recent requests for some sort of "last login time"
> attribute<= BR>> > or a "unused account" policy so that accounts can be disabled = if
> they have
> > not been used for 6 months. Would = either of these be appropriate for the
> > password policy = draft?
>
> Both of those sound like good things to have, and = it does seem to tie in
> to the rest of the password policy = features. There would still be
> replication issues here.
>
= > It seems to me that one solution to these replicated state attributes<= BR>> may be to define a second set of attributes - one that is = DSA-specific,
> never implicitly replicated, and another one that = serves as an aggregate
> for a collection of servers. Then one can = specify policies for each set
> independently, e.g., "number of = failed attempts" on a single DSA vs
> across the network. Sites that = require total accountability could set a
> policy implementing = counts across all replicas, other sites that want to
> avoid the = overhead of maintaining centralized counts could set a policy
> = using only dsa-specific attributes.
>
> --
> -- Howard = Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> = _http://www.symas.com < http://www.= symas.com/ >_
> _http://highlandsun.com/hyc_
> = Symas: Premier OpenSource Development and Support
>
> = _______________________________________________
> Ldapext mailing = list
> _Ldapext@ietf.org<= /U> < mailto:Ldapext@ietf.org= >_
> _https://www1.ietf.org/mailman/listinfo/ldapext_
>=
>-------------------------------------------------------------------= -----
>
>_______________________________________________
>= ;Ldapext mailing list
> Ldapex= t@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext =
>
>

--
Ludovic Poitou
Directory Architect.
D= irectory Server Group, Grenoble, France
Sun Microsystems Inc.

Sun= Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This email message is for = the sole use of the intended
recipient(s) and may contain confidential = and privileged
information. Any unauthorized review, use, disclosure = or
distribution is prohibited. If you are not the intended
recipient,= please contact the sender by reply email and destroy
all copies of the = original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~


--=__Part785B2945.1__=-- --===============0828225686== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0828225686==-- From ldapext-bounces@ietf.org Thu Feb 24 14:34:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04879 for ; Thu, 24 Feb 2005 14:34:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4OiO-0001My-UZ; Thu, 24 Feb 2005 14:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4OiM-0001JB-It for ldapext@megatron.ietf.org; Thu, 24 Feb 2005 14:31:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04493 for ; Thu, 24 Feb 2005 14:31:56 -0500 (EST) Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4P5H-0008IA-Dq for ldapext@ietf.org; Thu, 24 Feb 2005 14:55:41 -0500 Received: from mail-mx6.uio.no ([129.240.10.47] ident=[U2FsdGVkX19XNtCA2MTAstqwoBK+3OovggPW923w9tc=]) by pat.uio.no with esmtp (Exim 4.43) id 1D4OiE-0002TK-7t; Thu, 24 Feb 2005 20:31:50 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.43) id 1D4Oi9-000286-Ij; Thu, 24 Feb 2005 20:31:45 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1D4Oi9-0002Kg-4C; Thu, 24 Feb 2005 20:31:45 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Thu, 24 Feb 2005 20:31:45 +0100 To: "Kurt D. Zeilenga" Subject: Re: [ldapext] comment control, dummy request, no-response request In-Reply-To: <6.2.0.14.0.20050224080350.06bc6958@mail.openldap.org> References: <6.2.0.14.0.20050224080350.06bc6958@mail.openldap.org> X-Mailer: VM 7.18 under Emacs 21.3.1 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-4.643, required 12, autolearn=disabled, AWL 0.36, UIO_MAIL_IS_INTERNAL -5.00) X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Kurt D. Zeilenga writes: >At 02:30 PM 2/22/2005, Hallvard B Furuseth wrote: >>"Comment" control: >> >> It can be useful to attach a comment to an LDAP request. > > For what purpose? Tracing or other? That's the use which prompted this suggestion, yes. > (...) > (The point of me asking the above question is to have you > narrow the purpose of the control to one thing.) 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. >> 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 LDAPString would be natural, but sometimes one may >> want to attach data 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. 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. >> So a plain OCTET STRING might >> be better, to be interpreted at the server admin's discretion. > > I rather say that the information provided is to only be used > for trace purposes and is not to be otherwise interpreted or > used. 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. >> "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? > > I am not sure this makes sense, which I will illustrate below. > >> 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). > > 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. 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. > 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. 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. >> 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. > > 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.) >> "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. > > 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. 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. > > I think it generally unwise to attach semantics onto > operations created through use of controls which are not > 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 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 24 15:39:39 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17453 for ; Thu, 24 Feb 2005 15:39:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4PRq-0000zV-Sz; Thu, 24 Feb 2005 15:18:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4PRq-0000zN-3u for ldapext@megatron.ietf.org; Thu, 24 Feb 2005 15:18:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11960 for ; Thu, 24 Feb 2005 15:18:56 -0500 (EST) Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Pom-0001cE-Qn for ldapext@ietf.org; Thu, 24 Feb 2005 15:42:42 -0500 Received: from mail-mx3.uio.no ([129.240.10.44] ident=[U2FsdGVkX1/uPjoIllFcsJSaaEHUrUydqvbdk14eK5w=]) by pat.uio.no with esmtp (Exim 4.43) id 1D4PRk-0004wo-5b; Thu, 24 Feb 2005 21:18:52 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.43) id 1D4PRi-0005xi-PV; Thu, 24 Feb 2005 21:18:50 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1D4PRh-0003qn-Ui; Thu, 24 Feb 2005 21:18:49 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Thu, 24 Feb 2005 21:18:49 +0100 To: "Kurt D. Zeilenga" Subject: Re: [ldapext] draft-zeilenga-ldap-assert-05 notes In-Reply-To: <6.2.0.14.0.20050223215702.06a15670@mail.openldap.org> References: <6.2.0.14.0.20050223215702.06a15670@mail.openldap.org> X-Mailer: VM 7.18 under Emacs 21.3.1 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-4.665, required 12, autolearn=disabled, AWL 0.34, UIO_MAIL_IS_INTERNAL -5.00) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Kurt D. Zeilenga writes: >At 09:35 AM 2/23/2005, Hallvard B Furuseth wrote: >>draft-zeilenga-ldap-assert-05.txt says: >>> 4. Security Considerations >>> >>> As with any general assertion mechanism, the mechanism can be used to >>> determine directory content. Hence, this mechanism SHOULD be subject >>> to appropriate access controls. >> >>I suggest to add something like: >> >> ... preferably the same access controls as search filters. > > Is there a search reason behind this preference? It seemed to fit best the few access control models I know of. If a baseobject search for "(&)" or "(objectClass=*)" returns the entry but a search for some other filter does not, I think Modify with an assertion of that filter should cause assertionFailed. But I must admit I haven't thought through all the variants of this control and access controls even in the models I do know. > I rather not state a preference as part of a security considerations > unless there is a good security related reason for that preference. The security reason I'm aware of is that I got it very wrong the first time I thought of implementing access controls for this control. >> The implementor might find the same access controls as for Compare >> natural, but the server admin might e.g. not want substring matching to >> be possible - and he could have written the Compare ACLs knowing that >> Compare can't do substring matching. Or one might mistakenly use the >> same ACLs as for the "basic" operation being performed, e.g. Modify. > > It seems to be your statements depend greatly on what the > access control model is... I can certainly envision models > where that would not be a mistake. Can you give an example? Hypothetical or not. BTW, another point: The draft says > When the control is attached to an LDAP request, the processing of the > request is conditional on the evaluation of the Filter as applied > against the target of the operation. Except that the control should not prevent the return of a referral, I presume. -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 24 20:09:39 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15245 for ; Thu, 24 Feb 2005 20:09:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Tsz-0000IX-PE; Thu, 24 Feb 2005 20:03:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Tsy-0000IK-Hz for ldapext@megatron.ietf.org; Thu, 24 Feb 2005 20:03:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14446 for ; Thu, 24 Feb 2005 20:03:13 -0500 (EST) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Tsz-0001Ik-AQ for ldapext@ietf.org; Thu, 24 Feb 2005 20:03:18 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j1P136sM002909 for ; Thu, 24 Feb 2005 20:03:06 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1P136St251846 for ; Thu, 24 Feb 2005 20:03:06 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1P135Yt030872 for ; Thu, 24 Feb 2005 20:03:05 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.229.77]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1P135K4030869 for ; Thu, 24 Feb 2005 20:03:05 -0500 In-Reply-To: Subject: Re: [ldapext] draft-behera-ldap-password-policy - last login time To: ldapext@ietf.org X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: John McMeeking Date: Thu, 24 Feb 2005 19:03:02 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 02/24/2005 07:03:05 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org I can't say I'm raising my hand to author a draft, but I agree that this is rather outside the realm of the current password policy and might be better managed in a separate draft. It seems that at least a few people think this is the kind of thing a directory server would reasonably be expected to support. Next question is whether this kind of thing needs to be done in a standard way. Would we expect application developers to be writing application that would need to access these attributes or policies through LDAP? If so, would these be application that would typically be expected to need to support multiple directory vendors with minimal tailoring? Or would they be in-house applications that need only work with the user's current directory? John McMeeking "Jim Sermersheim" wrote on 02/23/2005 11:59:12 PM: > Occasionally we hear requests to add new policy to that draft which > squarely lands in the realm of "login" policy, and other times we > get requests to remove policy like intruder detection as it has more > to do with logging in than management of passwords (though it kind > of leaks into both areas). > > Usually though, consensus seems to point to putting login policy > into a draft of its own. This could also contain things like maximum > concurrent logins and allowed login times. > > If someone could author that I-D, we could possibly define intruder > detection in a way that it could be consumed from a password modify > perspective in the password policy I-D, and consumed from a password > usage perspective in the login policy I-D. > > Or, maybe it would be best to glob everything into a single I-D (my > feeling is this is worse). The problem I see currently is a lack of > resources to push both of these areas of policy forward together in > a coordinated way. > > Jim > > > >>> John McMeeking 2/23/05 1:17:11 PM >>> > > > > > I've had some recent requests for some sort of "last login time" attribute > or a "unused account" policy so that accounts can be disabled if they have > not been used for 6 months. Would either of these be appropriate for the > password policy draft? > > > John McMeeking > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 24 20:50:06 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19003 for ; Thu, 24 Feb 2005 20:50:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Ua8-0000TZ-5r; Thu, 24 Feb 2005 20:47:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Ua6-0000TT-SD for ldapext@megatron.ietf.org; Thu, 24 Feb 2005 20:47:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18890 for ; Thu, 24 Feb 2005 20:47:48 -0500 (EST) Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Ua8-0002TP-CB for ldapext@ietf.org; Thu, 24 Feb 2005 20:47:52 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j1P1lfAa004397 for ; Thu, 24 Feb 2005 20:47:41 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1P1lfm1068254 for ; Thu, 24 Feb 2005 20:47:41 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1P1leD7028336 for ; Thu, 24 Feb 2005 20:47:40 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.229.77]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1P1lenm028331 for ; Thu, 24 Feb 2005 20:47:40 -0500 In-Reply-To: Subject: Re: [ldapext] draft-behera-ldap-password-policy - last login time To: ldapext@ietf.org X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: John McMeeking Date: Thu, 24 Feb 2005 19:47:37 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 02/24/2005 07:47:40 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org I still think single directory first after all these years :-( So I hadn't thought of the replication side. I see the potential for the replication side of this becoming a significant implementation and performance issue. A directory used primarily for authentication generate lots of updates that need to be propagated. Actions on "read-only" replicas affect every server. But if that what someone really needs, they'll accept the price. My first reaction to multiple attributes is to have only one attribute. Then I think of times I have used something like a search for entries with a modifytimestamp > x to find entries that have changed since I last looked. In a replicated environment that may not work. Sometimes I want to know when an entry was changed by a client, and sometimes I want to know when this machine learned of the change. I'll have to think it through some more, but I think it could be a problem having a single attribute that might be the last local login, or might be the last network-wide login. You either need to define a single attribute and say it should always mean X, or define two attributes. It would be a reasonable optimization for a non-replicating server to keep one value but know it by both names. John McMeeking Jim Sermersheim wrote on 02/24/2005 11:05:25 AM: > Sure, but I still don't want to define two attributes for the same > state information. If replicating it seems appropriate, then > defining it as not-DSA Specific is the right thing to do, but beyond > that, it feels like an implementation issue as to whether and how > quickly it's replicated. > > > >>> Ludovic Poitou 2/24/05 7:25:29 AM >>> > Jim, > > I tend to agree with you. But I also see the point of Howard. X.500 and > LDAP both define different types of Operational Attributes: DSA Specific > and Directory Operation with specific semantic with regards to the > consistence of the attribute value in replicated systems. > Defining an operational attribute and letting implementation (or > administrator) decide if it'll be replicated or not is actually messing > with the distinctions between the various operational types. > > Ludovic. > > Jim Sermersheim wrote: > > > Regarding replication, I favor allowing implementations to solve their > > own consistency problems. A highly usable implementation would allow > > for any state attribute to be configured for different levels of > > replication consistency (from "never replicated", to whatever the > > highest level of consistency available is). This way the admin can > > decide how consistently the state data is replicated. > > I guess what I'm saying is that I see this as a replication problem in > > general, and would rather not solve this level of replication problems > > in the password policy I-D by defining multiple sets of attributes and > > specifying different grades of replication requirements for each. I do > > think it's reasonable to address problems of loose consistency which > > is what caused the use of time to be used for things like failure count. > > Jim > > > > >>> Howard Chu < hyc@highlandsun.com > 2/23/05 9:11:53 PM >>> > > John McMeeking wrote: > > > > > I've had some recent requests for some sort of "last login time" > > attribute > > > or a "unused account" policy so that accounts can be disabled if > > they have > > > not been used for 6 months. Would either of these be appropriate for the > > > password policy draft? > > > > Both of those sound like good things to have, and it does seem to tie in > > to the rest of the password policy features. There would still be > > replication issues here. > > > > It seems to me that one solution to these replicated state attributes > > may be to define a second set of attributes - one that is DSA-specific, > > never implicitly replicated, and another one that serves as an aggregate > > for a collection of servers. Then one can specify policies for each set > > independently, e.g., "number of failed attempts" on a single DSA vs > > across the network. Sites that require total accountability could set a > > policy implementing counts across all replicas, other sites that want to > > avoid the overhead of maintaining centralized counts could set a policy > > using only dsa-specific attributes. > > > > -- > > -- Howard Chu > > Chief Architect, Symas Corp. Director, Highland Sun > > _http://www.symas.com < http://www.symas.com/ >_ > > _http://highlandsun.com/hyc_ > > Symas: Premier OpenSource Development and Support > > > > _______________________________________________ > > Ldapext mailing list > > _Ldapext@ietf.org < mailto:Ldapext@ietf.org >_ > > _https://www1.ietf.org/mailman/listinfo/ldapext_ > > > >------------------------------------------------------------------------ > > > >_______________________________________________ > >Ldapext mailing list > > Ldapext@ietf.org > > https://www1.ietf.org/mailman/listinfo/ldapext > > > > > > -- > Ludovic Poitou > Directory Architect. > Directory Server Group, Grenoble, France > Sun Microsystems Inc. > > Sun Microsystems requires the following notice: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > NOTICE: This email message is for the sole use of the intended > recipient(s) and may contain confidential and privileged > information. Any unauthorized review, use, disclosure or > distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply email and destroy > all copies of the original message. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 24 21:51:17 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24043 for ; Thu, 24 Feb 2005 21:51:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4VXH-0000KQ-9k; Thu, 24 Feb 2005 21:48:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4VXD-0000FR-Ta for ldapext@megatron.ietf.org; Thu, 24 Feb 2005 21:48:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23853 for ; Thu, 24 Feb 2005 21:48:53 -0500 (EST) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4VXG-0003ip-2P for ldapext@ietf.org; Thu, 24 Feb 2005 21:48:58 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 24 Feb 2005 19:48:46 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta Date: Thu, 24 Feb 2005 19:48:23 -0700 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] draft-behera-ldap-password-policy - last login time Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0642267537==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0642267537== Content-Type: multipart/alternative; boundary="=__Part426113E7.0__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part426113E7.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit If the use case is that one needs to differentiate between local last login time, and global last login time, I agree, two attributes would be appropriate. But if the use case is that some deployments might prefer no replication, and others might prefer loosely or tightly consistent replication, then I think a single attribute is appropriate. Otherwise, one has to wonder how many attributes being defined (not just in this I-D) fall into the same use case and should also have semi-duplicates defined. Jim >>> John McMeeking 2/24/05 6:47:37 PM >>> I still think single directory first after all these years :-( So I hadn't thought of the replication side. I see the potential for the replication side of this becoming a significant implementation and performance issue. A directory used primarily for authentication generate lots of updates that need to be propagated. Actions on "read-only" replicas affect every server. But if that what someone really needs, they'll accept the price. My first reaction to multiple attributes is to have only one attribute. Then I think of times I have used something like a search for entries with a modifytimestamp > x to find entries that have changed since I last looked. In a replicated environment that may not work. Sometimes I want to know when an entry was changed by a client, and sometimes I want to know when this machine learned of the change. I'll have to think it through some more, but I think it could be a problem having a single attribute that might be the last local login, or might be the last network-wide login. You either need to define a single attribute and say it should always mean X, or define two attributes. It would be a reasonable optimization for a non-replicating server to keep one value but know it by both names. John McMeeking Jim Sermersheim wrote on 02/24/2005 11:05:25 AM: > Sure, but I still don't want to define two attributes for the same > state information. If replicating it seems appropriate, then > defining it as not-DSA Specific is the right thing to do, but beyond > that, it feels like an implementation issue as to whether and how > quickly it's replicated. > > > >>> Ludovic Poitou < Ludovic.Poitou@Sun.COM > 2/24/05 7:25:29 AM >>> > Jim, > > I tend to agree with you. But I also see the point of Howard. X.500 and > LDAP both define different types of Operational Attributes: DSA Specific > and Directory Operation with specific semantic with regards to the > consistence of the attribute value in replicated systems. > Defining an operational attribute and letting implementation (or > administrator) decide if it'll be replicated or not is actually messing > with the distinctions between the various operational types. > > Ludovic. > > Jim Sermersheim wrote: > > > Regarding replication, I favor allowing implementations to solve their > > own consistency problems. A highly usable implementation would allow > > for any state attribute to be configured for different levels of > > replication consistency (from "never replicated", to whatever the > > highest level of consistency available is). This way the admin can > > decide how consistently the state data is replicated. > > I guess what I'm saying is that I see this as a replication problem in > > general, and would rather not solve this level of replication problems > > in the password policy I-D by defining multiple sets of attributes and > > specifying different grades of replication requirements for each. I do > > think it's reasonable to address problems of loose consistency which > > is what caused the use of time to be used for things like failure count. > > Jim > > > > >>> Howard Chu < hyc@highlandsun.com > 2/23/05 9:11:53 PM >>> > > John McMeeking wrote: > > > > > I've had some recent requests for some sort of "last login time" > > attribute > > > or a "unused account" policy so that accounts can be disabled if > > they have > > > not been used for 6 months. Would either of these be appropriate for the > > > password policy draft? > > > > Both of those sound like good things to have, and it does seem to tie in > > to the rest of the password policy features. There would still be > > replication issues here. > > > > It seems to me that one solution to these replicated state attributes > > may be to define a second set of attributes - one that is DSA-specific, > > never implicitly replicated, and another one that serves as an aggregate > > for a collection of servers. Then one can specify policies for each set > > independently, e.g., "number of failed attempts" on a single DSA vs > > across the network. Sites that require total accountability could set a > > policy implementing counts across all replicas, other sites that want to > > avoid the overhead of maintaining centralized counts could set a policy > > using only dsa-specific attributes. > > > > -- > > -- Howard Chu > > Chief Architect, Symas Corp. Director, Highland Sun > > _http://www.symas.com < http://www.symas.com/ >_ > > _http://highlandsun.com/hyc_ > > Symas: Premier OpenSource Development and Support > > > > _______________________________________________ > > Ldapext mailing list > > _Ldapext@ietf.org < mailto:Ldapext@ietf.org >_ > > _https://www1.ietf.org/mailman/listinfo/ldapext_ > > > >------------------------------------------------------------------------ > > > >_______________________________________________ > >Ldapext mailing list > > Ldapext@ietf.org > > https://www1.ietf.org/mailman/listinfo/ldapext > > > > > > -- > Ludovic Poitou > Directory Architect. > Directory Server Group, Grenoble, France > Sun Microsystems Inc. > > Sun Microsystems requires the following notice: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > NOTICE: This email message is for the sole use of the intended > recipient(s) and may contain confidential and privileged > information. Any unauthorized review, use, disclosure or > distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply email and destroy > all copies of the original message. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__Part426113E7.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If the use case is that one needs to differentiate between local last = login time, and global last login time, I agree, two attributes would be = appropriate.
 
But if the use case is that some deployments might prefer no = replication, and others might prefer loosely or tightly consistent = replication, then I think a single attribute is appropriate. Otherwise, = one has to wonder how many attributes being defined (not just in this I-D) = fall into the same use case and should also have semi-duplicates defined.
 
Jim

>>> John McMeeking <jmcmeek@us.ibm.com> = 2/24/05 6:47:37 PM >>>




I still think single = directory first after all these years :-( So I hadn't
thought of the = replication side.

I see the potential for the replication side of = this becoming a significant
implementation and performance issue. A = directory used primarily for
authentication generate lots of updates = that need to be propagated.
Actions on "read-only" replicas affect = every server. But if that what
someone really needs, they'll accept the = price.

My first reaction to multiple attributes is to have only one = attribute.
Then I think of times I have used something like a search = for entries with
a modifytimestamp > x to find entries that have = changed since I last
looked. In a replicated environment that may not = work. Sometimes I want
to know when an entry was changed by a client, = and sometimes I want to know
when this machine learned of the change.
I'll have to think it through some more, but I think it could be a = problem
having a single attribute that might be the last local login, = or might be
the last network-wide login. You either need to define a = single attribute
and say it should always mean X, or define two = attributes. It would be a
reasonable optimization for a non-replicating = server to keep one value but
know it by both names.


John = McMeeking


Jim Sermersheim wrote on 02/24/2005 11:05:25 = AM:

> Sure, but I still don't want to define two attributes for = the same
> state information. If replicating it seems appropriate, = then
> defining it as not-DSA Specific is the right thing to do, but = beyond
> that, it feels like an implementation issue as to whether = and how
> quickly it's replicated.
>
>
> >>&g= t; Ludovic Poitou < Ludovic= .Poitou@Sun.COM > 2/24/05 7:25:29 AM >>>
> = Jim,
>
> I tend to agree with you. But I also see the point of = Howard. X.500 and
> LDAP both define different types of Operational = Attributes: DSA Specific
> and Directory Operation with specific = semantic with regards to the
> consistence of the attribute value in = replicated systems.
> Defining an operational attribute and letting = implementation (or
> administrator) decide if it'll be replicated or = not is actually messing
> with the distinctions between the various = operational types.
>
> Ludovic.
>
> Jim Sermersheim= wrote:
>
> > Regarding replication, I favor allowing = implementations to solve their
> > own consistency problems. A = highly usable implementation would allow
> > for any state = attribute to be configured for different levels of
> > replication= consistency (from "never replicated", to whatever the
> > = highest level of consistency available is). This way the admin can
> = > decide how consistently the state data is replicated.
> > I = guess what I'm saying is that I see this as a replication problem = in
> > general, and would rather not solve this level of = replication problems
> > in the password policy I-D by defining = multiple sets of attributes and
> > specifying different grades = of replication requirements for each. I do
> > think it's = reasonable to address problems of loose consistency which
> > is = what caused the use of time to be used for things like failure
count.> > Jim
> >
> > >>> Howard Chu < = hyc@highlandsun.com > = 2/23/05 9:11:53 PM >>>
> > John McMeeking wrote:
> = >
> > > I've had some recent requests for some sort of = "last login time"
> > attribute
> > > or a "unused = account" policy so that accounts can be disabled if
> > they = have
> > > not been used for 6 months. Would either of these = be appropriate for
the
> > > password policy draft?
> = >
> > Both of those sound like good things to have, and it = does seem to tie
in
> > to the rest of the password policy = features. There would still be
> > replication issues here.
>= ; >
> > It seems to me that one solution to these replicated = state attributes
> > may be to define a second set of attributes = - one that is DSA-specific,
> > never implicitly replicated, and = another one that serves as an
aggregate
> > for a collection = of servers. Then one can specify policies for each set
> > = independently, e.g., "number of failed attempts" on a single DSA vs
>= > across the network. Sites that require total accountability could = set a
> > policy implementing counts across all replicas, other = sites that want
to
> > avoid the overhead of maintaining = centralized counts could set a policy
> > using only dsa-specific = attributes.
> >
> > --
> > -- Howard Chu
>= > Chief Architect, Symas Corp. Director, Highland Sun
> > = _http://www.symas.com < http://www.= symas.com/ >_
> > _http://highlandsun.com/hyc_
> = > Symas: Premier OpenSource Development and Support
> >
>= > _______________________________________________
> > Ldapext = mailing list
> > _Ldapext@= ietf.org < mailto:Ldapext= @ietf.org >_
> > _https://www1.ietf.org/mailman/listinf= o/ldapext_
> >
> >---------------------------------------= ---------------------------------
> >
> >________________= _______________________________
> >Ldapext mailing list
> = > Ldapext@ietf.org =
> > https://www1.ietf.org/mailman/listinfo/ldapext
> >
&g= t; >
>
> --
> Ludovic Poitou
> Directory = Architect.
> Directory Server Group, Grenoble, France
> Sun = Microsystems Inc.
>
> Sun Microsystems requires the following = notice:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~
> NOTICE: This email message is for the sole use of the = intended
> recipient(s) and may contain confidential and privileged> information. Any unauthorized review, use, disclosure or
> = distribution is prohibited. If you are not the intended
> recipient, = please contact the sender by reply email and destroy
> all copies of = the original message.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~
>
> _________________________________________= ______
> Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext=


_______________________________________________
Lda= pext mailing list
Ldapext@ietf.or= g
https://www1.ietf.org/mailman/listinfo/ldapext
--=__Part426113E7.0__=-- --===============0642267537== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0642267537==-- From ldapext-bounces@ietf.org Thu Feb 24 22:49:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28865 for ; Thu, 24 Feb 2005 22:49:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4WRF-0008FU-UG; Thu, 24 Feb 2005 22:46:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4WRB-0008FM-Rf for ldapext@megatron.ietf.org; Thu, 24 Feb 2005 22:46:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28637 for ; Thu, 24 Feb 2005 22:46:43 -0500 (EST) Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4WRE-0004sL-NP for ldapext@ietf.org; Thu, 24 Feb 2005 22:46:49 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.12.9/8.12.9) with ESMTP id j1P3kfKW032009; Thu, 24 Feb 2005 21:46:42 -0600 Message-ID: <421E9F4D.8070600@highlandsun.com> Date: Thu, 24 Feb 2005 19:45:17 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050111 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pierangelo Masarati Subject: Re: [ldapext] Comments to References: <41F6C219.6080509@sys-net.it> In-Reply-To: <41F6C219.6080509@sys-net.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org, "Kurt D. Zeilenga" , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Pierangelo Masarati wrote: > Jim, > > I'm currently implementing the (now expired) version 02 of > in OpenLDAP based on the "chain" > overlay as first implemented by Howard Chu and subsequently extended by > myself. What follows is a collection of considerations that emerged > from the implementation and that, perhaps owing to my lack of > understanding of some details, I think require a clarification and might > be useful for the continuation of the work on the draft. The comments > are quite unsorted. > > 1. Comments I'm a bit skeptical about these features of the draft. X.511 only provides for "preferChaining" and "chainingProhibited." It strikes me that "chainingRequired" (and the implication that a request must fail if chaining is not available) is not useful. In the default case, where the control is not present, and the server does not support chaining, the server would just return a referral and the client would receive it and choose to follow it or drop it. Any client that goes to the effort of implementing this control will receive less information than it had without it. Seems like a lot of effort to go thru to be worse off than you were when you started. From another angle, the decision of whether to deal with referrals or not still resides with the client/App writer, and the server doesn't (and shouldn't have to) care. I would eliminate the chainingRequired behavior, and leave the result code name alone (out of a foolish consistency, perhaps, but it matches the name used in X.511). Further aligning with X.511, I would consider renaming "referralsRequired" to "chainingProhibited" since the two are equivalent. I personally don't see any use for "referralsPreferred" since (a) that's probably the server's default anyway and (b) it's only a preference, and the server will blithely ignore it if it's not the default. If you have a use case in mind I guess I'll let it slide, but surely any LDAP -> X.500 gateways would just delete this in any requests passed along. [By the way, I'm looking at a 2001 4th Edition X.500 draft; if I'm out of date here please disregard...] > 1.1. Return code renaming > I suggest to change the name of "chainingRequired" into > "requiresChaining" to avoid confusion and symbol clashes with the > "requiresChaining" value in the "Behavior" enumeration. > > 1.2. Return code usage clarification > I think you should clarify when the special return codes related to the > control need be returned. For instance, if behavior is > "chainingRequired" and the operation would return a referral that cannot > be chased, I'd return "cannotChain", but for any other "Behavior" case > returning a referral is acceptable, and returning a referral is not an > error: lists "referral" as a non-error > result code in Appendix A.1, so I don't see an application for the other > error code you indicate ("chainingRequired"). I suggest you clarify > your intentions. > > 1.3 OPTIONAL values and defaults > In the draft, both "Behavior" fields are marked as OPTIONAL. My point > is: what's the reason for not providing any? For instance, the "chain" > overlay in OpenLDAP's slapd by default acts as if both "Behavior" were > "chainingPreferred". If the control is present, but no values are > given, I see no point in using the control. Unless you mean that the > default behavior of the DSA may differ if the control is present or not; > e.g. if no control is present, default to "referralsRequired", while if > the control is present, default to "chainingPreferred" (OpenLDAP's slapd > without and with the "chain" overlay), and in any case both defaults are > left to the implementor. If this is the case, I suggest it is clarified. > [technical note: it is not clear to me if, in case none of the values is > provided, the crtls_value of the control structure should be empty or > null]. > > 1.4 Operations. > It appears from the draft that the control applies to all operations, > except "abandon, unbind, and StartTLS"; the second value applies only to > search continuations, and may apply to future operations. Should the > presence of the second value in other operations among those already > defined that do not require it be treated as an error? I think this > should be clarified. > > 1.5 Behavior > 1.5.1. "chainingPreferred" and "referralsPreferred" don't present any > issue; > 1.5.2. "chainingRequired" might be an issue if, in case it cannot be > honored, no intermediate results should be returned at all (I'm talking > about searches). In fact, unless caching all intermediate results > locally upon completion, it is very likely that a referral is met after > some entries/other intermediate results have already been returned. If > the referral cannot be chased, the operation should be terminated and > "cannotChain" be returned. I think it should be clarified if this > behavior is acceptable or not. > 1.5.3 "referralsRequired" should never fail, because that's the regular > behavior in case no chaining capabilities are available; I don't see any > issue that might prevent a DSA from returning a referral. Can you > clarify why this option is ever supposed to fail? > > 1.6. Criticality > I think the behavior should be discussed in view of the criticality of > the control. Would it be correct to simply ignore the "Behavior" in > case the control is not critical? It is my understanding that only the > "chainingRequired" behavior may suffer from the criticality field being > set when referrals cannot be chased; the other options should pose no > issues. How should the behavior differ in this case based on the value > of the criticality flag? > > 2. Few notes on the implementation. > > 2.1. Approach > The "chain" overlay in OpenLDAP's slapd uses the LDAP backend to chase > referrals in case they're being returned by the underlying backend (or > at the frontend level, if used as a global overlay). Credits for both > the overlay and the underlying LDAP backend essentially go to Howard Chu. > > 2.2. Authorization and Security > As such, it can exploit the identity assertion capabilities of back-ldap > to proxyAuthz the identity of the client while chasing the referral; > this provides features like SASL bind, authorization policies based on > pattern matching, grouping and so both at the local and at the remote > site. The connection can be wrapped in a TLS layer (use ldaps:// > referral URIs, or StartTLS over regular ldap:// URIs). > > 2.3. Relationship with other extensions > Interaction with the "manageDSAit" control as described in the draft, > although not intended, seems to work as described in the draft. Of > course it may need further testing. > > 2.4. Missing features and possible development > I plan to introduce: > 2.4.1. authorization based on referral suffix (e.g. only chain requests > rooted at ) > 2.4.2. authorization based on the referral URI (host/port portion) > 2.4.3. authorization based on the protocol scheme (e.g. only ldaps://) > 2.4.4. authorization based on some ssf > 2.4.5. to allow chaining of multiple DSAs, back-ldap's identity > assertion must be modified to allow authentication identity selection > based on the DSA that is being chained (now a single identity can be > specified, since back-ldap is intended to contact a single URI). > 2.4.6. it is not clear yet how the control could interact with further > referral chasing operated at the client library's level by the LDAP > backend (proxyAuthz and so). > 2.4.7 there's yet no provisions to check for loops and so. > > 2.5. Specific numbers and #defines > I'm currently using OIDs and return codes under OpenLDAP's/private > space; the macros and the numbers are(from OpenLDAP's HEAD ldap.h): > > /* LDAP Chaining Behavior Control *//* work in progress */ > /* ; > * see also LDAP_REQUIRES_CHAINING, LDAP_CANNOT_CHAIN */ > #ifdef LDAP_DEVEL > #define LDAP_CONTROL_X_CHAINING_BEHAVIOR "1.3.6.1.4.1.4203.666.11.3" > > #define LDAP_CHAINING_PREFERRED 0 > #define LDAP_CHAINING_REQUIRED 1 > #define LDAP_REFERRALS_PREFERRED 2 > #define LDAP_REFERRALS_REQUIRED 3 > #endif > > /* for the Chaining Behavior control (consecutive result codes requested; > * see ) */ > #ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR > #define LDAP_REQUIRES_CHAINING 0x4110 > #define LDAP_CANNOT_CHAIN 0x4111 > #endif > > > I hope the discussion above, and the quick overview on the current > implementation and its todo list, may be of help in stabilizing and > completing the draft. > > Sincerely, p. > > > > > SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497 > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 24 22:59:41 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00264 for ; Thu, 24 Feb 2005 22:59:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Wae-0004uV-PN; Thu, 24 Feb 2005 22:56:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Wac-0004uJ-Kf for ldapext@megatron.ietf.org; Thu, 24 Feb 2005 22:56:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29743 for ; Thu, 24 Feb 2005 22:56:28 -0500 (EST) Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Waf-000572-ON for ldapext@ietf.org; Thu, 24 Feb 2005 22:56:34 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.12.9/8.12.9) with ESMTP id j1P3uRKW032171; Thu, 24 Feb 2005 21:56:27 -0600 Message-ID: <421EA196.907@highlandsun.com> Date: Thu, 24 Feb 2005 19:55:02 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050111 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John McMeeking Subject: Re: [ldapext] draft-behera-ldap-password-policy - last login time References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit John McMeeking wrote: > My first reaction to multiple attributes is to have only one attribute. > Then I think of times I have used something like a search for entries with > a modifytimestamp > x to find entries that have changed since I last > looked. In a replicated environment that may not work. Sometimes I want > to know when an entry was changed by a client, and sometimes I want to know > when this machine learned of the change. The X.500 "dontUseCopy" control (and presumably draft-zeilenga-ldap-dontusecopy) would answer that need, if modifyTimestamp was always locally generated. But that solution doesn't solve the problem for last login time... > John McMeeking > > > Jim Sermersheim wrote on 02/24/2005 11:05:25 AM: > > >>Sure, but I still don't want to define two attributes for the same >>state information. If replicating it seems appropriate, then >>defining it as not-DSA Specific is the right thing to do, but beyond >>that, it feels like an implementation issue as to whether and how >>quickly it's replicated. >> >> >> >>>>>Ludovic Poitou 2/24/05 7:25:29 AM >>> >> >>Jim, >> >>I tend to agree with you. But I also see the point of Howard. X.500 and >>LDAP both define different types of Operational Attributes: DSA Specific >>and Directory Operation with specific semantic with regards to the >>consistence of the attribute value in replicated systems. >>Defining an operational attribute and letting implementation (or >>administrator) decide if it'll be replicated or not is actually messing >>with the distinctions between the various operational types. >> >>Ludovic. >> >>Jim Sermersheim wrote: >> >> >>>Regarding replication, I favor allowing implementations to solve their >>>own consistency problems. A highly usable implementation would allow >>>for any state attribute to be configured for different levels of >>>replication consistency (from "never replicated", to whatever the >>>highest level of consistency available is). This way the admin can >>>decide how consistently the state data is replicated. >>>I guess what I'm saying is that I see this as a replication problem in >>>general, and would rather not solve this level of replication problems >>>in the password policy I-D by defining multiple sets of attributes and >>>specifying different grades of replication requirements for each. I do >>>think it's reasonable to address problems of loose consistency which >>>is what caused the use of time to be used for things like failure > > count. > >>>Jim >>> >>> >>>>>>Howard Chu < hyc@highlandsun.com > 2/23/05 9:11:53 PM >>> >>> >>>John McMeeking wrote: >>> >>> >>>>I've had some recent requests for some sort of "last login time" >>> >>>attribute >>> >>>>or a "unused account" policy so that accounts can be disabled if >>> >>>they have >>> >>>>not been used for 6 months. Would either of these be appropriate for > > the > >>>>password policy draft? >>> >>>Both of those sound like good things to have, and it does seem to tie > > in > >>>to the rest of the password policy features. There would still be >>>replication issues here. >>> >>>It seems to me that one solution to these replicated state attributes >>>may be to define a second set of attributes - one that is DSA-specific, >>>never implicitly replicated, and another one that serves as an > > aggregate > >>>for a collection of servers. Then one can specify policies for each set >>>independently, e.g., "number of failed attempts" on a single DSA vs >>>across the network. Sites that require total accountability could set a >>>policy implementing counts across all replicas, other sites that want > > to > >>>avoid the overhead of maintaining centralized counts could set a policy >>>using only dsa-specific attributes. >>> >>>-- >>>-- Howard Chu >>>Chief Architect, Symas Corp. Director, Highland Sun >>>_http://www.symas.com < http://www.symas.com/ >_ >>>_http://highlandsun.com/hyc_ >>>Symas: Premier OpenSource Development and Support >>> >>>_______________________________________________ >>>Ldapext mailing list >>>_Ldapext@ietf.org < mailto:Ldapext@ietf.org >_ >>>_https://www1.ietf.org/mailman/listinfo/ldapext_ >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>Ldapext mailing list >>>Ldapext@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ldapext >>> >>> >> >>-- >>Ludovic Poitou >>Directory Architect. >>Directory Server Group, Grenoble, France >>Sun Microsystems Inc. >> >>Sun Microsystems requires the following notice: >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>NOTICE: This email message is for the sole use of the intended >>recipient(s) and may contain confidential and privileged >>information. Any unauthorized review, use, disclosure or >>distribution is prohibited. If you are not the intended >>recipient, please contact the sender by reply email and destroy >>all copies of the original message. >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >>_______________________________________________ >>Ldapext mailing list >>Ldapext@ietf.org >>https://www1.ietf.org/mailman/listinfo/ldapext > > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 24 23:01:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00464 for ; Thu, 24 Feb 2005 23:01:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Wci-0006bi-AV; Thu, 24 Feb 2005 22:58:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Wcg-0006a0-AN for ldapext@megatron.ietf.org; Thu, 24 Feb 2005 22:58:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00114 for ; Thu, 24 Feb 2005 22:58:35 -0500 (EST) Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Wci-0005DB-7d for ldapext@ietf.org; Thu, 24 Feb 2005 22:58:41 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.12.9/8.12.9) with ESMTP id j1P3wXKW032216; Thu, 24 Feb 2005 21:58:33 -0600 Message-ID: <421EA214.2000705@highlandsun.com> Date: Thu, 24 Feb 2005 19:57:08 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050111 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] draft-behera-ldap-password-policy - last login time References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: 7bit Cc: jmcmeek@us.ibm.com, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: > If the use case is that one needs to differentiate between local last > login time, and global last login time, I agree, two attributes would be > appropriate. > > But if the use case is that some deployments might prefer no > replication, and others might prefer loosely or tightly consistent > replication, then I think a single attribute is appropriate. Otherwise, > one has to wonder how many attributes being defined (not just in this > I-D) fall into the same use case and should also have semi-duplicates > defined. That's a good point. Perhaps instead of a second set of attribute definitions, there should just be a subentry devoted to carrying the global state. > Jim > > >>> John McMeeking 2/24/05 6:47:37 PM >>> > > > > > I still think single directory first after all these years :-( So I hadn't > thought of the replication side. > > I see the potential for the replication side of this becoming a significant > implementation and performance issue. A directory used primarily for > authentication generate lots of updates that need to be propagated. > Actions on "read-only" replicas affect every server. But if that what > someone really needs, they'll accept the price. > > My first reaction to multiple attributes is to have only one attribute. > Then I think of times I have used something like a search for entries with > a modifytimestamp > x to find entries that have changed since I last > looked. In a replicated environment that may not work. Sometimes I want > to know when an entry was changed by a client, and sometimes I want to know > when this machine learned of the change. > > I'll have to think it through some more, but I think it could be a problem > having a single attribute that might be the last local login, or might be > the last network-wide login. You either need to define a single attribute > and say it should always mean X, or define two attributes. It would be a > reasonable optimization for a non-replicating server to keep one value but > know it by both names. > > > John McMeeking > > > Jim Sermersheim wrote on 02/24/2005 11:05:25 AM: > > > Sure, but I still don't want to define two attributes for the same > > state information. If replicating it seems appropriate, then > > defining it as not-DSA Specific is the right thing to do, but beyond > > that, it feels like an implementation issue as to whether and how > > quickly it's replicated. > > > > > > >>> Ludovic Poitou <_ Ludovic.Poitou@Sun.COM > _ > 2/24/05 7:25:29 AM >>> > > Jim, > > > > I tend to agree with you. But I also see the point of Howard. X.500 and > > LDAP both define different types of Operational Attributes: DSA Specific > > and Directory Operation with specific semantic with regards to the > > consistence of the attribute value in replicated systems. > > Defining an operational attribute and letting implementation (or > > administrator) decide if it'll be replicated or not is actually messing > > with the distinctions between the various operational types. > > > > Ludovic. > > > > Jim Sermersheim wrote: > > > > > Regarding replication, I favor allowing implementations to solve their > > > own consistency problems. A highly usable implementation would allow > > > for any state attribute to be configured for different levels of > > > replication consistency (from "never replicated", to whatever the > > > highest level of consistency available is). This way the admin can > > > decide how consistently the state data is replicated. > > > I guess what I'm saying is that I see this as a replication problem in > > > general, and would rather not solve this level of replication problems > > > in the password policy I-D by defining multiple sets of attributes and > > > specifying different grades of replication requirements for each. I do > > > think it's reasonable to address problems of loose consistency which > > > is what caused the use of time to be used for things like failure > count. > > > Jim > > > > > > >>> Howard Chu < _hyc@highlandsun.com _ > > 2/23/05 9:11:53 PM >>> > > > John McMeeking wrote: > > > > > > > I've had some recent requests for some sort of "last login time" > > > attribute > > > > or a "unused account" policy so that accounts can be disabled if > > > they have > > > > not been used for 6 months. Would either of these be appropriate for > the > > > > password policy draft? > > > > > > Both of those sound like good things to have, and it does seem to tie > in > > > to the rest of the password policy features. There would still be > > > replication issues here. > > > > > > It seems to me that one solution to these replicated state attributes > > > may be to define a second set of attributes - one that is DSA-specific, > > > never implicitly replicated, and another one that serves as an > aggregate > > > for a collection of servers. Then one can specify policies for each set > > > independently, e.g., "number of failed attempts" on a single DSA vs > > > across the network. Sites that require total accountability could set a > > > policy implementing counts across all replicas, other sites that want > to > > > avoid the overhead of maintaining centralized counts could set a policy > > > using only dsa-specific attributes. > > > > > > -- > > > -- Howard Chu > > > Chief Architect, Symas Corp. Director, Highland Sun > > > _http://www.symas.com < _http://www.symas.com/_ >_ > > > _http://highlandsun.com/hyc_ > > > Symas: Premier OpenSource Development and Support > > > > > > _______________________________________________ > > > Ldapext mailing list > > > __Ldapext@ietf.org _ < > _mailto:Ldapext@ietf.org_ >_ > > > _https://www1.ietf.org/mailman/listinfo/ldapext_ > > > > > >------------------------------------------------------------------------ > > > > > >_______________________________________________ > > >Ldapext mailing list > > > _Ldapext@ietf.org _ > > > _https://www1.ietf.org/mailman/listinfo/ldapext_ > > > > > > > > > > -- > > Ludovic Poitou > > Directory Architect. > > Directory Server Group, Grenoble, France > > Sun Microsystems Inc. > > > > Sun Microsystems requires the following notice: > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > NOTICE: This email message is for the sole use of the intended > > recipient(s) and may contain confidential and privileged > > information. Any unauthorized review, use, disclosure or > > distribution is prohibited. If you are not the intended > > recipient, please contact the sender by reply email and destroy > > all copies of the original message. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 24 23:47:08 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04879 for ; Thu, 24 Feb 2005 23:47:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4XMw-0000sa-V8; Thu, 24 Feb 2005 23:46:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4XMo-0000cT-70 for ldapext@megatron.ietf.org; Thu, 24 Feb 2005 23:46:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04834 for ; Thu, 24 Feb 2005 23:46:15 -0500 (EST) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4XMr-0006FF-Gw for ldapext@ietf.org; Thu, 24 Feb 2005 23:46:22 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 24 Feb 2005 21:46:08 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta Date: Thu, 24 Feb 2005 21:45:57 -0700 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] Comments to Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Content-Transfer-Encoding: 7bit Cc: Kurt@OpenLDAP.org, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit I have to admit that I disliked the names and limited usefulnes of the controls as they are defined in X.511, and that may have influenced me to simply define them in a symmetrical and (to me) more clear way for LDAP. I see usefulness in chainingRequired. For example, assume a client wishes to perform a SSS or VLV search operation and knows that the data in the result set may be distributed (and perhaps further assume some DSAs support chaining these operations). If the client can specify chainingRequired, it would know that the results it gets back are already sorted and no extra work needs to be done. If the server cannot, or will not chain, then the operation fails, and the client learns this up front. In the absence of chainingRequired, the client may get back many search results -- assuming they're sorted, only to find out in the end that one or more search result references need to be followed to complete the operation. I believe that chainingRequired may also be useful for other multi-object operations which are served best (or can only be completed) by the act of DSA chaining. Off the top of my head, I can't think of a strong case for chainingRequired during name resolution (otehr than the case I make below for referralsPreferred), but I see no harm in allowing it's specification. I also see usefulness in referralsPreferred. It allows one to possibly override whatever the server's behavior is. We have deployments where the server's setting is chainingPreferred or chainingRequired. Clients may prefer to receive referrals, yet want the operation to be chained when policy prevents a referral from being returned. Jim >>> Howard Chu 02/24/05 8:45 PM >>> Pierangelo Masarati wrote: > Jim, > > I'm currently implementing the (now expired) version 02 of > in OpenLDAP based on the "chain" > overlay as first implemented by Howard Chu and subsequently extended by > myself. What follows is a collection of considerations that emerged > from the implementation and that, perhaps owing to my lack of > understanding of some details, I think require a clarification and might > be useful for the continuation of the work on the draft. The comments > are quite unsorted. > > 1. Comments I'm a bit skeptical about these features of the draft. X.511 only provides for "preferChaining" and "chainingProhibited." It strikes me that "chainingRequired" (and the implication that a request must fail if chaining is not available) is not useful. In the default case, where the control is not present, and the server does not support chaining, the server would just return a referral and the client would receive it and choose to follow it or drop it. Any client that goes to the effort of implementing this control will receive less information than it had without it. Seems like a lot of effort to go thru to be worse off than you were when you started. From another angle, the decision of whether to deal with referrals or not still resides with the client/App writer, and the server doesn't (and shouldn't have to) care. I would eliminate the chainingRequired behavior, and leave the result code name alone (out of a foolish consistency, perhaps, but it matches the name used in X.511). Further aligning with X.511, I would consider renaming "referralsRequired" to "chainingProhibited" since the two are equivalent. I personally don't see any use for "referralsPreferred" since (a) that's probably the server's default anyway and (b) it's only a preference, and the server will blithely ignore it if it's not the default. If you have a use case in mind I guess I'll let it slide, but surely any LDAP -> X.500 gateways would just delete this in any requests passed along. [By the way, I'm looking at a 2001 4th Edition X.500 draft; if I'm out of date here please disregard...] > 1.1. Return code renaming > I suggest to change the name of "chainingRequired" into > "requiresChaining" to avoid confusion and symbol clashes with the > "requiresChaining" value in the "Behavior" enumeration. > > 1.2. Return code usage clarification > I think you should clarify when the special return codes related to the > control need be returned. For instance, if behavior is > "chainingRequired" and the operation would return a referral that cannot > be chased, I'd return "cannotChain", but for any other "Behavior" case > returning a referral is acceptable, and returning a referral is not an > error: lists "referral" as a non-error > result code in Appendix A.1, so I don't see an application for the other > error code you indicate ("chainingRequired"). I suggest you clarify > your intentions. > > 1.3 OPTIONAL values and defaults > In the draft, both "Behavior" fields are marked as OPTIONAL. My point > is: what's the reason for not providing any? For instance, the "chain" > overlay in OpenLDAP's slapd by default acts as if both "Behavior" were > "chainingPreferred". If the control is present, but no values are > given, I see no point in using the control. Unless you mean that the > default behavior of the DSA may differ if the control is present or not; > e.g. if no control is present, default to "referralsRequired", while if > the control is present, default to "chainingPreferred" (OpenLDAP's slapd > without and with the "chain" overlay), and in any case both defaults are > left to the implementor. If this is the case, I suggest it is clarified. > [technical note: it is not clear to me if, in case none of the values is > provided, the crtls_value of the control structure should be empty or > null]. > > 1.4 Operations. > It appears from the draft that the control applies to all operations, > except "abandon, unbind, and StartTLS"; the second value applies only to > search continuations, and may apply to future operations. Should the > presence of the second value in other operations among those already > defined that do not require it be treated as an error? I think this > should be clarified. > > 1.5 Behavior > 1.5.1. "chainingPreferred" and "referralsPreferred" don't present any > issue; > 1.5.2. "chainingRequired" might be an issue if, in case it cannot be > honored, no intermediate results should be returned at all (I'm talking > about searches). In fact, unless caching all intermediate results > locally upon completion, it is very likely that a referral is met after > some entries/other intermediate results have already been returned. If > the referral cannot be chased, the operation should be terminated and > "cannotChain" be returned. I think it should be clarified if this > behavior is acceptable or not. > 1.5.3 "referralsRequired" should never fail, because that's the regular > behavior in case no chaining capabilities are available; I don't see any > issue that might prevent a DSA from returning a referral. Can you > clarify why this option is ever supposed to fail? > > 1.6. Criticality > I think the behavior should be discussed in view of the criticality of > the control. Would it be correct to simply ignore the "Behavior" in > case the control is not critical? It is my understanding that only the > "chainingRequired" behavior may suffer from the criticality field being > set when referrals cannot be chased; the other options should pose no > issues. How should the behavior differ in this case based on the value > of the criticality flag? > > 2. Few notes on the implementation. > > 2.1. Approach > The "chain" overlay in OpenLDAP's slapd uses the LDAP backend to chase > referrals in case they're being returned by the underlying backend (or > at the frontend level, if used as a global overlay). Credits for both > the overlay and the underlying LDAP backend essentially go to Howard Chu. > > 2.2. Authorization and Security > As such, it can exploit the identity assertion capabilities of back-ldap > to proxyAuthz the identity of the client while chasing the referral; > this provides features like SASL bind, authorization policies based on > pattern matching, grouping and so both at the local and at the remote > site. The connection can be wrapped in a TLS layer (use ldaps:// > referral URIs, or StartTLS over regular ldap:// URIs). > > 2.3. Relationship with other extensions > Interaction with the "manageDSAit" control as described in the draft, > although not intended, seems to work as described in the draft. Of > course it may need further testing. > > 2.4. Missing features and possible development > I plan to introduce: > 2.4.1. authorization based on referral suffix (e.g. only chain requests > rooted at ) > 2.4.2. authorization based on the referral URI (host/port portion) > 2.4.3. authorization based on the protocol scheme (e.g. only ldaps://) > 2.4.4. authorization based on some ssf > 2.4.5. to allow chaining of multiple DSAs, back-ldap's identity > assertion must be modified to allow authentication identity selection > based on the DSA that is being chained (now a single identity can be > specified, since back-ldap is intended to contact a single URI). > 2.4.6. it is not clear yet how the control could interact with further > referral chasing operated at the client library's level by the LDAP > backend (proxyAuthz and so). > 2.4.7 there's yet no provisions to check for loops and so. > > 2.5. Specific numbers and #defines > I'm currently using OIDs and return codes under OpenLDAP's/private > space; the macros and the numbers are(from OpenLDAP's HEAD ldap.h): > > /* LDAP Chaining Behavior Control *//* work in progress */ > /* ; > * see also LDAP_REQUIRES_CHAINING, LDAP_CANNOT_CHAIN */ > #ifdef LDAP_DEVEL > #define LDAP_CONTROL_X_CHAINING_BEHAVIOR "1.3.6.1.4.1.4203.666.11.3" > > #define LDAP_CHAINING_PREFERRED 0 > #define LDAP_CHAINING_REQUIRED 1 > #define LDAP_REFERRALS_PREFERRED 2 > #define LDAP_REFERRALS_REQUIRED 3 > #endif > > /* for the Chaining Behavior control (consecutive result codes requested; > * see ) */ > #ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR > #define LDAP_REQUIRES_CHAINING 0x4110 > #define LDAP_CANNOT_CHAIN 0x4111 > #endif > > > I hope the discussion above, and the quick overview on the current > implementation and its todo list, may be of help in stabilizing and > completing the draft. > > Sincerely, p. > > > > > SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497 > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Feb 25 01:12:02 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13045 for ; Fri, 25 Feb 2005 01:12:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Ygd-0001oW-UF; Fri, 25 Feb 2005 01:10:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4YgR-0001o5-L3 for ldapext@megatron.ietf.org; Fri, 25 Feb 2005 01:10:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12865 for ; Fri, 25 Feb 2005 01:10:39 -0500 (EST) Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4YgW-0008Cg-8s for ldapext@ietf.org; Fri, 25 Feb 2005 01:10:44 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.12.9/8.12.9) with ESMTP id j1P6AZCT002105; Fri, 25 Feb 2005 00:10:36 -0600 Message-ID: <421EC13E.3090108@highlandsun.com> Date: Thu, 24 Feb 2005 22:10:06 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050111 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Comments to References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: Kurt@OpenLDAP.org, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: > I have to admit that I disliked the names and limited usefulnes of the > controls as they are defined in X.511, and that may have influenced me > to simply define them in a symmetrical and (to me) more clear way for > LDAP. Fair enough, I can appreciate symmetry... > I see usefulness in chainingRequired. For example, assume a client > wishes to perform a SSS or VLV search operation and knows that the data > in the result set may be distributed (and perhaps further assume some > DSAs support chaining these operations). If the client can specify > chainingRequired, it would know that the results it gets back are > already sorted and no extra work needs to be done. If the server cannot, > or will not chain, then the operation fails, and the client learns this > up front. In the absence of chainingRequired, the client may get back > many search results -- assuming they're sorted, only to find out in the > end that one or more search result references need to be followed to > complete the operation. I believe you're seeing a false economy here. The point is, why did the client ask the question it asked - presumably, because it wanted some data. If your client sends a request with e.g. SSS, the server will proceed to gather results up, find that it can't obey the Chaining control, and return an error to the client. But as far as I can see, the client still wanted that data, else why did it ask in the first place. The client can just give up and say "sorry, I can't get what you want in my preferred fashion" but the more useful thing for it to do is to retry the request and make do with whatever results it gets. In that case, you've just doubled the amount of work the server has to do, because the client will re-issue the same request, with relaxed controls. Nothing changes the fact that extra work needs to be done by the client, (or it must just fail); the presence of the control doesn't help matters in any way. Also, this SSS example isn't quite right - obviously a server needs to gather up the complete result set before it can begin returning sorted results to the client. As such, it will already know if references are present before sending any results to the client. It would be wrong for the server to begin sending entries back knowing that the result set contains unresolved references, so that search should automatically fail in the absence of chaining. Indeed, RFC2891 pretty much dictates that the request will fail, in section 2.1. In this regard, I would prefer that that spec be changed to require servers to send unresolved references first, ahead of regular entries, and let the client decide whether it wants to slog through or give up. Cutting off the information at the server prevents the DUA user from making an informed decision about what to do next. Giving the information to the client allows the possibility of a graceful recovery. > I believe that chainingRequired may also be > useful for other multi-object operations which are served best (or can > only be completed) by the act of DSA chaining. Off the top of my head, I > can't think of a strong case for chainingRequired during name resolution > (otehr than the case I make below for referralsPreferred), but I see no > harm in allowing it's specification. I believe the harm is in preventing useful information from reaching the client, thus making error recovery messier and more expensive than it needs to be. > I also see usefulness in referralsPreferred. It allows one to possibly > override whatever the server's behavior is. We have deployments where > the server's setting is chainingPreferred or chainingRequired. Clients > may prefer to receive referrals, yet want the operation to be chained > when policy prevents a referral from being returned. To me, the absence of any chaining control already implies "referralsPreferred" but I'll have to think about it some more. It becomes useful if you assume that the client knows more about the referred server than the original DSA knows. Personally I believe this assumption is seldom true, but I guess I can't say "never" so I'll leave this alone for now. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Feb 25 10:42:24 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00435 for ; Fri, 25 Feb 2005 10:42:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4hZ3-0007T5-JA; Fri, 25 Feb 2005 10:39:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4hZ1-0007Sn-Nh for ldapext@megatron.ietf.org; Fri, 25 Feb 2005 10:39:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00192 for ; Fri, 25 Feb 2005 10:39:32 -0500 (EST) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4hZA-0004Jq-49 for ldapext@ietf.org; Fri, 25 Feb 2005 10:39:44 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 25 Feb 2005 08:39:25 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta Date: Fri, 25 Feb 2005 08:39:00 -0700 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Comments to Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit Cc: Kurt@OpenLDAP.org, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Ugh, now we're going to get into gritty implementation details of VLV and SSS -- I shoulda used a different example. Our (and I imagine other) implementations will service VLV and SSS controls using an index if possible. In this case, entries may be immediately returned as they are matched (as opposed to gathered, sorted, then returned). In this scenario, (unless your proposed change to SSS happens) a client may need to wade through many results *before* it can even decide whether to begin presenting returned entries to a user interface for exmple. This is because the server is free to return referrals at any point (2.1 of rfc2891 does not excuse this). In my example, the client did want data as you say, but only under certain circumstances. When a number of DSAs hold copies of portions of the tree, the client may need to contact a series of altServers in order to locate one that can service the request in the manner that the client wishes. Only after exhausting all DSAs might the client wish to fail over to performing the distributed search and merge sort the results. I still don't see there being harm in, as you say, preventing useful information from reaching the client. The client is aware of what it's asking for, and has chosen to ask for a certain behavior. If the client wishes for a different behavior, it should ask for different behavior. There's a kind of unrelated analogy to the criticality of controls here. A client may wish to make a control critical to prevent the server from performing the requested task (even though performing it might result in useful information being returned) if it cannot service the request in the exact way the client wants. The final point is that there are implementations (two that I know of) which allow all four of these behaviors to be set on a server-wide basis, and the control can be used to override the server's behavior. One implementation currently has its installation default as chainingPreferred, the other has it as chainingRequired. The implementation which defaults to chainingPreferred has been available and widely used (most deployments are left in chainingPreferred mode) for over ten years, so in my mind, there are a lot of people who assume that in the absence of any control, their request is going to be chained. Assumptions aside, it's the DSA's choice, and this control allows as much flexibility as I could imagine is needed for today's and tomorrow's need to override the server's default behavior. Jim >>> Howard Chu 2/24/05 11:10:06 PM >>> Jim Sermersheim wrote: > I have to admit that I disliked the names and limited usefulnes of the > controls as they are defined in X.511, and that may have influenced me > to simply define them in a symmetrical and (to me) more clear way for > LDAP. Fair enough, I can appreciate symmetry... > I see usefulness in chainingRequired. For example, assume a client > wishes to perform a SSS or VLV search operation and knows that the data > in the result set may be distributed (and perhaps further assume some > DSAs support chaining these operations). If the client can specify > chainingRequired, it would know that the results it gets back are > already sorted and no extra work needs to be done. If the server cannot, > or will not chain, then the operation fails, and the client learns this > up front. In the absence of chainingRequired, the client may get back > many search results -- assuming they're sorted, only to find out in the > end that one or more search result references need to be followed to > complete the operation. I believe you're seeing a false economy here. The point is, why did the client ask the question it asked - presumably, because it wanted some data. If your client sends a request with e.g. SSS, the server will proceed to gather results up, find that it can't obey the Chaining control, and return an error to the client. But as far as I can see, the client still wanted that data, else why did it ask in the first place. The client can just give up and say "sorry, I can't get what you want in my preferred fashion" but the more useful thing for it to do is to retry the request and make do with whatever results it gets. In that case, you've just doubled the amount of work the server has to do, because the client will re-issue the same request, with relaxed controls. Nothing changes the fact that extra work needs to be done by the client, (or it must just fail); the presence of the control doesn't help matters in any way. Also, this SSS example isn't quite right - obviously a server needs to gather up the complete result set before it can begin returning sorted results to the client. As such, it will already know if references are present before sending any results to the client. It would be wrong for the server to begin sending entries back knowing that the result set contains unresolved references, so that search should automatically fail in the absence of chaining. Indeed, RFC2891 pretty much dictates that the request will fail, in section 2.1. In this regard, I would prefer that that spec be changed to require servers to send unresolved references first, ahead of regular entries, and let the client decide whether it wants to slog through or give up. Cutting off the information at the server prevents the DUA user from making an informed decision about what to do next. Giving the information to the client allows the possibility of a graceful recovery. > I believe that chainingRequired may also be > useful for other multi-object operations which are served best (or can > only be completed) by the act of DSA chaining. Off the top of my head, I > can't think of a strong case for chainingRequired during name resolution > (otehr than the case I make below for referralsPreferred), but I see no > harm in allowing it's specification. I believe the harm is in preventing useful information from reaching the client, thus making error recovery messier and more expensive than it needs to be. > I also see usefulness in referralsPreferred. It allows one to possibly > override whatever the server's behavior is. We have deployments where > the server's setting is chainingPreferred or chainingRequired. Clients > may prefer to receive referrals, yet want the operation to be chained > when policy prevents a referral from being returned. To me, the absence of any chaining control already implies "referralsPreferred" but I'll have to think about it some more. It becomes useful if you assume that the client knows more about the referred server than the original DSA knows. Personally I believe this assumption is seldom true, but I guess I can't say "never" so I'll leave this alone for now. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Feb 25 15:09:27 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25108 for ; Fri, 25 Feb 2005 15:09:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4lkY-0003B8-3V; Fri, 25 Feb 2005 15:07:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4lkX-0003B2-9r for ldapext@megatron.ietf.org; Fri, 25 Feb 2005 15:07:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24701 for ; Fri, 25 Feb 2005 15:07:43 -0500 (EST) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4lkh-0001cb-Hb for ldapext@ietf.org; Fri, 25 Feb 2005 15:07:57 -0500 Received: from gypsy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j1PK7e2x075430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Feb 2005 20:07:40 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.0.14.0.20050225115120.098910e0@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 25 Feb 2005 12:06:50 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: [ldapext] draft-zeilenga-ldap-assert-05 notes In-Reply-To: References: <6.2.0.14.0.20050223215702.06a15670@mail.openldap.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 12:18 PM 2/24/2005, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 09:35 AM 2/23/2005, Hallvard B Furuseth wrote: >>>draft-zeilenga-ldap-assert-05.txt says: >>>> 4. Security Considerations >>>> >>>> As with any general assertion mechanism, the mechanism can be used to >>>> determine directory content. Hence, this mechanism SHOULD be subject >>>> to appropriate access controls. >>> >>>I suggest to add something like: >>> >>> ... preferably the same access controls as search filters. >> >> Is there a search reason behind this preference? > >It seemed to fit best the few access control models I know of. If a >baseobject search for "(&)" or "(objectClass=*)" returns the entry but a >search for some other filter does not, I think Modify with an assertion >of that filter should cause assertionFailed. But I must admit I haven't >thought through all the variants of this control and access controls >even in the models I do know. > >> I rather not state a preference as part of a security considerations >> unless there is a good security related reason for that preference. > >The security reason I'm aware of is that I got it very wrong the >first time I thought of implementing access controls for this control. Wrong? or just not the way you thought it should be for the particular access control you were using? Saying "SHOULD be subject to appropriate access controls" implies that the implementor should careful consider what is appropriate within the particular access model used in that implementation. I find it difficult to suggest what might be appropriate in general as that requires, I think, making some assumptions about the access control model. >>> The implementor might find the same access controls as for Compare >>> natural, but the server admin might e.g. not want substring matching to >>> be possible - and he could have written the Compare ACLs knowing that >>> Compare can't do substring matching. Or one might mistakenly use the >>> same ACLs as for the "basic" operation being performed, e.g. Modify. >> >> It seems to be your statements depend greatly on what the >> access control model is... I can certainly envision models >> where that would not be a mistake. > >Can you give an example? Hypothetical or not. I think it would be reasonable to allow a user authorized to perform a modify to make that modify conditional. In a model where "search" rights includes "read" rights, I don't see in necessary to requires "search" rights. >BTW, another point: The draft says > >> When the control is attached to an LDAP request, the processing of the >> request is conditional on the evaluation of the Filter as applied >> against the target of the operation. > >Except that the control should not prevent the return of a referral, I >presume. If the server does not hold the target, it should (as it would normally) return a referral (or noSuchObject) as appropriate. >-- >Hallvard > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Feb 25 19:50:02 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20498 for ; Fri, 25 Feb 2005 19:50:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4q71-0000P7-U6; Fri, 25 Feb 2005 19:47:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4q6z-0000P1-UE for ldapext@megatron.ietf.org; Fri, 25 Feb 2005 19:47:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20358 for ; Fri, 25 Feb 2005 19:47:10 -0500 (EST) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4q7C-0007cV-Rz for ldapext@ietf.org; Fri, 25 Feb 2005 19:47:28 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 25 Feb 2005 17:47:02 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta Date: Fri, 25 Feb 2005 17:46:34 -0700 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Subject: [ldapext] OIDs in LDAP Internet-Drafts X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit All, While a specification progresses through its life cycle as an Internet-Draft, Implementations of it may need to issue OIDs for schema elements, extension names, etc. Ideally, any time an implementation is updated to match a semantic change in a newer version of the specification, it will revise the OID it's using. This would have the effect of indicating support for the semantics defined in the particular revision implemented. I know some implementations use their own experimental OID arc for implementations of pre-RFC specifications. I don't know what their policy is in terms of updating OIDs as semantics of the specification change. It would be very useful if, instead of each implementation doing this, it could be done in the I-D itself. Ideally, one would procure a "proposed OID arc" from IANA. The I-D editor would then update OID assignements in the specification, and rev them anytime a semantic change would cause an interoperability problem. Alternately (more simply) the editor could update them all everytime the I-D was revised. To make it easy, they could even assign an arc below the IANA-assigned arc which adopts the I-D revision number. i.e. if the IANA assigned arc is 1.2.3.4, the OIDs in the I-D would be 1.2.3.4.0.x for the -00 revision, and 1.2.3.4.1.x for the -01 revision. When the I-D is progressed to an RFC, IANA could do its usual assignment / replacement. The two benefits I see are that multiple interoperable implementations may be produced while a specification is being progressed, and that the experimental/temporary OIDs being used will match a specific incarnation of the specification. What think ye? Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Feb 25 22:53:13 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00163 for ; Fri, 25 Feb 2005 22:53:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4sz4-0003U4-G5; Fri, 25 Feb 2005 22:51:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4sz2-0003S0-89 for ldapext@megatron.ietf.org; Fri, 25 Feb 2005 22:51:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00077 for ; Fri, 25 Feb 2005 22:51:10 -0500 (EST) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4szI-0001yr-D8 for ldapext@ietf.org; Fri, 25 Feb 2005 22:51:28 -0500 Received: from gypsy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j1Q3pAJM091957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Feb 2005 03:51:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.0.14.0.20050225192136.09eaf200@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 25 Feb 2005 19:50:19 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] OIDs in LDAP Internet-Drafts In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org I see a couple of flaws in your rationale for OID versioning in "works in progress". The main one is that early implementations do not adhere strictly to one particular revision of the "work in progress". That is, aside from the specification being a "work in progress", often so are early implementations. Consistency is hard in the early stages of development of an extension specification and its implementations. It seems far easier for a single implementor wanting to develop peers to use a locally assigned OID. This is what the OpenLDAP Project does, it seems to work fine. We have a special branch for this, known the "devil made me do it" branch. The assignment practice in this branch is that each OID identifies a "work in progress" (or portion thereof) as currently implemented. Again, no consistency guaranteed. It's a work in progress after all. For this and other reasons, we avoid advertising support for "works in progress", even in development codes. For those wanting to do some interop testing, those participating in the testing should easily be able to reach some adhoc agreement as what OID to use. Since we talking early implementation here, I presume that changing OIDs to test is no big deal. That all said, if you want to provide an OID, you may use Experimental OIDs (see Section 3.1 of BCP 64). These MUST be replaced prior to publication as an RFC. I see no reason why you could version assignments under the OID. BCP 64 certainly does not preclude that. I would not recommend updating OIDs on each revision. That just creates unnecessary change. Instead only update the OIDs when the new semantics are not backwards compatible with the old semantics. Personally, I think I'll stick to my current approach. Avoid OIDs in I-Ds. At 04:46 PM 2/25/2005, Jim Sermersheim wrote: >All, > >While a specification progresses through its life cycle as an >Internet-Draft, Implementations of it may need to issue OIDs for schema >elements, extension names, etc. > >Ideally, any time an implementation is updated to match a semantic >change in a newer version of the specification, it will revise the OID >it's using. This would have the effect of indicating support for the >semantics defined in the particular revision implemented. > >I know some implementations use their own experimental OID arc for >implementations of pre-RFC specifications. I don't know what their >policy is in terms of updating OIDs as semantics of the specification >change. > >It would be very useful if, instead of each implementation doing this, >it could be done in the I-D itself. Ideally, one would procure a >"proposed OID arc" from IANA. The I-D editor would then update OID >assignements in the specification, and rev them anytime a semantic >change would cause an interoperability problem. Alternately (more >simply) the editor could update them all everytime the I-D was revised. >To make it easy, they could even assign an arc below the IANA-assigned >arc which adopts the I-D revision number. i.e. if the IANA assigned arc >is 1.2.3.4, the OIDs in the I-D would be 1.2.3.4.0.x for the -00 >revision, and 1.2.3.4.1.x for the -01 revision. > >When the I-D is progressed to an RFC, IANA could do its usual >assignment / replacement. > >The two benefits I see are that multiple interoperable implementations >may be produced while a specification is being progressed, and that the >experimental/temporary OIDs being used will match a specific incarnation >of the specification. > >What think ye? > >Jim > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sat Feb 26 11:58:35 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16108 for ; Sat, 26 Feb 2005 11:58:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D55EG-0004oi-2s; Sat, 26 Feb 2005 11:55:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D55ED-0004od-VN for ldapext@megatron.ietf.org; Sat, 26 Feb 2005 11:55:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15963 for ; Sat, 26 Feb 2005 11:55:38 -0500 (EST) Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D55Ea-0007BS-B6 for ldapext@ietf.org; Sat, 26 Feb 2005 11:56:04 -0500 Received: from mail-mx6.uio.no ([129.240.10.47] ident=[U2FsdGVkX18Oq8BjDIHSrNW+i1eXOJmBsjQIPOEXHPk=]) by pat.uio.no with esmtp (Exim 4.43) id 1D55E8-0001PU-Py; Sat, 26 Feb 2005 17:55:36 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.43) id 1D55E4-0001Oo-Gv; Sat, 26 Feb 2005 17:55:32 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1D55E3-00016z-8p; Sat, 26 Feb 2005 17:55:31 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Sat, 26 Feb 2005 17:55:31 +0100 To: "Kurt D. Zeilenga" Subject: Re: [ldapext] draft-zeilenga-ldap-assert-05 notes In-Reply-To: <6.2.0.14.0.20050225115120.098910e0@mail.openldap.org> References: <6.2.0.14.0.20050223215702.06a15670@mail.openldap.org> <6.2.0.14.0.20050225115120.098910e0@mail.openldap.org> X-Mailer: VM 7.18 under Emacs 21.3.1 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-4.654, required 12, autolearn=disabled, AWL 0.35, UIO_MAIL_IS_INTERNAL -5.00) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Kurt D. Zeilenga writes: >At 12:18 PM 2/24/2005, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: >>>At 09:35 AM 2/23/2005, Hallvard B Furuseth wrote: >>>>draft-zeilenga-ldap-assert-05.txt says: >>>>> 4. Security Considerations >>>>> >>>>> As with any general assertion mechanism, the mechanism can be used to >>>>> determine directory content. Hence, this mechanism SHOULD be subject >>>>> to appropriate access controls. >>>> >>>>I suggest to add something like: >>>> >>>> ... preferably the same access controls as search filters. >> >> (...) >>> I rather not state a preference as part of a security considerations >>> unless there is a good security related reason for that preference. >> >>The security reason I'm aware of is that I got it very wrong the >>first time I thought of implementing access controls for this control. > > Wrong? or just not the way you thought it should be for the > particular access control you were using? Different from how I thought it should work is wrong enough when I'm the one who did it:-) Which doesn't mean anyone else would do the same, of course. > Saying "SHOULD be subject to appropriate access controls" implies > that the implementor should careful consider what is appropriate within > the particular access model used in that implementation. I find it > difficult to suggest what might be appropriate in general as that > requires, I think, making some assumptions about the access control > model. Me too, now that I've thought about it. "Same as for filters" was too broad for what I was trying to address; I should at least have said filters in baseobject searches, since one could have different access controls for baseobject searches and other searches. So I can well imagine there are other ways I haven't thought of. Still, I do think there are pitfalls and it would be useful to flesh out the issue somewhat. See below. >>>> The implementor might find the same access controls as for Compare >>>> natural, but the server admin might e.g. not want substring matching to >>>> be possible - and he could have written the Compare ACLs knowing that >>>> Compare can't do substring matching. Or one might mistakenly use the >>>> same ACLs as for the "basic" operation being performed, e.g. Modify. >>> >>> It seems to be your statements depend greatly on what the >>> access control model is... I can certainly envision models >>> where that would not be a mistake. >> >>Can you give an example? Hypothetical or not. > > I think it would be reasonable to allow a user authorized to > perform a modify to make that modify conditional. I hope not, if you mean conditional on any part of the entry. Then if I have Modify access to attribute in an entry but attribute is hidden from read/search/compare by access controls, I can subvert those access controls by e.g. trying remove a non-existent value from or modify it to contain the same value as before, conditional on a filter. noSuchAttribute or success reveal that the filter matches the "hidden" value of . assertionFailed reveals that it does not. Come to think of it, that can work even without Modify access. Getting insufficientAccessRights instead of assertionFailed can reveal that the assertion succeeded, unless the server implementor took care to check all access controls before checking the assertion. That may even be a correct interpretation of the draft's literal wording. Are access checks part of "processing" the operation, which is only done if the assertion succeeds? With some caveats, the same seems to me to apply if and are the same attribute. If access is set so that one can write but not test an attribute, there is presumably some reason for it. Allowing people to provide secret input to some questionnaire, maybe. But in that case one can in any case simulate an equality filter by attempting to add and remove again the value to be tested. > In a model where "search" rights includes "read" rights, I don't see > in necessary to requires "search" rights. Well, in that model, to require "same access controls as search filters" would require "read" rights. -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sat Feb 26 13:29:31 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21428 for ; Sat, 26 Feb 2005 13:29:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D56g3-00053K-C3; Sat, 26 Feb 2005 13:28:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D56g0-00052G-JV for ldapext@megatron.ietf.org; Sat, 26 Feb 2005 13:28:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21203 for ; Sat, 26 Feb 2005 13:28:25 -0500 (EST) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D56gN-0000Gy-UC for ldapext@ietf.org; Sat, 26 Feb 2005 13:28:52 -0500 Received: from gypsy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j1QISNOU013956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Feb 2005 18:28:23 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.0.14.0.20050226100641.09d60c50@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sat, 26 Feb 2005 10:27:30 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: [ldapext] draft-zeilenga-ldap-assert-05 notes In-Reply-To: References: <6.2.0.14.0.20050223215702.06a15670@mail.openldap.org> <6.2.0.14.0.20050225115120.098910e0@mail.openldap.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 08:55 AM 2/26/2005, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 12:18 PM 2/24/2005, Hallvard B Furuseth wrote: >>>Kurt D. Zeilenga writes: >>>>At 09:35 AM 2/23/2005, Hallvard B Furuseth wrote: >>>>>draft-zeilenga-ldap-assert-05.txt says: >>>>>> 4. Security Considerations >>>>>> >>>>>> As with any general assertion mechanism, the mechanism can be used to >>>>>> determine directory content. Hence, this mechanism SHOULD be subject >>>>>> to appropriate access controls. >>>>> >>>>>I suggest to add something like: >>>>> >>>>> ... preferably the same access controls as search filters. >>> >>> (...) >>>> I rather not state a preference as part of a security considerations >>>> unless there is a good security related reason for that preference. >>> >>>The security reason I'm aware of is that I got it very wrong the >>>first time I thought of implementing access controls for this control. >> >> Wrong? or just not the way you thought it should be for the >> particular access control you were using? > >Different from how I thought it should work is wrong enough when I'm the >one who did it:-) Which doesn't mean anyone else would do the same, of >course. > >> Saying "SHOULD be subject to appropriate access controls" implies >> that the implementor should careful consider what is appropriate within >> the particular access model used in that implementation. I find it >> difficult to suggest what might be appropriate in general as that >> requires, I think, making some assumptions about the access control >> model. > >Me too, now that I've thought about it. "Same as for filters" was too >broad for what I was trying to address; I should at least have said >filters in baseobject searches, since one could have different access >controls for baseobject searches and other searches. So I can well >imagine there are other ways I haven't thought of. I note that the server might not even implement the Search operation, so saying same as "search" or same as "search filters" could have some odd implications. >Still, I do think there are pitfalls and it would be useful to flesh out >the issue somewhat. See below. Please feel free to offer specific text for consideration. >>>>> The implementor might find the same access controls as for Compare >>>>> natural, but the server admin might e.g. not want substring matching to >>>>> be possible - and he could have written the Compare ACLs knowing that >>>>> Compare can't do substring matching. Or one might mistakenly use the >>>>> same ACLs as for the "basic" operation being performed, e.g. Modify. >>>> >>>> It seems to be your statements depend greatly on what the >>>> access control model is... I can certainly envision models >>>> where that would not be a mistake. >>> >>>Can you give an example? Hypothetical or not. >> >> I think it would be reasonable to allow a user authorized to >> perform a modify to make that modify conditional. > >I hope not, if you mean conditional on any part of the entry. Then if I >have Modify access to attribute in an entry but attribute is >hidden from read/search/compare by access controls, I can subvert those >access controls by e.g. trying remove a non-existent value from or >modify it to contain the same value as before, conditional on a >filter. noSuchAttribute or success reveal that the filter matches the >"hidden" value of . assertionFailed reveals that it does not. Ah, but the client could have used its modify rights to do: changetype: modify delete: foo foo: bar - add: foo foo: bar - To see if that hidden exists. Or: control: no-op changetype: modify add: foo foo: bar - My point here is that "right to modify" often implies a right to make assertions, at least certain kinds of assertions, as these assertions are necessary to perform the operation. >Come to think of it, that can work even without Modify access. Getting >insufficientAccessRights instead of assertionFailed can reveal that the >assertion succeeded, unless the server implementor took care to check >all access controls before checking the assertion. The access control model may have "don't disclose on error" provisions. >That may even be a >correct interpretation of the draft's literal wording. Are access >checks part of "processing" the operation, which is only done if the >assertion succeeds? I generally presume there will be access checks in different parts of the overall processing of the request, including in finding the target object, performing the assertion, and performing the "normal" processing. >With some caveats, the same seems to me to apply if and are >the same attribute. If access is set so that one can write but not test >an attribute, there is presumably some reason for it. Allowing people >to provide secret input to some questionnaire, maybe. But in that case >one can in any case simulate an equality filter by attempting to add and >remove again the value to be tested. Correct. Or use no-op control as I demonstrated above. >> In a model where "search" rights includes "read" rights, I don't see >> in necessary to requires "search" rights. > >Well, in that model, to require "same access controls as search filters" >would require "read" rights. > >-- >Hallvard > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sun Feb 27 12:20:41 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14471 for ; Sun, 27 Feb 2005 12:20:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5S3n-0002KQ-QU; Sun, 27 Feb 2005 12:18:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5S3l-0002I9-Tu for ldapext@megatron.ietf.org; Sun, 27 Feb 2005 12:18:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14302 for ; Sun, 27 Feb 2005 12:18:23 -0500 (EST) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5S4J-0001Yo-8V for ldapext@ietf.org; Sun, 27 Feb 2005 12:19:01 -0500 Received: from gypsy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j1RHIKio038888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Feb 2005 17:18:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.0.14.0.20050227084818.02ad6860@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sun, 27 Feb 2005 09:17:26 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: [ldapext] comment control, dummy request, no-response request In-Reply-To: References: <6.2.0.14.0.20050224080350.06bc6958@mail.openldap.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 11:31 AM 2/24/2005, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 02:30 PM 2/22/2005, Hallvard B Furuseth wrote: >>>"Comment" control: >>> >>> It can be useful to attach a comment to an LDAP request. >> >> For what purpose? Tracing or other? > >That's the use which prompted this suggestion, yes. >> (...) >> (The point of me asking the above question is to have you >> narrow the purpose of the control to one thing.) > >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 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. >> (...) 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. > >>> 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 LDAPString would be natural, but sometimes one may >>> want to attach data 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. > >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. 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). >>> So a plain OCTET STRING might >>> be better, to be interpreted at the server admin's discretion. >> >> I rather say that the information provided is to only be used >> for trace purposes and is not to be otherwise interpreted or >> used. > >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". 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. >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. Basically, if the trace information is logged to a consumable resource, unrestricted logging can easily lead to denial of service. >>> "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? >> >> I am not sure this makes sense, which I will illustrate below. >> >>> 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). >> >> 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. > >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. > >> 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. > >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. > >>> 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. >> >> 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.) > > >>> "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. >> >> 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. > >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. >> >> I think it generally unwise to attach semantics onto >> operations created through use of controls which are not >> 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 > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sun Feb 27 14:15:21 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23304 for ; Sun, 27 Feb 2005 14:15:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Tqs-00053K-TM; Sun, 27 Feb 2005 14:13:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Tqq-000539-VE for ldapext@megatron.ietf.org; Sun, 27 Feb 2005 14:13:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23176 for ; Sun, 27 Feb 2005 14:13:11 -0500 (EST) Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5TrR-0003hZ-Ft for ldapext@ietf.org; Sun, 27 Feb 2005 14:13:49 -0500 Received: from mail-mx4.uio.no ([129.240.10.45] ident=7411) by pat.uio.no with esmtp (Exim 4.43) id 1D5Tqk-0005CX-Ta; Sun, 27 Feb 2005 20:13:07 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.43) id 1D5Tqf-0005Ui-N4; Sun, 27 Feb 2005 20:13:01 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1D5Tqe-0003fP-OW; Sun, 27 Feb 2005 20:13:00 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Sun, 27 Feb 2005 20:13:00 +0100 To: "Kurt D. Zeilenga" Subject: Re: [ldapext] Trace control (was: comment control, dummy request, no-response request) In-Reply-To: <6.2.0.14.0.20050227084818.02ad6860@mail.openldap.org> References: <6.2.0.14.0.20050224080350.06bc6958@mail.openldap.org> <6.2.0.14.0.20050227084818.02ad6860@mail.openldap.org> X-Mailer: VM 7.18 under Emacs 21.3.1 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-4.758, required 12, autolearn=disabled, AWL 0.24, UIO_MAIL_IS_INTERNAL -5.00) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Kurt D. Zeilenga writes: >At 11:31 AM 2/24/2005, Hallvard B Furuseth wrote: >> 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 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). OK. Makes sense. > I note that we likely want to allow multiple instances of the > control to be attached to a message. "The order of multiple trace controls in a request SHOULD be preserved." >> 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". > > 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. Nice. s/semantical/semantic/, I think. -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sun Feb 27 16:15:36 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04840 for ; Sun, 27 Feb 2005 16:15:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5VkH-0002Yr-Nj; Sun, 27 Feb 2005 16:14:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5VkG-0002Yj-0h for ldapext@megatron.ietf.org; Sun, 27 Feb 2005 16:14:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04793 for ; Sun, 27 Feb 2005 16:14:30 -0500 (EST) Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5Vkq-00061t-Tm for ldapext@ietf.org; Sun, 27 Feb 2005 16:15:10 -0500 Received: from mail-mx4.uio.no ([129.240.10.45] ident=7411) by pat.uio.no with esmtp (Exim 4.43) id 1D5VkA-0004MN-Qq; Sun, 27 Feb 2005 22:14:26 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.43) id 1D5Vk6-0005z7-Qf; Sun, 27 Feb 2005 22:14:22 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1D5Vk5-0007rm-TH; Sun, 27 Feb 2005 22:14:21 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Sun, 27 Feb 2005 22:14:21 +0100 To: "Kurt D. Zeilenga" Subject: Re: [ldapext] draft-zeilenga-ldap-assert-05 notes In-Reply-To: <6.2.0.14.0.20050226100641.09d60c50@mail.openldap.org> References: <6.2.0.14.0.20050223215702.06a15670@mail.openldap.org> <6.2.0.14.0.20050225115120.098910e0@mail.openldap.org> <6.2.0.14.0.20050226100641.09d60c50@mail.openldap.org> X-Mailer: VM 7.18 under Emacs 21.3.1 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-4.761, required 12, autolearn=disabled, AWL 0.24, UIO_MAIL_IS_INTERNAL -5.00) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Kurt D. Zeilenga writes: >At 08:55 AM 2/26/2005, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: >>> (...) >>> I think it would be reasonable to allow a user authorized to >>> perform a modify to make that modify conditional. >> >> I hope not, if you mean conditional on any part of the entry. Then if I >> have Modify access to attribute in an entry but attribute is >> hidden from read/search/compare by access controls, I can subvert those >> access controls by e.g. trying remove a non-existent value from or >> modify it to contain the same value as before, conditional on a >> filter. noSuchAttribute or success reveal that the filter matches the >> "hidden" value of . assertionFailed reveals that it does not. > > Ah, but the client could have used its modify rights to do: > changetype: modify > delete: foo > foo: bar > - > add: foo > foo: bar > - > > To see if that hidden exists. Or: > control: no-op > changetype: modify > add: foo > foo: bar > - Huh? None of these refer to attribute bar, only to an attribute value of foo. > My point here is that "right to modify" often implies a right > to make assertions, at least certain kinds of assertions, as > these assertions are necessary to perform the operation. Yes. Still, only equality assertions, which fits Compare access more than general search (filter) access. >> Come to think of it, that can work even without Modify access. Getting >> insufficientAccessRights instead of assertionFailed can reveal that the >> assertion succeeded, unless the server implementor took care to check >> all access controls before checking the assertion. > > The access control model may have "don't disclose on error" > provisions. True enough. > (...) -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Feb 28 09:45:19 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25813 for ; Mon, 28 Feb 2005 09:45:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5m7i-0004Vz-IG; Mon, 28 Feb 2005 09:43:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5m7g-0004Vu-Tp for ldapext@megatron.ietf.org; Mon, 28 Feb 2005 09:43:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25675 for ; Mon, 28 Feb 2005 09:43:47 -0500 (EST) Received: from e3.ny.us.ibm.com ([32.97.182.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5m8Q-000068-33 for ldapext@ietf.org; Mon, 28 Feb 2005 09:44:36 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j1SEhV5w022013 for ; Mon, 28 Feb 2005 09:43:31 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1SEhVmU060410 for ; Mon, 28 Feb 2005 09:43:31 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1SEhUX6019978 for ; Mon, 28 Feb 2005 09:43:31 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.229.77]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1SEhUBo019934 for ; Mon, 28 Feb 2005 09:43:30 -0500 In-Reply-To: Subject: Re: [ldapext] draft-zeilenga-ldap-assert-05 notes To: ldapext@ietf.org X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: John McMeeking Date: Mon, 28 Feb 2005 08:43:29 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 02/28/2005 08:43:30 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org I know how I would expect some servers to handle this control, but I don't think that guidance would necessarily apply to other access control models. I can offer the following text which might address Hallvard's concerns as I understand them. Access control policy SHOULD be applied to processing of the assertion control value. Use of the assertion control might enable a client to obtain information about an entry it does not have authority to. A result code associated with authority to evaluate the control assertion ( e.g. insufficientAccess or assertionFailed) might also reveal information that violates access control policy; in such cases, the result code should be dictated by the access control policy. John McMeeking Hallvard B Furuseth wrote on 02/27/2005 03:14:21 PM: > Kurt D. Zeilenga writes: > >At 08:55 AM 2/26/2005, Hallvard B Furuseth wrote: > >>Kurt D. Zeilenga writes: > >>> (...) > >>> I think it would be reasonable to allow a user authorized to > >>> perform a modify to make that modify conditional. > >> > >> I hope not, if you mean conditional on any part of the entry. Then if I > >> have Modify access to attribute in an entry but attribute is > >> hidden from read/search/compare by access controls, I can subvert those > >> access controls by e.g. trying remove a non-existent value from or > >> modify it to contain the same value as before, conditional on a > >> filter. noSuchAttribute or success reveal that the filter matches the > >> "hidden" value of . assertionFailed reveals that it does not. > > > > Ah, but the client could have used its modify rights to do: > > changetype: modify > > delete: foo > > foo: bar > > - > > add: foo > > foo: bar > > - > > > > To see if that hidden exists. Or: > > control: no-op > > changetype: modify > > add: foo > > foo: bar > > - > > Huh? None of these refer to attribute bar, only to an attribute value > of foo. > > > My point here is that "right to modify" often implies a right > > to make assertions, at least certain kinds of assertions, as > > these assertions are necessary to perform the operation. > > Yes. Still, only equality assertions, which fits Compare access > more than general search (filter) access. > > >> Come to think of it, that can work even without Modify access. Getting > >> insufficientAccessRights instead of assertionFailed can reveal that the > >> assertion succeeded, unless the server implementor took care to check > >> all access controls before checking the assertion. > > > > The access control model may have "don't disclose on error" > > provisions. > > True enough. > > > (...) > > -- > Hallvard > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Feb 28 13:35:57 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20183 for ; Mon, 28 Feb 2005 13:35:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5phi-0004x0-DM; Mon, 28 Feb 2005 13:33:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5phh-0004wu-CZ for ldapext@megatron.ietf.org; Mon, 28 Feb 2005 13:33:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20003 for ; Mon, 28 Feb 2005 13:33:09 -0500 (EST) Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5piS-0005X9-PV for ldapext@ietf.org; Mon, 28 Feb 2005 13:34:02 -0500 Received: from ns1.sys-net.it (localhost [127.0.0.1]) by mail.sys-net.it (8.13.3/8.13.3) with ESMTP id j1SIX8x0029440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Feb 2005 19:33:08 +0100 DomainKey-Signature: a=rsa-sha1; s=mail; d=sys-net.it; c=simple; q=dns; b=gABy6bxBCaBKJrFHFAiKr3WQU0G96n4Il5Yo0Hy5cxZN6I8LFQTWAgV57oKDOnT5E 9fEQ8dHQTzLcGXU7K8k8Q== Received: (from apache@localhost) by ns1.sys-net.it (8.13.3/8.12.5/Submit) id j1SIX5fj029422; Mon, 28 Feb 2005 19:33:05 +0100 Received: from 131.175.154.56 (SquirrelMail authenticated user ando); by webmail.sys-net.it with HTTP; Mon, 28 Feb 2005 19:33:05 +0100 (CET) Message-ID: <45126.131.175.154.56.1109615585.squirrel@131.175.154.56> In-Reply-To: References: Date: Mon, 28 Feb 2005 19:33:05 +0100 (CET) Subject: Re: [ldapext] draft-zeilenga-ldap-assert-05 notes From: "Pierangelo Masarati" To: "John McMeeking" User-Agent: SquirrelMail/1.4.3a-1 X-Mailer: SquirrelMail/1.4.3a-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-SysNet-MailScanner-Information: postmaster@sys-net.it X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 8bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ando@sys-net.it List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 8bit > > I know how I would expect some servers to handle this control, but I don't > think that guidance would necessarily apply to other access control > models. > I can offer the following text which might address Hallvard's concerns as > I > understand them. > > Access control policy SHOULD be applied to processing of the assertion > control value. Use of the assertion control might enable a client to > obtain information about an entry it does not have authority to. A result > code associated with authority to evaluate the control assertion ( e.g. > insufficientAccess or assertionFailed) might also reveal information that > violates access control policy; in such cases, the result code should be > dictated by the access control policy. There's some development ongoing in OpenLDAP's slapd on this; it's not in a very representative piece of software though (back-sql), but I'm planning to extend it to other backends. All operations support the draft-zeilenga-ldap-assert control, and, whenever appropriate, if an error is to be returned, including assertionFailed, the associated object is checked for "disclose" access to the "entry" pseudo-attribute. If no disclose access is granted, noSuchObject is returned instead of the real error. Regular access checks related to filter testing apply. p. -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext