From michael@stroeder.com Wed Mar 13 15:39:35 2013 Return-Path: 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 76A7B21F84B7 for ; Wed, 13 Mar 2013 15:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 xE7qyR5S5NbT for ; Wed, 13 Mar 2013 15:39:35 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB1921F84B2 for ; Wed, 13 Mar 2013 15:39:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 2CF7D60232; Wed, 13 Mar 2013 23:39:31 +0100 (CET) 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 MbaUIjn8W6un; Wed, 13 Mar 2013 23:39:27 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id 0DE026018C; Wed, 13 Mar 2013 22:39:25 +0000 (UTC) Message-ID: <51410020.4020800@stroeder.com> Date: Wed, 13 Mar 2013 23:39:28 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16 MIME-Version: 1.0 To: Kurt Zeilenga References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> In-Reply-To: <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030104070306030401030107" Cc: "ldap@umich.edu" , ldapext Subject: [ldapext] draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ldapext List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 22:39:35 -0000 This is a cryptographically signed message in MIME format. --------------ms030104070306030401030107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Kurt Zeilenga wrote: > I see this document is marked as being intended to be published as > Informational, but it reads more like it's trying to be a standard. I tried to add some wording to avoid that misunderstanding in the next revision of this draft: http://www.ietf.org/internet-drafts/draft-stroeder-hashed-userpassword-va= lues-01.txt > I note that at Isode we have a 2307 style hash scheme that we use to ho= ld > SCRAM compatible hash. Aside from being SCRAM compatible, it's designe= d to > hinder dictionary and brute force attacks by significant increasing the= > cost of producing the stored value. It would be good to include this = as > part of the 'current practice'. I'd like to add that if you provide more detailed information about it. Ciao, Michael. --------------ms030104070306030401030107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzEzMjIzOTI4WjAjBgkq hkiG9w0BCQQxFgQUDRYSMLdGIfd54BGH82nmXVV22rkwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAEodJm6uyah8a+N/q2wPpcxHSv1V/cXhLhtXaVaMyCm+E9uXnzD4vM4HeW8WOmrS55kpQ VAyjeP2UB+dud/YEPj49fh/F8XfCKywmAUjmeqt4zeyunEVm4+22cJiBy2OO37lGPRxo9zso 7uEosJ5I9ag7KSpvKSHmzpi6btczOhjJgCgMgDdTVpvWoLuCbhfVOC/TmSbSjjt92jX20Uaf ZdJJUcrgIzp58FBkLkZOt/Ozu2pvsVWbT20cnn7Gxl0yinncSFPvpjsf66jxuFfJRBUoI//9 WOmSdyeZdhNFA1x8S8c3zv8VqmGhe5zGubGU0w8IvslADmTOqJ2iXivaMAAAAAAAAA== --------------ms030104070306030401030107-- From andrew.findlay@skills-1st.co.uk Wed Mar 13 17:19:06 2013 Return-Path: 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 6289421F8D19 for ; Wed, 13 Mar 2013 17:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 HVvpwqEaUlIp for ; Wed, 13 Mar 2013 17:19:05 -0700 (PDT) Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) by ietfa.amsl.com (Postfix) with ESMTP id 793B721F8D11 for ; Wed, 13 Mar 2013 17:19:05 -0700 (PDT) Received: from 2.b.0.9.d.6.e.f.f.f.a.6.1.2.2.0.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1:221:6aff:fe6d:90b2] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UFvss-0002tc-7z; Thu, 14 Mar 2013 00:19:02 +0000 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.80.1) (envelope-from ) id 1UFvsr-0004Py-Mx; Thu, 14 Mar 2013 00:19:01 +0000 Date: Thu, 14 Mar 2013 00:19:01 +0000 From: Andrew Findlay To: ldapext Message-ID: <20130314001901.GN18706@slab.skills-1st.co.uk> References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51410020.4020800@stroeder.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Cc: "ldap@umich.edu" , Kurt Zeilenga Subject: Re: [ldapext] draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 00:19:06 -0000 On Wed, Mar 13, 2013 at 11:39:28PM +0100, Michael Ströder wrote: > > I see this document is marked as being intended to be published as > > Informational, but it reads more like it's trying to be a standard. > > I tried to add some wording to avoid that misunderstanding in the next > revision of this draft: > > http://www.ietf.org/internet-drafts/draft-stroeder-hashed-userpassword-values-01.txt Still -01 ? You are explicitly excluding details of '{crypt}'. I think this is a mistake, especially in an informational document. {crypt} is extremely useful in transition scenarios, so people need to know about it. What platform-specific variants do you know of? The really important one is the old Unix-crypt 13-char salted hash. Could you perhaps say something like: {crypt} introduces a password-hash string that is generated and checked by the crypt(3) library. This could be the traditional 13-character 'Unix crypt' or some other variant such as the stronger '$1$' and $6$' schemes used by recent versions of Linux. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- From michael@stroeder.com Wed Mar 13 18:23:51 2013 Return-Path: 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 4FC7E11E80DC for ; Wed, 13 Mar 2013 18:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 PFnuritltEkx for ; Wed, 13 Mar 2013 18:23:50 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id E2F2411E80D5 for ; Wed, 13 Mar 2013 18:23:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 614C96025F; Thu, 14 Mar 2013 02:23:43 +0100 (CET) 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 ScU9eNBsapoL; Thu, 14 Mar 2013 02:23:37 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id 7DDCC60251; Thu, 14 Mar 2013 01:23:36 +0000 (UTC) Message-ID: <5141269B.1030205@stroeder.com> Date: Thu, 14 Mar 2013 02:23:39 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16 MIME-Version: 1.0 To: Andrew Findlay , ldapext References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> <20130314001901.GN18706@slab.skills-1st.co.uk> In-Reply-To: <20130314001901.GN18706@slab.skills-1st.co.uk> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030303080305010000040703" Cc: "ldap@umich.edu" Subject: Re: [ldapext] draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 01:23:51 -0000 This is a cryptographically signed message in MIME format. --------------ms030303080305010000040703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andrew Findlay wrote: > On Wed, Mar 13, 2013 at 11:39:28PM +0100, Michael Str=F6der wrote: >=20 >>> I see this document is marked as being intended to be published as >>> Informational, but it reads more like it's trying to be a standard. >> >> I tried to add some wording to avoid that misunderstanding in the next= >> revision of this draft: >> >> http://www.ietf.org/internet-drafts/draft-stroeder-hashed-userpassword= -values-01.txt >=20 > Still -01 ? Not "still" -01. Now -01. > You are explicitly excluding details of '{crypt}'. I think this is a > mistake, especially in an informational document. {crypt} is > extremely useful in transition scenarios, so people need to know about > it. Hmm...I've expected somebody to ask for it. :-/ It makes the spec part more complex. > What platform-specific variants do you know of? Well, looking at crypt(3) man page it seems to me that there are many var= iants of the library on various Unix platforms. This is what I meant with "platform-specific". > The really important one is the old Unix-crypt 13-char salted hash. >=20 > Could you perhaps say something like: >=20 > {crypt} introduces a password-hash string that is generated and > checked by the crypt(3) library. This could be the traditional > 13-character 'Unix crypt' or some other variant such as the stronger > '$1$' and $6$' schemes used by recent versions of Linux. I've added some text hopefully getting {CRYPT} stuff complete. Yuck! Ciao, Michael. --------------ms030303080305010000040703 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE0MDEyMzM5WjAjBgkq hkiG9w0BCQQxFgQUglHJijEcUMBo7SoXMyCk2JAKwEcwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAfSFXhfe6+ngDQc/dbSK7BzNhV3C0xo4ECR44nuXYctFgg1qrc5wXKXou3HxLDcv3Z+SS 7BJ+L5teO8x2PPgfSZo/I5ygoQQYZLtC579zxEjTt/apTzw88KV0v0lEOO4eVkkkU6UFKR9z Zj27iWv8QvHBv38ZnqlHh04KfD1hZr91kwsMws82ynenNMRq5//ezgOHT6SHF4U7costxBar 9lq7qwDjsNbS0rtgz2OjULmQ0Ps4+VrqZhEMwme2X/TOVX0rTd80Iory8w/Zsvz6RzzmZHj6 vO1xtihDXVHUqBH5Vi1cBZm00ZVCFDS2IuuKKEqdyrxdvV2b4OFOCHWEhAAAAAAAAA== --------------ms030303080305010000040703-- From ludovic.poitou@gmail.com Thu Mar 14 03:19:26 2013 Return-Path: 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 593BA21F8F5D for ; Thu, 14 Mar 2013 03:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 r+PALNhHj-Du for ; Thu, 14 Mar 2013 03:19:22 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 1E45321F8F56 for ; Thu, 14 Mar 2013 03:19:21 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id e12so1491528wge.34 for ; Thu, 14 Mar 2013 03:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=Swg+Z+d2TsVUaZY06Zqj9tHp65PvatplHm5Er54AxXE=; b=YZxm5hq1jE3e5lwuAJnRsTepejxxkaUKVQ2vUJxTCSeAmeVHCD7AhCweEYWUb1sfWd s72X4TrLRRKqCFg7MC4edyUw9UeDfq9us41g2OW2lk0nBeKw+Zak01CEc4yCkWxztUWL lYdwRkLTaUd5OM2fWtNdnNs45An3vKXaFwOakgTHyMczwdwP4LuXvCnpAXjRtZaikQlM fI7bWcxxUJUPCOxAaHcIfyJpUFgd/pyBZWTBtgGuz+RcHUCyi0lHklG1Lgi7cgV7sKOV kVbk7Pqcyqwr+HFpX/ds5nJWnXBMKQKC29vIZqWpXSJK7/Y1Yc+0+9fj3Pj3bMoPk3IM k/Yw== X-Received: by 10.194.170.165 with SMTP id an5mr2779786wjc.41.1363256361202; Thu, 14 Mar 2013 03:19:21 -0700 (PDT) Received: from [172.16.203.238] (LLagny-156-34-26-241.w80-14.abo.wanadoo.fr. [80.14.205.241]) by mx.google.com with ESMTPS id fv2sm2981669wib.6.2013.03.14.03.19.19 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 14 Mar 2013 03:19:20 -0700 (PDT) Date: Thu, 14 Mar 2013 11:19:20 +0100 From: Ludovic Poitou To: =?utf-8?Q?Michael_Str=C3=B6der?= Message-ID: <1B373B048AD84206A7E8AAB9EB4D69AD@gmail.com> In-Reply-To: <5141269B.1030205@stroeder.com> References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> <20130314001901.GN18706@slab.skills-1st.co.uk> <5141269B.1030205@stroeder.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5141a428_4cdced4c_19a" Cc: ldapext , Andrew Findlay , "=?utf-8?Q?ldap=40umich.edu?=" Subject: Re: [ldapext] draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 10:19:26 -0000 --5141a428_4cdced4c_19a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Michael, I'm glad that you've added text to support =7BCRYPT=7D. But I'm not sure = it is necessary to make the description complete (i.e. refer to all under= lying platform specific algorithm). I think it might be enough to describe the general format of passwords ge= nerated by the crypt(3) library, mentions the default unix crypt and one = or two other algorithm, but also warn that crypt being extensible and pla= tform specific, it's use might result in interoperability issues. I would suggest that you add to the list of schemes, PBKD=462 and BCrypt = that are 2 mechanisms that are providing much stronger security than the = SHA 1 or 2. I'be happy to provide a description of PBKD=462 if you want, as we've imp= lemented support for it in OpenDJ. Regards, Ludo -- =20 Ludovic Poitou http://ludopoitou.wordpress.com On Thursday, March 14, 2013 at 2:23 , Michael Str=C3=B6der wrote: > Andrew =46indlay wrote: > > On Wed, Mar 13, 2013 at 11:39:28PM +0100, Michael Str=C3=B6der wrote:= > > =20 > > > > I see this document is marked as being intended to be published a= s > > > > Informational, but it reads more like it's trying to be a standar= d. > > > > =20 > > > =20 > > > =20 > > > I tried to add some wording to avoid that misunderstanding in the n= ext > > > revision of this draft: > > > =20 > > > http://www.ietf.org/internet-drafts/draft-stroeder-hashed-userpassw= ord-values-01.txt > > =20 > > Still -01 =3F > =20 > Not =22still=22 -01. Now -01. > =20 > > You are explicitly excluding details of '=7Bcrypt=7D'. I think this i= s a > > mistake, especially in an informational document. =7Bcrypt=7D is > > extremely useful in transition scenarios, so people need to know abou= t > > it. > > =20 > =20 > =20 > Hmm...I've expected somebody to ask for it. :-/ > It makes the spec part more complex. > =20 > > What platform-specific variants do you know of=3F > =20 > Well, looking at crypt(3) man page it seems to me that there are many v= ariants > of the library on various Unix platforms. This is what I meant with > =22platform-specific=22. > =20 > > The really important one is the old Unix-crypt 13-char salted hash. > > =20 > > Could you perhaps say something like: > > =20 > > =7Bcrypt=7D introduces a password-hash string that is generated and > > checked by the crypt(3) library. This could be the traditional > > 13-character 'Unix crypt' or some other variant such as the stronger > > '=241=24' and =246=24' schemes used by recent versions of Linux. > > =20 > =20 > =20 > I've added some text hopefully getting =7BCRYPT=7D stuff complete. Yuck= =21 > =20 > Ciao, Michael. > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Ldapext mailing list > Ldapext=40ietf.org (mailto:Ldapext=40ietf.org) > https://www.ietf.org/mailman/listinfo/ldapext > =20 > =20 > =20 > =20 > Attachments: =20 > - smime.p7s > =20 > =20 --5141a428_4cdced4c_19a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Michael,

