
From michael@stroeder.com  Fri Apr 20 09:48:03 2012
Return-Path: <michael@stroeder.com>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5EF21F865B for <ldapext@ietfa.amsl.com>; Fri, 20 Apr 2012 09:48:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.369
X-Spam-Level: 
X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDIBolJPjqp5 for <ldapext@ietfa.amsl.com>; Fri, 20 Apr 2012 09:48:03 -0700 (PDT)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id A488F21F8659 for <ldapext@ietf.org>; Fri, 20 Apr 2012 09:48:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id DA23860126 for <ldapext@ietf.org>; Fri, 20 Apr 2012 18:47:56 +0200 (CEST)
X-Virus-Scanned: amavisd-new at stroeder.com
Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjdJW3PA7v9d for <ldapext@ietf.org>; Fri, 20 Apr 2012 18:47:53 +0200 (CEST)
Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id 1BEDC60069 for <ldapext@ietf.org>; Fri, 20 Apr 2012 16:47:53 +0000 (UTC)
Message-ID: <4F919338.5070903@stroeder.com>
Date: Fri, 20 Apr 2012 18:47:52 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Firefox/11.0 SeaMonkey/2.8
MIME-Version: 1.0
To: ldapext@ietf.org
X-Enigmail-Version: 1.4
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000701070807010705070400"
Subject: [ldapext] Read Entry control not applicable to Bind Operations
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Apr 2012 16:48:03 -0000

This is a cryptographically signed message in MIME format.

--------------ms000701070807010705070400
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

HI!

I wonder why RFC 4527 limits the use of the Read Entry control to update
operations (Add, Delete, Modify, ModifyDN).

E.g. the pre-read control could be also useful to read the last login tim=
e and
number of failed authc attempts and display it to the user *after* a
successful bind. This is a bit tricky since the appropriate ACLs would ha=
ve to
be applied when reading the attribute values although the user is not alr=
eady
bound. But this could be internally handled by the server similar to prox=
y authz.

Ciao, Michael.


--------------ms000701070807010705070400
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC
BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx
MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj
MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd
NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV
hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/
0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ
NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH
AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy
IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl
cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB
BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov
L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq
hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj
/E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd
dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH
SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ
AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63
TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT
QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ
R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv
n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy
D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB
gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx
IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1
cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQyMDE2NDc1MlowIwYJKoZIhvcNAQkEMRYE
FAa1Q9QPPZXmkny9JnXVKQDgDfQ2MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG
CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq
hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n
IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG
CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6
Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh
MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE
ggEAB5BN9HJSpp1/m9y4tbK8v3B4zZ1KdF+lDldj8wL4ACiBAS0oJ6Cee/N5vKDBRXJUmJgJ
C0HzUDoPhflmqIFAO/hWHFA0OkMMorCX/keyGt52ExzUoXB4c6ylcr4p9KCw2kJzlqpO+yu/
75ncOkLg2dsDJ8xe4ySNW4NHesy0UA1MwcVcEM+JZXEM7q05yf0OruGcWUlAXgfDIZBNsRPl
GmZcAT6Mol77waaxnwYlrG4opv+Dr6iA3TSa9W9jSM9XvfukZIvsGpiIj2epHP08HjoLSprq
du76YJEDY6YdJ16N74fn8j2KYSO3Av9cb4q08rG0jyH8WXX7iCjD54OCQQAAAAAAAA==
--------------ms000701070807010705070400--

From kurt.zeilenga@isode.com  Fri Apr 20 18:10:41 2012
Return-Path: <kurt.zeilenga@isode.com>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6288421F8441 for <ldapext@ietfa.amsl.com>; Fri, 20 Apr 2012 18:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level: 
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+7nwWDDmu9o for <ldapext@ietfa.amsl.com>; Fri, 20 Apr 2012 18:10:35 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 1279D21E8041 for <ldapext@ietf.org>; Fri, 20 Apr 2012 18:10:35 -0700 (PDT)
Received: from gypsy.boolean.net (66-214-104-34.dhcp.slto.ca.charter.com [66.214.104.34])  by rufus.isode.com (smtp internal) via TCP with ESMTPA  id <T5IJCAAg2xmg@rufus.isode.com>; Sat, 21 Apr 2012 02:10:33 +0100
X-RBL-Found: 34.104.214.66.zen.spamhaus.org. (127.0.0.11)
From: Kurt Zeilenga <kurt.zeilenga@isode.com>
In-Reply-To: <4F919338.5070903@stroeder.com>
Date: Fri, 20 Apr 2012 18:10:29 -0700
Message-Id: <0C3F610D-C6EC-4B5E-AAB8-F4B4C304CD97@isode.com>
References: <4F919338.5070903@stroeder.com>
To: =?iso-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
X-Mailer: Apple Mail (2.1257)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: ldapext@ietf.org
Subject: Re: [ldapext] Read Entry control not applicable to Bind Operations
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Apr 2012 01:10:41 -0000

On Apr 20, 2012, at 9:47 AM, Michael Str=F6der wrote:

> HI!
>=20
> I wonder why RFC 4527 limits the use of the Read Entry control to =
update
> operations (Add, Delete, Modify, ModifyDN).

Because to solve the problem I had at the time, I only needed pre- and =
post-read entry on update capabilities.

> E.g. the pre-read control could be also useful to read the last login =
time and
> number of failed authc attempts and display it to the user *after* a
> successful bind.

There's lots of issues here which make this not so simple.

* There is a bad assumption that there is a one and only entry =
associated with the user.
* There is a bad assumption that the information desired is held in that =
entry.
* The request and response controls are not protected by the SASL layers =
established, if any, during the Bind.
* Proper semantics in multi-step SASL bind gets messy.

Lastly, it kind of overlaps with the purposes of the draft password =
policy control... which arguely should be capable of return a wide range =
of authentication and service authorization information to the client.

So, even if I was now writing the read-entry spec, I would have strongly =
opposed including non-update coverage, especially bind coverage, in the =
spec.

If someone really wants this, they can write a separate spec, reuse all =
the syntaxes (just define a "feature" for the extension to this control =
extension).

-- Kurt=