I'm glad that you've added text to support =7BC= RYPT=7D. But I'm not sure it is necessary to make the description complet= e (i.e. refer to all underlying platform specific algorithm).
I= think it might be enough to describe the general format of passwords gen= erated by the crypt(3) library, mentions the default unix crypt and one o= r two other algorithm, but also warn that crypt being extensible and plat= form specific, it's use might result in interoperability issues.

I would suggest that you add to the list of schemes, PBK= D=462 and BCrypt that are 2 mechanisms that are providing much stronger s= ecurity than the SHA 1 or 2.
I'be happy to provide a descriptio= n of PBKD=462 if you want, as we've implemented support for it in OpenDJ.=

Regards,

Ludo
-- 
Ludovic Poitou

=20

On Thursday, March 14,= 2013 at 2:23 , Michael Str=C3=B6der wrote:

Andrew =46indlay wrote:
On Wed, Mar 13, 2013 at 11:39:28PM += 0100, Michael Str=C3=B6der wrote:

I see this docume= nt is marked as being intended to be published as
Informational= , but it reads more like it's trying to be a standard.

I tried to add some wording to avoid that misun= derstanding in the next
revision of this draft:

Still -01 =3F

<= /div>
Not =22still=22 -01. Now -01.

You are explicitly excluding details of '=7Bcr= ypt=7D'. I think this is a
mistake, especially in an informatio= nal document. =7Bcrypt=7D is
extremely useful in transition sce= narios, so people need to know about
it.

Hmm...I've expected somebody to ask for it. :-/
It makes the spec part more complex.

What platform-specific variants do you know of=3F=

Well, looking at crypt(3) man page= it seems to me that there are many variants
of the library on = various Unix platforms. This is what I meant with
=22platform-s= pecific=22.

T= he really important one is the old Unix-crypt 13-char salted hash.
<= div>
Could you perhaps say something like:

=7Bcrypt=7D introduces a password-hash string that is generated = and
checked by the crypt(3) library. This could be the traditio= nal
13-character 'Unix crypt' or some other variant such as the= stronger
'=241=24' and =246=24' schemes used by recent version= s of Linux.

I've added some t= ext hopefully getting =7BCRYPT=7D stuff complete. Yuck=21

<= /div>
Ciao, Michael.
=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
= =20 =20

=20
Attachments:
=20 =20 =20 =20 =20 =20 =20
=20
- smime.p7s
=20
=20 =20 =20

--5141a428_4cdced4c_19a-- From michael@stroeder.com Thu Mar 14 07:32:19 2013 Return-Path: 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 AE64F11E8199 for ; Thu, 14 Mar 2013 07:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 XYPrlLSfGmir for ; Thu, 14 Mar 2013 07:32:18 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id E619011E8150 for ; Thu, 14 Mar 2013 07:31:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id DB95E602D1; Thu, 14 Mar 2013 15:31:34 +0100 (CET) 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 3KwEqg2TUOnT; Thu, 14 Mar 2013 15:31:30 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id 3795A60238; Thu, 14 Mar 2013 14:31:29 +0000 (UTC) Message-ID: <5141DF40.3040104@stroeder.com> Date: Thu, 14 Mar 2013 15:31:28 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16 MIME-Version: 1.0 To: Ludovic Poitou References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> <20130314001901.GN18706@slab.skills-1st.co.uk> <5141269B.1030205@stroeder.com> <1B373B048AD84206A7E8AAB9EB4D69AD@gmail.com> In-Reply-To: <1B373B048AD84206A7E8AAB9EB4D69AD@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070703040602080303050009" Cc: "ldap@umich.edu" , ldapext Subject: Re: [ldapext] draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:32:19 -0000 This is a cryptographically signed message in MIME format. --------------ms070703040602080303050009 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ludovic Poitou wrote: > I'm glad that you've added text to support {CRYPT}. But I'm not sure it= is > necessary to make the description complete (i.e. refer to all underlyin= g > platform specific algorithm). > I think it might be enough to describe the general format of passwords > generated by the crypt(3) library, mentions the default unix crypt and = one or > two other algorithm, but also warn that crypt being extensible and plat= form > specific, it's use might result in interoperability issues. That's exactly what I did even without describing any of the algorithms. > I would suggest that you add to the list of schemes, PBKDF2 and BCrypt = that > are 2 mechanisms that are providing much stronger security than the SHA= 1 or 2. > I'be happy to provide a description of PBKDF2 if you want, as we've > implemented support for it in OpenDJ. I'm glad to see PBKDF2 appearing in LDAP server implementations. Yes, please provide text to be added. Ciao, Michael. --------------ms070703040602080303050009 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE0MTQzMTI4WjAjBgkq hkiG9w0BCQQxFgQUzQ5qMqPzcPzNWUTp51RXN3q8ZHAwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAom2Kn6hkybP0u6Y1bTpyoJ7qHutioWB0WBZNJResUxWjERpIjcSivuY0FCUqHdm+pq0t 4qRXJ08i8QuI1HXKouKTyQwHoXuAzF/Z37EECQ3RR70Tv1ywN3hbL8bo7SzbyFOCkiHgxVTe nFgThQNUvjpWbhhE4f4+1gjWp3AoquS357oF4EPk1/9mCZxXPOOtKNcVkSh1YSBrzC1SI717 pAVeUIIiBWpkP/bA7ASjVsrVTF/FVP9Oz4DnrDwTKTtwDEjmgRSvfh6B5SFiLzefeFSBaXWD 2kgned+hRKmruaSTD0gOQqZLR8nZgkA4G50LonDVKDFKu5PwWSP3XQ9YYQAAAAAAAA== --------------ms070703040602080303050009-- From hyc@highlandsun.com Thu Mar 14 09:06:07 2013 Return-Path: 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 88BF011E8267 for ; Thu, 14 Mar 2013 09:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ulW6eoRXX3ep for ; Thu, 14 Mar 2013 09:06:03 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE9311E8141 for ; Thu, 14 Mar 2013 09:05:54 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 1F07B84ED5; Thu, 14 Mar 2013 12:05:52 -0400 (EDT) Message-ID: <5141F560.6040805@highlandsun.com> Date: Thu, 14 Mar 2013 09:05:52 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0 SeaMonkey/2.19a1 MIME-Version: 1.0 To: Andrew Findlay , ldapext References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> <20130314001901.GN18706@slab.skills-1st.co.uk> In-Reply-To: <20130314001901.GN18706@slab.skills-1st.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "ldap@umich.edu" , Kurt Zeilenga Subject: Re: [ldapext] draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 16:06:07 -0000 Andrew Findlay wrote: > On Wed, Mar 13, 2013 at 11:39:28PM +0100, Michael Ströder wrote: > >>> I see this document is marked as being intended to be published as >>> Informational, but it reads more like it's trying to be a standard. >> >> I tried to add some wording to avoid that misunderstanding in the next >> revision of this draft: >> >> http://www.ietf.org/internet-drafts/draft-stroeder-hashed-userpassword-values-01.txt > > Still -01 ? > > You are explicitly excluding details of '{crypt}'. I think this is a > mistake, especially in an informational document. {crypt} is > extremely useful in transition scenarios, so people need to know about > it. Who benefits from this document? What interoperability problems does it solve? Hashed userPassword values are strictly a server-internal implementation detail, clients never need to know about them. The syntax specification is defective in at least 2 ways: 1) it only allows a form "hashandsalt" which actually precludes any unsalted hash mechanisms. 2) it only allows "b64-hashandsalt" which precludes any mechanisms that don't use base64 format for their values. E.g. Unix crypt and Windows LANMAN hash formats use their own binary-to-printable encoding, not base64. > What platform-specific variants do you know of? > The really important one is the old Unix-crypt 13-char salted hash. > > Could you perhaps say something like: > > {crypt} introduces a password-hash string that is generated and > checked by the crypt(3) library. This could be the traditional > 13-character 'Unix crypt' or some other variant such as the stronger > '$1$' and $6$' schemes used by recent versions of Linux. > > Andrew > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From kurt.zeilenga@isode.com Thu Mar 14 10:34:40 2013 Return-Path: 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 700B011E80E9 for ; Thu, 14 Mar 2013 10:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 4lbrD6XSNDw5 for ; Thu, 14 Mar 2013 10:34:36 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 1426A21F8F35 for ; Thu, 14 Mar 2013 10:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1363282474; d=isode.com; s=selector; i=@isode.com; bh=1l9pqknA5q8VqIoGRdBYxXrfQIYsV8tSX+IjjuAFGAw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Zi2e3UPVMjM1D3Zp5BOpDSnmdi3ik9cZM2K7k955D9yYICl7vZt3cdzO2VqH+lUsB3EF7Q 8LAZaYpLq6llw7zv4nZ1eNftQh6aBdHtlqrazxYlsq0rfUZjHSl4YxgEWV3rQ+p2k0oAhu nNCDakFf03h7V95mWIV/z2HRMMvgccA=; Received: from pagan.boolean.net (66-214-104-34.dhcp.slto.ca.charter.com [66.214.104.34]) by statler.isode.com (submission channel) via TCP with ESMTPSA id for ; Thu, 14 Mar 2013 17:34:34 +0000 From: Kurt Zeilenga In-Reply-To: <51410020.4020800@stroeder.com> Date: Thu, 14 Mar 2013 10:34:28 -0700 Message-Id: <83CC875C-A64C-47D9-84CB-5C34DE0C67DE@isode.com> References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> To: ldapext X-Mailer: Apple Mail (2.1499) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [ldapext] draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 17:34:40 -0000 SCRAM is "{" scram-mech"}" scram-authInfo "$" scram-authValue where the scram-* productions are defined in RFC 5803. Example: = {SCRAM-SHA-1}4096:oX1HwnNpqWsmV5xrv5m1YQ=3D=3D$PcqaaIoiFSOA9/txc4QaNa1jWxA= =3D:4m6FNpHpuxJK63WRpXTAinev7zM=3D -- Kurt= From michael@stroeder.com Thu Mar 14 11:30:01 2013 Return-Path: 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 A2E9E11E81B8 for ; Thu, 14 Mar 2013 11:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 hzvICZ0LvYtt for ; Thu, 14 Mar 2013 11:29:59 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB1D11E818B for ; Thu, 14 Mar 2013 11:29:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id EA9BC60306; Thu, 14 Mar 2013 19:29:57 +0100 (CET) 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 9tSHaYFh-wGf; Thu, 14 Mar 2013 19:29:51 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id CE0456027F; Thu, 14 Mar 2013 18:29:49 +0000 (UTC) Message-ID: <5142171C.6090807@stroeder.com> Date: Thu, 14 Mar 2013 19:29:48 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16 MIME-Version: 1.0 To: Howard Chu , ldapext References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> <20130314001901.GN18706@slab.skills-1st.co.uk> <5141F560.6040805@highlandsun.com> In-Reply-To: <5141F560.6040805@highlandsun.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050108010309080403020002" Cc: "ldap@umich.edu" Subject: Re: [ldapext] [ldap] Re: draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 18:30:01 -0000 This is a cryptographically signed message in MIME format. --------------ms050108010309080403020002 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Howard Chu wrote: > Andrew Findlay wrote: >> On Wed, Mar 13, 2013 at 11:39:28PM +0100, Michael Str=F6der wrote: >> >>>> I see this document is marked as being intended to be published as >>>> Informational, but it reads more like it's trying to be a standard. >>> >>> I tried to add some wording to avoid that misunderstanding in the nex= t >>> revision of this draft: >>> >>> http://www.ietf.org/internet-drafts/draft-stroeder-hashed-userpasswor= d-values-01.txt >>> >> >> Still -01 ? >> >> You are explicitly excluding details of '{crypt}'. I think this is a >> mistake, especially in an informational document. {crypt} is >> extremely useful in transition scenarios, so people need to know about= >> it. >=20 > Who benefits from this document? What interoperability problems does it= solve? Anybody who has to generate or compare such userPassword values. > Hashed userPassword values are strictly a server-internal implementatio= n > detail, clients never need to know about them. Not true. 1. E.g. think of bulk sync processes where it's quite usual that you conv= ert password hashes within the LDAP client - in some cases even salted. 2. Furthermore if a server does not support RFC 3062 and/or server-side hashing but supports this hashed values when performing password checking= you also have to do client-side generation. This gets rare with recent server= releases of various vendors but it's not something to completely ignore. 3. In some cases it's more appropriate that a LDAP client writes several attributes in a *single* LDAP write operation instead of using a add/modi= fy with a subsequent Password Modify ext. op. E.g. when subschema has 'MUST userPassword' for an object class used. > The syntax specification is defective in at least 2 ways: > 1) it only allows a form "hashandsalt" which actually precludes any u= nsalted > hash mechanisms. Not true. The unsalted variant has simply a zero-length salt. For -02 I'v= e added some text to clarify this. > 2) it only allows "b64-hashandsalt" which precludes any mechanisms th= at > don't use base64 format for their values. E.g. Unix crypt and Windows L= ANMAN > hash formats use their own binary-to-printable encoding, not base64. Well, at first I simply wanted to ignore this completely. But after Andrews request I've already changed it for upcoming -02 like t= his: userpasswordvalue =3D cleartext-password / prefix hashed-password prefix =3D "{" scheme "}" scheme =3D %x30-39 / %x41-5A / %x61-7a / %x2D-2F / %x5F ;0-9, A-Z, a-z, "-", ".", "/", or "_" hashed-password =3D b64-hashandsalt / crypt3-result b64-hashandsalt =3D hashandsalt =3D password-hash salt password-hash =3D cleartext-password =3D %x00-FF salt =3D %x00-FF crypt3-result =3D Please review this. Comments about clarity welcome. Ciao, Michael. --------------ms050108010309080403020002 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE0MTgyOTQ4WjAjBgkq hkiG9w0BCQQxFgQUpzRynR6oCkw/5sYEjr78rm/VxVowbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEADqtsGBWpN17/f6Lw1Zydtl29BFom/o9ST0ql53U2aUMJrkCPATwQ3e7Hu+jwesJnIaYK R0g0pbA7udBZI5sjvxN48qaga+dKMdg+Dz0v/2HHDoUmSbKfnSN8v1xMJkCQ+aOjULFaVJ5I OFEgVRoBy8gblekFZnKOhTuZdFjHwCrOt3hr3sDJuI/KFnuiw2o+LjiufejKM5ByY5JrBqmW iTbLq+lhNeDQ49zzY5fxsh+0+EwYvSb16Glv0C1PYbSSvSMZqBezTTFTrgWb/76DevKweCbV fUfmu8+3RkXe/ThYs5J5SBHNRGxyXZFmT7z/5GrB2/ZcE3MPM1QCNnEQZQAAAAAAAA== --------------ms050108010309080403020002-- From hyc@highlandsun.com Thu Mar 14 12:02:36 2013 Return-Path: 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 0F51721F910A for ; Thu, 14 Mar 2013 12:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, 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 kEGSdlnxmEIs for ; Thu, 14 Mar 2013 12:02:35 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by ietfa.amsl.com (Postfix) with ESMTP id F240321F911F for ; Thu, 14 Mar 2013 12:02:34 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 04F9584ED5; Thu, 14 Mar 2013 15:02:33 -0400 (EDT) Message-ID: <51421EC9.6060502@highlandsun.com> Date: Thu, 14 Mar 2013 12:02:33 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0 SeaMonkey/2.19a1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_Str=F6der?= , ldapext References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> <20130314001901.GN18706@slab.skills-1st.co.uk> <5141F560.6040805@highlandsun.com> <5142171C.6090807@stroeder.com> In-Reply-To: <5142171C.6090807@stroeder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "ldap@umich.edu" Subject: Re: [ldapext] [ldap] Re: draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:02:36 -0000 Michael Ströder wrote: > Howard Chu wrote: >> Andrew Findlay wrote: >>> On Wed, Mar 13, 2013 at 11:39:28PM +0100, Michael Ströder wrote: >>> >>>>> I see this document is marked as being intended to be published as >>>>> Informational, but it reads more like it's trying to be a standard. >>>> >>>> I tried to add some wording to avoid that misunderstanding in the next >>>> revision of this draft: >>>> >>>> http://www.ietf.org/internet-drafts/draft-stroeder-hashed-userpassword-values-01.txt >>>> >>> >>> Still -01 ? >>> >>> You are explicitly excluding details of '{crypt}'. I think this is a >>> mistake, especially in an informational document. {crypt} is >>> extremely useful in transition scenarios, so people need to know about >>> it. >> >> Who benefits from this document? What interoperability problems does it solve? > > Anybody who has to generate or compare such userPassword values. > >> Hashed userPassword values are strictly a server-internal implementation >> detail, clients never need to know about them. > > Not true. > > 1. E.g. think of bulk sync processes where it's quite usual that you convert > password hashes within the LDAP client - in some cases even salted. If you can convert from one hash to another, the hash is broken. > 2. Furthermore if a server does not support RFC 3062 and/or server-side > hashing but supports this hashed values when performing password checking you > also have to do client-side generation. This gets rare with recent server > releases of various vendors but it's not something to completely ignore. A server that can effectively read/use values but cannot write/create them in the first place has to be considered defective. Fine, don't ignore it, but footnote it. It doesn't deserve to be treated as in any way normal. > 3. In some cases it's more appropriate that a LDAP client writes several > attributes in a *single* LDAP write operation instead of using a add/modify > with a subsequent Password Modify ext. op. E.g. when subschema has 'MUST > userPassword' for an object class used. Perhaps so. But this requires the client (or admin running the client) to already know what schemes the target server supports. So again, it's server-specific knowledge and isn't required for interoperability between heterogeneous implementations. Taking the opposite approach - there is no way for a server to advertise what mechanisms it supports, so an uninformed client/admin cannot possibly do this correctly anyway. And on that note - no, I don't believe the server should advertise what its supported mechanisms are. Again, it's purely an internal matter, and there's no reason to give an arbitrary 3rd party a head start on cracking attempts. Without advance knowledge, obtained out of band, none of these scenarios are feasible. The advance knowledge is always specific to a particular server deployment. Finally, an objectclass that defines "MUST userPassword" also has to be considered broken. (Reminds me of groupOfNames / MUST member.) >> The syntax specification is defective in at least 2 ways: >> 1) it only allows a form "hashandsalt" which actually precludes any unsalted >> hash mechanisms. > > Not true. The unsalted variant has simply a zero-length salt. For -02 I've > added some text to clarify this. > >> 2) it only allows "b64-hashandsalt" which precludes any mechanisms that >> don't use base64 format for their values. E.g. Unix crypt and Windows LANMAN >> hash formats use their own binary-to-printable encoding, not base64. > > Well, at first I simply wanted to ignore this completely. > But after Andrews request I've already changed it for upcoming -02 like this: > > userpasswordvalue = cleartext-password / prefix hashed-password I think you should replace "hashed-password" with "scheme-specific data" and stop there. Provide examples for MD5/SHA/SHA-2 if you like, but emphasize that these are just informal examples. There's no reason someone can't come along and use an unconstrained octet string after the scheme, if they really want to. > prefix = "{" scheme "}" > scheme = %x30-39 / %x41-5A / %x61-7a / %x2D-2F / %x5F > ;0-9, A-Z, a-z, "-", ".", "/", or "_" > > hashed-password = b64-hashandsalt / crypt3-result > > b64-hashandsalt = > > hashandsalt = password-hash salt > > password-hash = > > cleartext-password = %x00-FF > > salt = %x00-FF > > crypt3-result = > > Please review this. Comments about clarity welcome. > > Ciao, Michael. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From michael@stroeder.com Thu Mar 14 12:19:26 2013 Return-Path: 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 02C4A11E811F for ; Thu, 14 Mar 2013 12:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 tvXhW7YknkLM for ; Thu, 14 Mar 2013 12:19:25 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id F27D811E80F2 for ; Thu, 14 Mar 2013 12:19:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id A8C216030F; Thu, 14 Mar 2013 20:19:23 +0100 (CET) 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 vB2aZCJ3K5Xh; Thu, 14 Mar 2013 20:19:17 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id D27236027F; Thu, 14 Mar 2013 19:19:14 +0000 (UTC) Message-ID: <514222B0.9090107@stroeder.com> Date: Thu, 14 Mar 2013 20:19:12 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16 MIME-Version: 1.0 To: Howard Chu , ldapext References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> <20130314001901.GN18706@slab.skills-1st.co.uk> <5141F560.6040805@highlandsun.com> <5142171C.6090807@stroeder.com> <51421EC9.6060502@highlandsun.com> In-Reply-To: <51421EC9.6060502@highlandsun.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020405050500060001050609" Cc: "ldap@umich.edu" Subject: Re: [ldapext] [ldap] Re: draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:19:26 -0000 This is a cryptographically signed message in MIME format. --------------ms020405050500060001050609 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Howard Chu wrote: > Michael Str=F6der wrote: >> Howard Chu wrote: >>> Hashed userPassword values are strictly a server-internal implementat= ion >>> detail, clients never need to know about them. >> >> Not true. >> >> 1. E.g. think of bulk sync processes where it's quite usual that you c= onvert >> password hashes within the LDAP client - in some cases even salted. >=20 > If you can convert from one hash to another, the hash is broken. Conversion in this context means converting string representations of (sa= lted) hashes. Obviously the algorithm and order of password and salt has to be = the same. >> 3. In some cases it's more appropriate that a LDAP client writes sever= al >> attributes in a *single* LDAP write operation instead of using a add/m= odify >> with a subsequent Password Modify ext. op. E.g. when subschema has 'MU= ST >> userPassword' for an object class used. >=20 > Perhaps so. But this requires the client (or admin running the client) = to > already know what schemes the target server supports. We all know that clients have to use some a priori knowledge - most times= called protocol. ;-) Another use-cases is dealing with data migration to server product of ano= ther vendor. =3D> So I consider this draft to be useful. > Finally, an objectclass that defines "MUST userPassword" also has to be= > considered broken. (Reminds me of groupOfNames / MUST member.) That's simply your personal opinion not a strong objecting argument. >> userpasswordvalue =3D cleartext-password / prefix hashed-passwor= d >=20 > I think you should replace "hashed-password" with "scheme-specific data= " and > stop there. That's a conclusion of your opinion. But I want to describe the *order* o= f password and salt used by any server I saw using the scheme. > Provide examples for MD5/SHA/SHA-2 if you like, but emphasize that > these are just informal examples. The whole I-D has target "informational". > There's no reason someone can't come along > and use an unconstrained octet string after the scheme, if they really = want to. Yes. But this would just be another scheme to be defined somewhere else. This draft does not claim to cover everything you could ever stuff into 'userPassword'. Ciao, Michael. --------------ms020405050500060001050609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE0MTkxOTEyWjAjBgkq hkiG9w0BCQQxFgQUoXKcUJkgnJT733rSxnKB/dyq2+AwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAdZJTMhW/FK9O9RqYO7HOiCLwmo+vtRD3rxCnb5vIuujfDCYuPnGS7WHaSmjJ2nfFWbXI ESoSEAm4lpU66M7ntR+2A6CdENfdbQQjHKzs0tL96qWTvF7jxG0dQSy83j9KpebfFYL2nLpO RoQVWSvAAaJAdzNh4FebNzQPWG4gssquyh8YATCcAhQ4VsOxHhx+qeQ3Kv/69Hq8NOC6AcHc hu2nu+ss3r9iZMHdhp5L+Uu6zMddt0Q0b/lSC0iQb6fcKQ4u/EiAyhl4roTyvoHKFXfGqJgK 2U3s1ETKnaJU+ylGS3NPUMLnwFWg7T5mm7g6fAr33rVp/8CDcrjdbbGxsQAAAAAAAA== --------------ms020405050500060001050609-- From hyc@highlandsun.com Thu Mar 14 12:35:06 2013 Return-Path: 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 4344F11E8192 for ; Thu, 14 Mar 2013 12:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, 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 AHNmNUzrYlrK for ; Thu, 14 Mar 2013 12:35:05 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFED11E80BF for ; Thu, 14 Mar 2013 12:35:05 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 43C8984ED5; Thu, 14 Mar 2013 15:35:01 -0400 (EDT) Message-ID: <51422664.1040209@highlandsun.com> Date: Thu, 14 Mar 2013 12:35:00 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0 SeaMonkey/2.19a1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_Str=F6der?= , ldapext References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> <20130314001901.GN18706@slab.skills-1st.co.uk> <5141F560.6040805@highlandsun.com> <5142171C.6090807@stroeder.com> In-Reply-To: <5142171C.6090807@stroeder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "ldap@umich.edu" Subject: Re: [ldapext] [ldap] Re: draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:35:06 -0000 Michael Ströder wrote: > Well, at first I simply wanted to ignore this completely. > But after Andrews request I've already changed it for upcoming -02 like this: I think you need to re-read RFC5234. > > userpasswordvalue = cleartext-password / prefix hashed-password > > prefix = "{" scheme "}" > scheme = %x30-39 / %x41-5A / %x61-7a / %x2D-2F / %x5F > ;0-9, A-Z, a-z, "-", ".", "/", or "_" Should be something like schemechar = %x30-39 / %x41-5A / %x61-7a / %x2D-2F / %x5F scheme = 1*schemechar > > hashed-password = b64-hashandsalt / crypt3-result > > b64-hashandsalt = > > hashandsalt = password-hash salt > > password-hash = > cleartext-password = %x00-FF > > salt = %x00-FF Should be something like octet = %x00-FF cleartext-password = 1*octet salt = 0*octet (Or perhaps you allow zero-length passwords? Don't care much either way.) md5-hash = 16octet sha1-hash = 20octet ... > crypt3-result = > > Please review this. Comments about clarity welcome. > > Ciao, Michael. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From michael@stroeder.com Thu Mar 14 15:51:59 2013 Return-Path: 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 3D60611E81B5 for ; Thu, 14 Mar 2013 15:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 3tN1uY6UjQc8 for ; Thu, 14 Mar 2013 15:51:58 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 508C511E81B2 for ; Thu, 14 Mar 2013 15:51:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 8893C60331; Thu, 14 Mar 2013 23:51:56 +0100 (CET) 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 TnO1MXC1gSS8; Thu, 14 Mar 2013 23:51:52 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id A4B206028F; Thu, 14 Mar 2013 22:51:51 +0000 (UTC) Message-ID: <51425486.4020606@stroeder.com> Date: Thu, 14 Mar 2013 23:51:50 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16 MIME-Version: 1.0 To: Howard Chu , ldapext References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> <20130314001901.GN18706@slab.skills-1st.co.uk> <5141F560.6040805@highlandsun.com> <5142171C.6090807@stroeder.com> <51422664.1040209@highlandsun.com> In-Reply-To: <51422664.1040209@highlandsun.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030207080700020401080801" Cc: "ldap@umich.edu" Subject: Re: [ldapext] [ldap] Re: draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 22:51:59 -0000 This is a cryptographically signed message in MIME format. --------------ms030207080700020401080801 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Howard Chu wrote: > Michael Str=F6der wrote: >> Well, at first I simply wanted to ignore this completely. >> But after Andrews request I've already changed it for upcoming -02 lik= e this: >=20 > I think you need to re-read RFC5234. I did and followed some more of the recommendations found therein. Thanks for your feedback regarding the ABNF definition. Most of your modifications will appear in -02. Not sure about whether it's really needed to have something like this: md5-hash =3D 16octet sha1-hash =3D 20octet I'd like to avoid having to specify a rule for each algorithm. But maybe = it should be made more clear how the table listing the algorithms should be interpreted. Ciao, Michael. --------------ms030207080700020401080801 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE0MjI1MTUwWjAjBgkq hkiG9w0BCQQxFgQUO85Ibx504dKESWs5blDoXURv4gQwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAZ4rPKVb/kX2wQWfxgPe2uMn0ziDWoX6opz7D3B+2PNF23aGH5DN5erCmwsufr6YMAW6K T0IMjWu1eOwASalqubaVr7YWamViL+p7X5QqY+Bq28MgVPFteU10/Sfa2Ju7FkzI8OkOXac5 WKiLN09a9Q4XFTHjddY3r+Xflmr7PchIv3GZtM8KwyUMF7+y4g9N0Spo/X6p35d63bmA3NpJ qAjYb89USduKJo02OORL/+GxCIfPNirU1UDHQ2BjmiboFUdMnizpZ5MmqwTEebLNLNSUfODj u1MUo2kctsNHM10E5bYXSo69fMEE6TjuvDi1+y/Pan/3TvaWZYVpNajkxQAAAAAAAA== --------------ms030207080700020401080801-- From andrew.findlay@skills-1st.co.uk Fri Mar 15 03:18:45 2013 Return-Path: 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 12FC621F8B75 for ; Fri, 15 Mar 2013 03:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 hs7P42DS10pr for ; Fri, 15 Mar 2013 03:18:44 -0700 (PDT) Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) by ietfa.amsl.com (Postfix) with ESMTP id D840C21F8B71 for ; Fri, 15 Mar 2013 03:18:43 -0700 (PDT) Received: from 2.b.0.9.d.6.e.f.f.f.a.6.1.2.2.0.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1:221:6aff:fe6d:90b2] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UGRij-00016i-DT; Fri, 15 Mar 2013 10:18:41 +0000 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.80.1) (envelope-from ) id 1UGRii-0005VK-S0; Fri, 15 Mar 2013 10:18:40 +0000 Date: Fri, 15 Mar 2013 10:18:40 +0000 From: Andrew Findlay To: Michael =?iso-8859-1?Q?Str=F6der?= Message-ID: <20130315101840.GQ18706@slab.skills-1st.co.uk> References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> <20130314001901.GN18706@slab.skills-1st.co.uk> <5141F560.6040805@highlandsun.com> <5142171C.6090807@stroeder.com> <51421EC9.6060502@highlandsun.com> <514222B0.9090107@stroeder.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <514222B0.9090107@stroeder.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Cc: "ldap@umich.edu" , ldapext Subject: Re: [ldapext] [ldap] Re: draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 10:18:45 -0000 On Thu, Mar 14, 2013 at 08:19:12PM +0100, Michael Ströder wrote: > >> userpasswordvalue = cleartext-password / prefix hashed-password > > > > I think you should replace "hashed-password" with "scheme-specific data" and > > stop there. > > That's a conclusion of your opinion. But I want to describe the *order* of > password and salt used by any server I saw using the scheme. Why not separate the description of the data from the overall syntax? It will be easier to read that way, and much more obvious that the whole thing is extensible and a bit informal. userPassword has Octet String syntax, so in principle the value is A separate section of the doc could then describe (or refer to) the formats of all the commonly-used storage schemes. I was about to call them 'hash schemes' but that is wrong, as some servers support reversible encryption schemes as well as hashes. On a slight tangent, a rough guide to the current strength of various hash schemes can be found on hashcat's front page: http://hashcat.net/oclhashcat-plus/ The table at the bottom gives the brute-force attack rate in crypts/sec using a single PC with a good (mid-range gaming) graphics engine. Numbers range from about 4k c/s for bcrypt up to 7500M c/2 for NTLM. It does not explicitly list figures for SSHA and SMD5 but I suspect the 'sha512crypt $6$' figure is indicative at 12k c/s. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- From kurt.zeilenga@isode.com Fri Mar 15 04:07:53 2013 Return-Path: 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 4E36D21F8F08 for ; Fri, 15 Mar 2013 04:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 BQS98o-WvPEc for ; Fri, 15 Mar 2013 04:07:52 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id DA61021F8F61 for ; Fri, 15 Mar 2013 04:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1363345660; d=isode.com; s=selector; i=@isode.com; bh=FZ26dyXXuXGIXkSkqxKAs/a1dvVsmCnBd714R3t5e4k=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=cIV7v/diL2OdjIILps651d39OXqLuil4UVlTQfpSG0ENQFawuuoG8Tc7QuoAtWaA0HFOlV DX+RSbhVnuJ5oKsT5lgLQH5FwBcCQDww/a/H2tbycLhXkhDtbwenT8Se2no6Hg2GO4iBYj LLzg+JO4Y8qnhxr/ApH/CMJkOLt2eAk=; Received: from pagan.boolean.net (66-214-104-34.dhcp.slto.ca.charter.com [66.214.104.34]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 15 Mar 2013 11:07:39 +0000 From: Kurt Zeilenga In-Reply-To: <20130315101840.GQ18706@slab.skills-1st.co.uk> Date: Fri, 15 Mar 2013 04:07:29 -0700 Message-Id: References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> <20130314001901.GN18706@slab.skills-1st.co.uk> <5141F560.6040805@highlandsun.com> <5142171C.6090807@stroeder.com> <51421EC9.6060502@highlandsun.com> <514222B0.9090107@stroeder.com> <20130315101840.GQ18706@slab.skills-1st.co.uk> To: Andrew Findlay X-Mailer: Apple Mail (2.1503) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ldap@umich.edu" , ldapext , =?iso-8859-1?Q?Michael_Str=F6der?= Subject: Re: [ldapext] [ldap] Re: draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 11:07:53 -0000 On Mar 15, 2013, at 3:18 AM, Andrew Findlay = wrote: > On Thu, Mar 14, 2013 at 08:19:12PM +0100, Michael Str=F6der wrote: >=20 >>>> userpasswordvalue =3D cleartext-password / prefix = hashed-password >>>=20 >>> I think you should replace "hashed-password" with "scheme-specific = data" and >>> stop there. >>=20 >> That's a conclusion of your opinion. But I want to describe the = *order* of >> password and salt used by any server I saw using the scheme. >=20 > Why not separate the description of the data from the overall syntax? > It will be easier to read that way, and much more obvious that the = whole > thing is extensible and a bit informal. >=20 > userPassword has Octet String syntax, so in principle the value is > >=20 > A separate section of the doc could then describe (or refer to) the = formats > of all the commonly-used storage schemes. I was about to call them = 'hash > schemes' but that is wrong, as some servers support reversible = encryption > schemes as well as hashes. >=20 >=20 > On a slight tangent, a rough guide to the current strength of various = hash > schemes can be found on hashcat's front page: >=20 > http://hashcat.net/oclhashcat-plus/ >=20 > The table at the bottom gives the brute-force attack rate in = crypts/sec > using a single PC with a good (mid-range gaming) graphics engine. > Numbers range from about 4k c/s for bcrypt up to 7500M c/2 for NTLM. > It does not explicitly list figures for SSHA and SMD5 but I suspect = the > 'sha512crypt $6$' figure is indicative at 12k c/s. The difference per check of SSHA and SHA is one SHAUpdate call, even if = this call account for 100% of the work, then SSHA should be no more than = twice as expensive SHA. Likewise for other simple salted hash methods. -- Kurt >=20 > Andrew > --=20 > = ----------------------------------------------------------------------- > | =46rom Andrew Findlay, Skills 1st Ltd = | > | Consultant in large-scale systems, networks, and directory services = | > | http://www.skills-1st.co.uk/ +44 1628 782565 = | > = ----------------------------------------------------------------------- > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext From andrew.findlay@skills-1st.co.uk Fri Mar 15 05:36:19 2013 Return-Path: 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 DF86B21F9138 for ; Fri, 15 Mar 2013 05:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 gko9DVSOP-rW for ; Fri, 15 Mar 2013 05:36:18 -0700 (PDT) Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) by ietfa.amsl.com (Postfix) with ESMTP id 3940921F9137 for ; Fri, 15 Mar 2013 05:36:14 -0700 (PDT) Received: from 2.b.0.9.d.6.e.f.f.f.a.6.1.2.2.0.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1:221:6aff:fe6d:90b2] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UGTrn-0002Ln-6W; Fri, 15 Mar 2013 12:36:11 +0000 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.80.1) (envelope-from ) id 1UGTrm-0005xO-C2; Fri, 15 Mar 2013 12:36:10 +0000 Date: Fri, 15 Mar 2013 12:36:10 +0000 From: Andrew Findlay To: Kurt Zeilenga Message-ID: <20130315123610.GR18706@slab.skills-1st.co.uk> References: <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> <20130314001901.GN18706@slab.skills-1st.co.uk> <5141F560.6040805@highlandsun.com> <5142171C.6090807@stroeder.com> <51421EC9.6060502@highlandsun.com> <514222B0.9090107@stroeder.com> <20130315101840.GQ18706@slab.skills-1st.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Cc: "ldap@umich.edu" , ldapext , Michael =?iso-8859-1?Q?Str=F6der?= Subject: Re: [ldapext] [ldap] Re: draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 12:36:20 -0000 On Fri, Mar 15, 2013 at 04:07:29AM -0700, Kurt Zeilenga wrote: > > On a slight tangent, a rough guide to the current strength of various hash > > schemes can be found on hashcat's front page: > > > > http://hashcat.net/oclhashcat-plus/ > > > > The table at the bottom gives the brute-force attack rate in crypts/sec > > using a single PC with a good (mid-range gaming) graphics engine. > > Numbers range from about 4k c/s for bcrypt up to 7500M c/2 for NTLM. > > It does not explicitly list figures for SSHA and SMD5 but I suspect the > > 'sha512crypt $6$' figure is indicative at 12k c/s. > > The difference per check of SSHA and SHA is one SHAUpdate call, even if this call account for 100% of the work, then SSHA should be no more than twice as expensive SHA. Likewise for other simple salted hash methods. Good point. Salt protects against pre-computed lookup tables but on its own has minimal effect on this style of brute-force attack, as the salt is known by the attacker. The big difference with sha512crypt is the number of rounds. This defaults to 5000, which should make it 5000 times slower than SHA512. The Hashcat numbers are roughly consistent with that. This suggests that implementers should be encouraged to future-proof their products: Make it easy to add new password-storage schemes - preferably without recompiling the server or client code Provide schemes with multiple rounds in the standard distribution Make it easy to configure the number of rounds Ensure that passwords stored with different schemes and number of rounds can still be used even if the server config is changed Provide a way to disable passwords stored with particular configs in the past that are now considered insecure The document under discussion would be a good place to put that advice. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- From andrew.findlay@skills-1st.co.uk Fri Mar 15 05:53:29 2013 Return-Path: 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 9EF4221F8F56 for ; Fri, 15 Mar 2013 05:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 vuu4uARRMR1G for ; Fri, 15 Mar 2013 05:53:29 -0700 (PDT) Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) by ietfa.amsl.com (Postfix) with ESMTP id BB09E21F8F4F for ; Fri, 15 Mar 2013 05:53:28 -0700 (PDT) Received: from 2.b.0.9.d.6.e.f.f.f.a.6.1.2.2.0.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1:221:6aff:fe6d:90b2] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UGU8V-0002UV-Jl; Fri, 15 Mar 2013 12:53:27 +0000 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.80.1) (envelope-from ) id 1UGU8U-00060f-R1; Fri, 15 Mar 2013 12:53:26 +0000 Date: Fri, 15 Mar 2013 12:53:26 +0000 From: Andrew Findlay To: Michael =?iso-8859-1?Q?Str=F6der?= Message-ID: <20130315125326.GA22595@slab.skills-1st.co.uk> References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51410020.4020800@stroeder.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Cc: "ldap@umich.edu" , ldapext Subject: Re: [ldapext] draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 12:53:29 -0000 On Wed, Mar 13, 2013 at 11:39:28PM +0100, Michael Ströder wrote: > http://www.ietf.org/internet-drafts/draft-stroeder-hashed-userpassword-values-01.txt In section 3 Implementation Issues, the 4th paragraph talks about checking the syntax of the storage scheme. This certainly has to be done, but I am a bit worried by the last sentence: Any value which do not adhere to this syntax MAY be treated as clear-text password by the DSA when processing a LDAP simple bind request or LDAP compare request. This is probably what most servers actually do, but it does mean that any unrecognised schemes or badly-formatted values effectively become clear-text passwords. Not a good failure mode... This is another case where the use of standard-setting words like MAY and SHOULD sits uneasily with the informational status of the document. From a security perspective I would prefer something like this: Any value which does not have correct syntax SHOULD be treated as a value that can never match any password asserted by a user. On the other hand, as a description of current practice it may be better to say: The treatment of values with incorrect syntax is defined by the server implementation. Administrators should be aware that servers may treat such values as clear-text passwords, thus removing the benefit of hashing entirely. Values using storage schemes not known to the server may have the same effect. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- From hyc@highlandsun.com Fri Mar 15 06:18:11 2013 Return-Path: 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 21A3C21F913E for ; Fri, 15 Mar 2013 06:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, 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 vrrE+8NiDgd2 for ; Fri, 15 Mar 2013 06:18:10 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by ietfa.amsl.com (Postfix) with ESMTP id 56FA221F8FA4 for ; Fri, 15 Mar 2013 06:18:08 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 7731784ED5; Fri, 15 Mar 2013 09:18:06 -0400 (EDT) Message-ID: <51431F8D.3030701@highlandsun.com> Date: Fri, 15 Mar 2013 06:18:05 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0 SeaMonkey/2.19a1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_Str=F6der?= , ldapext References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> <20130314001901.GN18706@slab.skills-1st.co.uk> <5141F560.6040805@highlandsun.com> <5142171C.6090807@stroeder.com> <51421EC9.6060502@highlandsun.com> <514222B0.9090107@stroeder.com> In-Reply-To: <514222B0.9090107@stroeder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "ldap@umich.edu" Subject: Re: [ldapext] [ldap] Re: draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 13:18:11 -0000 Michael Ströder wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> Howard Chu wrote: >>>> Hashed userPassword values are strictly a server-internal implementation >>>> detail, clients never need to know about them. >>> >>> Not true. >>> >>> 1. E.g. think of bulk sync processes where it's quite usual that you convert >>> password hashes within the LDAP client - in some cases even salted. >> >> If you can convert from one hash to another, the hash is broken. > > Conversion in this context means converting string representations of (salted) > hashes. Obviously the algorithm and order of password and salt has to be the same. > >>> 3. In some cases it's more appropriate that a LDAP client writes several >>> attributes in a *single* LDAP write operation instead of using a add/modify >>> with a subsequent Password Modify ext. op. E.g. when subschema has 'MUST >>> userPassword' for an object class used. >> >> Perhaps so. But this requires the client (or admin running the client) to >> already know what schemes the target server supports. > > We all know that clients have to use some a priori knowledge - most times > called protocol. ;-) > > Another use-cases is dealing with data migration to server product of another > vendor. In which case the Admin must look up the documentation of the other vendor's product. It is not the IETF's job to serve as a clearinghouse for all vendor-specific implementation details, nor is it practical in the long run. > => So I consider this draft to be useful. > >> Finally, an objectclass that defines "MUST userPassword" also has to be >> considered broken. (Reminds me of groupOfNames / MUST member.) > > That's simply your personal opinion not a strong objecting argument. You're obviously missing the bigger picture then. I shouldn't need to remind you of all the trouble that "MUST member" has caused. In this case, deleting a userPassword is a straightforward way of disabling authentication for an account. If your schema prevents this mechanism your schema is broken. That's not an opinion, that's fact. >>> userpasswordvalue = cleartext-password / prefix hashed-password >> >> I think you should replace "hashed-password" with "scheme-specific data" and >> stop there. > > That's a conclusion of your opinion. But I want to describe the *order* of > password and salt used by any server I saw using the scheme. You can describe those things separately, but this is as far as you should go with a formal syntax. Otherwise you will get sucked into the rathole of defining special cases for every currently known encoding, and you've already stated that you want to avoid that. So no, it's a logical conclusion from *your* opinion, not mine. >> Provide examples for MD5/SHA/SHA-2 if you like, but emphasize that >> these are just informal examples. > > The whole I-D has target "informational". > >> There's no reason someone can't come along >> and use an unconstrained octet string after the scheme, if they really want to. > > Yes. But this would just be another scheme to be defined somewhere else. > This draft does not claim to cover everything you could ever stuff into > 'userPassword'. But defining a formal syntax as you're doing *does* exactly that. Which is why I'm telling you you're making a mistake. > Ciao, Michael. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From michael@stroeder.com Fri Mar 15 15:08:27 2013 Return-Path: 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 D64FF11E80A5 for ; Fri, 15 Mar 2013 15:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 uR63SqHm3yGC for ; Fri, 15 Mar 2013 15:08:27 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id A841621F896B for ; Fri, 15 Mar 2013 15:08:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 5D1C3603D4; Fri, 15 Mar 2013 23:08:24 +0100 (CET) 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 cneKPtxLaAdE; Fri, 15 Mar 2013 23:08:16 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id 9F83160327; Fri, 15 Mar 2013 22:08:14 +0000 (UTC) Message-ID: <51439BCF.3080802@stroeder.com> Date: Fri, 15 Mar 2013 23:08:15 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16.2 MIME-Version: 1.0 To: Andrew Findlay References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> <20130315125326.GA22595@slab.skills-1st.co.uk> In-Reply-To: <20130315125326.GA22595@slab.skills-1st.co.uk> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070507030405080406050602" Cc: "ldap@umich.edu" , ldapext Subject: Re: [ldapext] [ldap] Re: draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 22:08:28 -0000 This is a cryptographically signed message in MIME format. --------------ms070507030405080406050602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andrew Findlay wrote: > On Wed, Mar 13, 2013 at 11:39:28PM +0100, Michael Str=F6der wrote: >=20 >> http://www.ietf.org/internet-drafts/draft-stroeder-hashed-userpassword= -values-01.txt >=20 > In section 3 Implementation Issues, the 4th paragraph talks > about checking the syntax of the storage scheme. This > certainly has to be done, but I am a bit worried by the last > sentence: >=20 > Any value which do not adhere to this syntax MAY be treated as > clear-text password by the DSA when processing a LDAP simple > bind request or LDAP compare request. >=20 > This is probably what most servers actually do, but it does > mean that any unrecognised schemes or badly-formatted values > effectively become clear-text passwords. Not a good failure > mode... I know that this sounds kinda problematic but what is the actual risk? The risk depends on how predictable the incorrect value is. It would be good to know how the various server implementors handle this.= Also see this in the context with the paragraph following the above citat= ion: Servers MAY provide local configuration items to limit the set of hash schemes to be processed and for completely disabling use of clear-text passwords in attribute 'userPassword'. The "MAY provide" here sounds too weak from a security perspective but us= ing SHOULD would be too strong. Maybe it could be replaced by a lower-cased "should consider to provide". > This is another case where the use of standard-setting words > like MAY and SHOULD sits uneasily with the informational > status of the document. Agreed. > From a security perspective I would > prefer something like this: >=20 > Any value which does not have correct syntax SHOULD be > treated as a value that can never match any password > asserted by a user. The condition "does not have correct syntax" cannot be resolved because t= he syntax definition starts with: userpasswordvalue =3D cleartext-password / ( prefix hashed-password ) > On the other hand, as a description of current practice it may > be better to say: >=20 > The treatment of values with incorrect syntax is > defined by the server implementation. Administrators > should be aware that servers may treat such values as > clear-text passwords, thus removing the benefit of > hashing entirely. Values using storage schemes not > known to the server may have the same effect. That's better. But I'm not sure whether administrator is a usual term in this type of do= cuments. Ciao, Michael. --------------ms070507030405080406050602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE1MjIwODE1WjAjBgkq hkiG9w0BCQQxFgQU8rXc29RaD4ska5PwGvUIN5gdaKgwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAhBI/jLHv/CBVFntAwAJeGh9DgZUUm+plt0S1/sZfW5NmnJQjD7H5w5QhSgHnK5AfZkLv ON7r7T/pRNckm3nGSKelTBvdeEuF1j5oBdqnJbK4efA/MC0MN0MnhZ3KsMA3/fopwsq7yojD ZZ/7lQy5QiWauAR10TbBtexJcE91UH7ZbmTyYWaYTiabhh1Cr9YOlh3UmydWYzgifULvK+QI FJEXnuc+M98U+D9CXblLvG58D8UYa4XXvCzLnb2xqSUkqZKQR/zF77QvYaaZd4WCuYNZ4OWu NdKroXImTXHS3ZN4SZD/mJPv1kvXIbynVDBPFxN2XTr8FuEHyxA5ufbCrgAAAAAAAA== --------------ms070507030405080406050602-- From michael@stroeder.com Fri Mar 15 15:44:59 2013 Return-Path: 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 BF32621F86C1 for ; Fri, 15 Mar 2013 15:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.239 X-Spam-Level: X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 8OtwxjsvcUz7 for ; Fri, 15 Mar 2013 15:44:59 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id D6CC51F0D07 for ; Fri, 15 Mar 2013 15:44:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 0E133603D6; Fri, 15 Mar 2013 23:44:49 +0100 (CET) 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 iBBL-Z9BZvfV; Fri, 15 Mar 2013 23:44:38 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id 868AF60327; Fri, 15 Mar 2013 22:44:37 +0000 (UTC) Message-ID: <5143A455.80205@stroeder.com> Date: Fri, 15 Mar 2013 23:44:37 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16.2 MIME-Version: 1.0 To: Howard Chu , ldapext References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> <20130314001901.GN18706@slab.skills-1st.co.uk> <5141F560.6040805@highlandsun.com> <5142171C.6090807@stroeder.com> <51421EC9.6060502@highlandsun.com> <514222B0.9090107@stroeder.com> <51431F8D.3030701@highlandsun.com> In-Reply-To: <51431F8D.3030701@highlandsun.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070601010609050802080207" Cc: "ldap@umich.edu" Subject: Re: [ldapext] draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 22:44:59 -0000 This is a cryptographically signed message in MIME format. --------------ms070601010609050802080207 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Howard Chu wrote: > Michael Str=F6der wrote: >> Another use-cases is dealing with data migration to server product of = another >> vendor. >=20 > In which case the Admin must look up the documentation of the other ven= dor's > product. Yes. But it's so much easier to ask a vendor whether the userPassword syn= tax adheres to some of the variants described in this document. Actually acco= rding to your statement above it's a pretty good example why such a document is= needed. >>> Finally, an objectclass that defines "MUST userPassword" also has to = be >>> considered broken. (Reminds me of groupOfNames / MUST member.) >> >> That's simply your personal opinion not a strong objecting argument. >=20 > You're obviously missing the bigger picture then. I don't. But this document is not about schema design anyway. > I shouldn't need to remind > you of all the trouble that "MUST member" has caused. Ok, let's go for this example... I remember Kurt pointing out one use-case for "MUST member" during discus= sion about draft-findlay-ldap-groupofentries: You can check whether 'member' is empty or whether access was prohibited = by ACLs. Not that I'm *personally* in favour of such a use-case (up to now). But another deployer could have good reasons to want that and it was good to = read Kurt's hint about something I personally did not think about before. Or m= aybe even I personally might have such a use-case in the future. So stating that "MUST userPassword" is broken in any case for every deplo= yment is pretty presumptuous. > In this case, deleting a userPassword is a straightforward way of disab= ling > authentication for an account. It's one possibility to do it. It's not the variant I prefer though. And also normal user accounts for humans are not the only user accounts t= o consider. > If your schema prevents this mechanism your schema is broken. That's > not an opinion, that's fact. I strongly disagree for various reasons we should discuss in another thre= ad if you really want. >> Yes. But this would just be another scheme to be defined somewhere els= e. >> This draft does not claim to cover everything you could ever stuff int= o >> 'userPassword'. >=20 > But defining a formal syntax as you're doing *does* exactly that. Which= is why > I'm telling you you're making a mistake. This draft does not claim that the formal syntax specified therein is the= only possible syntax for 'userPassword' ever used. If you suggest wording to make that more clear I'd of course consider it = to be added. Ciao, Michael. --------------ms070601010609050802080207 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE1MjI0NDM3WjAjBgkq hkiG9w0BCQQxFgQUPp+8qntZ83j0K/9mkeSYQro7hdAwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAvnMO9SoWAV/ILBS3TPLrnmvYVEBnevfgpFRwBnXphc6+CUESBSk09brl7+ancpDx5Deq xI8bwpjhqYxBVOBg4rt/lahgJKaVtFGjT2K0AH6bA1VDq1CxfaHft/iSTzmu/wDtaZwasxWS Ft0/JhT+K+N6EA7QugRwao6eNFeBqQnITxzfOZAJYtCN47BHxxSqrI1VXJfeJoKNkO+uy0L3 nogZxgCBMV1AuUEDX5RQ2metut03MLO96+or0t48IUVHjjnD1CNfYDj1fGpK2Kc7CO7neD/F +iXHpLh7k6tR6e8C1EXUzQIVQY2RpIhrb5Mp0LfPNh2GtRaCUlATnecj9wAAAAAAAA== --------------ms070601010609050802080207-- From hbf@ulrik.uio.no Fri Mar 15 20:54:27 2013 Return-Path: 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 2E6041F0D0F for ; Fri, 15 Mar 2013 20:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 M2JRAyRqexgO for ; Fri, 15 Mar 2013 20:54:26 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id AFA0B21F8945 for ; Fri, 15 Mar 2013 20:54:25 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1UGiCO-00067j-Gp; Sat, 16 Mar 2013 04:54:24 +0100 Received: from bombur.uio.no ([129.240.6.233]) by mail-mx3.uio.no with esmtp (Exim 4.80) (envelope-from ) id 1UGiCO-0005g5-2H; Sat, 16 Mar 2013 04:54:24 +0100 Received: by bombur.uio.no (Postfix, from userid 2112) id 4337B562; Sat, 16 Mar 2013 04:54:22 +0100 (CET) From: Hallvard Breien Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Sat, 16 Mar 2013 04:54:22 +0100 To: =?ISO-8859-1?Q?Michael_Str=F6der?= In-Reply-To: <51439BCF.3080802@stroeder.com> References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> <20130315125326.GA22595@slab.skills-1st.co.uk> <51439BCF.3080802@stroeder.com> X-Mailer: VM 8.2.0a under 23.1.1 (x86_64-redhat-linux-gnu) X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 7 sum msgs/h 3 total rcpts 242 max rcpts/h 12 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.552, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: CDA2D7FD9A47A98F0E4D9846820957A377BDB041 X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -55 maxlevel 80 minaction 1 bait 0 mail/h: 2 total 373 max/h 10 blacklist 0 greylist 1 ratelimit 0 Cc: ldap@umich.edu, Andrew Findlay , ldapext@ietf.org Subject: Re: [ldapext] draft-stroeder-hashed-userpassword-values-01 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 03:54:27 -0000 I'm not convinced that this much detail is useful, but anyway: You can document existing practice and recommend what implementations' practice ought to be, but should say that the implementation's doc is authoritative. What implementations have you surveyed for that existing practice? If we generate 'userPassword's which this document says is OK but the implementation does not support, then Bind can break in interesting ways. So users MUST NOT trust this document if the implementation differs, which they must read the implementation doc to discover. E.g. some implementation might have a scheme {SSHA} with a different syntax like . Or: > Implementations MUST be prepared of handling field salt of arbitrary > length. Who wants megabyte-sized salts? It seems reasonable for the implementation to set some arbitrary limit. Both for convenience and because you could do a DoS attack by setting a huge salt and repeatedly Bind, forcing the server to hash a large value often. ================ Unix crypt(3): This is a function, not a library. Drop the 3 since non-Unix people will wonder why we're passing 3 to the function. The definition should boil down to "whatever crypt() returns on this host", which is no more yucky than the notes above other schemes:-) Perhaps less so since there's no point in giving a syntax, crypt() should be used to both generate the hash and verify a password. Please and add a reference to the quite general definition in the Single Unix Specification at functions/crypt.html. It's free, but you must register to read it. ================ An EXAMPLES section with the same value and hash in different schemes would be useful - including Linux {crypt}$1$ (salted MD5) and {SMD5}. ================ >> Any value which do not adhere to this syntax MAY be treated as >> clear-text password (...) > > I know that this sounds kinda problematic but what is the actual risk? Umm... The reason we use hashes at all is that if someone knows the attribute value, he can't just type it in and Bind with it. Please add the {CLEARTEXT} scheme from OpenLDAP for this purpose. RECOMMEND that servers are configured to not recognize userPassword values without a scheme. And maybe that this config is the default. ================ >> There's no reason someone can't come along and use an unconstrained >> octet string after the scheme, if they really want to. > > Yes. But this would just be another scheme to be defined somewhere > else. This draft does not claim to cover everything you could ever > stuff into 'userPassword'. Yes it does. The sentence "userPassword values MUST be represented by following syntax:" claims to cover everything you could ever stuff into 'userPassword', and thus that anything using different userPassword syntax is invalid. That is wrong for schemes like {CRYPT} with different syntax, and for servers which treat "{scheme}foo" as a cleartext password. Instead you can say: - Generally, syntax "{" scheme "}" scheme-parameters / cleartext pw like someone said. Leave scheme-parameters unspecified. - [The following listed schemes] share [the following more specific scheme-parameters definition]. Note that scheme-parameters need not involve a hashing or a password. In OpenLDAP, {CLEARTEXT} does not hash. I think {SASL} need not encode the password either, just tell SASL where to find auth info. ================ The draft can RECOMMEND that clients avoid needing to know anything about password formats by using the Password Modify operation (RFC 3062) when feasible. Provided the server will then hash the password if it is stored in userPassword, anyway. Which it hopefully will. But RFC 3062 says nothing about hashing in that case. Should it be updated to do so? Use cases at our site for generating {scheme}hash: - Importing user info including userPassword from the SQL user database - which does not keep the cleartext passwords. - Multiple passwords in one entry, typically during the transition when changing the password for an LDAP service DN. MUST userPassword in an object class may be broken, but RFC 1274 defines simpleSecurityObject (AUXILIARY MUST userPassword) anyway. For use with classes like 'account' which lack userPassword. Might be about time to define simpleSecurityObject2 using 'MAY' instead. -- Hallvard