From shawn.emery@oracle.com Tue Jun 1 00:43:39 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BB783A68BD; Tue, 1 Jun 2010 00:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPsAyOw4SVKR; Tue, 1 Jun 2010 00:43:38 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 10B5A3A6824; Tue, 1 Jun 2010 00:43:38 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o517hKZ9017027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Jun 2010 07:43:22 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o517Saon011978; Tue, 1 Jun 2010 07:43:19 GMT Received: from abhmt019.oracle.com by acsmt354.oracle.com with ESMTP id 312300221275378176; Tue, 01 Jun 2010 00:42:56 -0700 Received: from [129.150.48.63] (/129.150.48.63) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Jun 2010 00:42:55 -0700 Message-ID: <4C04B9FE.2090804@oracle.com> Date: Tue, 01 Jun 2010 01:42:54 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: kitten@ietf.org, sasl@ietf.org Content-Type: multipart/mixed; boundary="------------060805080206080204000308" X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090201.4C04BA1C.01BA:SCFMA4539811,ss=1,fgs=0 Subject: [sasl] Kitten Recharter X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 07:43:39 -0000 This is a multi-part message in MIME format. --------------060805080206080204000308 Content-Type: multipart/alternative; boundary="------------040107090009090306070208" --------------040107090009090306070208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Per the recent thead on "MOGGIES Proposed Charter"; I have taken suggestions by kitten/SASL WG members and created recharter text for Kitten (whilst closing SASL). Please let me know if I missed anything. Shawn. Kitten co-chair. -- --------------040107090009090306070208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Per the recent thead on "MOGGIES Proposed Charter"; I have taken suggestions by kitten/SASL WG members and created recharter text for Kitten (whilst closing SASL). Please let me know if I missed anything. Shawn. Kitten co-chair. --
--------------040107090009090306070208-- --------------060805080206080204000308 Content-Type: text/plain; name="kitten-recharter.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kitten-recharter.txt" Kitten (Common Authentication Technology Next Generation) Description of Working Group: The Generic Security Services (GSS) API and Simple Authentication and Security Layer (SASL) provide various applications with a security framework for secure network communication. The purpose of the Common Authentication Technology Next Generation (Kitten) working group (WG) is to develop extensions/improvements to the GSS-API, shepherd specific GSS-API security mechanisms, and provide guidance for any new SASL-related submissions. This working is chartered to specify the following extensions and improvements (draft-yu-kitten-api-wishlist-00) to the GSS-API: * Provide new interfaces for credential management, which include the following: initializing credentials iterating credentials exporting/importing credentials * Specify interface for asynchronous calls. * Define interfaces for better error message reporting. * Provide a more programmer friendly interface for application developers. This WG is also chartered to transition proposed SASL mechanisms as GSS-API mechanisms: * A SASL Mechanism for OpenID draft-lear-ietf-sasl-openid-00 * A SASL Mechanism for SAML draft-wierenga-ietf-sasl-saml-00 The transition from SASL to GSS-API mechanisms will allow a greater set of applications to utilize said mechanisms with SASL implementations that support the use of GSS-API mechanisms in SASL (draft-ietf-sasl-gs2). * Shepard draft-melnikov-digest-to-historic through standards track. This WG should review proposals for new SASL and GSS-API mechanisms. The WG should also review non-mechanism proposals related to SASL and the GSS-API. Deliverables: * GSS-API: initializing credentials [editor: TBD] * GSS-API: iterating credentials [editor: TBD] * GSS-API: exporting/importing credentials [editor: TBD] * GSS-API: specification for asynchronous calls [editor: TBD] * GSS-API: interfaces/improvements for better error message reporting [editor: TBD] * GSS-API: programmer friendly interfaces [editor: TBD] * GSS-API: transition SASL mechanism for OpenID [editor: TBD] * GSS-API: transition SASL mechanism for SAML [editor: TBD] * GSS-API: publish draft-ietf-kitten-gssapi-extensions-iana [editor: Nicolas Williams] * GSS-API: publish draft-ietf-kitten-gssapi-naming-exts [editor: Leif Johansson] * SASL: publish draft-melnikov-digest-to-historic [editor: Alexey Melnikov] Goals and Milestones: June 2010 Submit publish draft-ietf-kitten-gssapi-naming-exts to the IESG as Proposed Standard June 2010 WGLC, again, on draft-ietf-kitten-gssapi-extensions-iana July 2010 Submit draft-ietf-kitten-gssapi-extensions-iana to the IESG as Proposed Standard July 2010 First Meeting TBD Other Listed Work Items --------------060805080206080204000308-- From paul@darkrain42.org Mon Jun 7 14:35:12 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 654E03A687C for ; Mon, 7 Jun 2010 14:35:06 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikShWVeMFL0m for ; Mon, 7 Jun 2010 14:34:47 -0700 (PDT) Received: from mail.darkrain42.org (o-chul.darkrain42.org [IPv6:2001:470:1f05:d58::1]) by core3.amsl.com (Postfix) with ESMTP id 2BDC63A6879 for ; Mon, 7 Jun 2010 14:34:31 -0700 (PDT) Received: from [192.168.0.8] (97-126-71-241.tukw.qwest.net [97.126.71.241]) by mail.darkrain42.org (mail.darkrain42.org) with ESMTPSA id 2A29A8065 for ; Mon, 7 Jun 2010 14:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=darkrain42.org; s=a; t=1275946467; bh=eMALhUK2+WhJWp5HD9fqmO8eGyAVdydXI7zu4/rmC40=; l=2638; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=X5YuWBQtQwDnQGEUFa2G/gBkn5rvirp7+1iSs+l8B4mkZqKc2gGElYiXrDT//fTJ1 agfut7JaVYnXAH5Yef8o7DPB/lrRUXEhl5rpY6YlXGuZJfgIgNubx0bcD9owXSZObE 3PKJvRmebXIZ3wPLZZuXigjEGIuru4ftRJF3OaybV7vsCRW8sIpwXnzwNtf8XvtFKK veodbzE3f0BBdzIKbSWSPIVZDoceWSujxQnsr85g/kbI5L+2rzOSjCWpf3DMyOW/YY FOQIDePtf2UIEbmyOrMC3u297ybOseq/IC6QxrfhXn2w3f5VhGCaypYiFohBE8b2qD EXy6dIbGQp7iA== Message-ID: <4C0D65D8.4010401@darkrain42.org> Date: Mon, 07 Jun 2010 14:34:16 -0700 From: Paul Aurich User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: SASL WG References: <4BCC5BD0.7060100@isode.com> <4BD900E0.1000103@darkrain42.org> In-Reply-To: <4BD900E0.1000103@darkrain42.org> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig8770D70202ADBF231308EBA7" Subject: Re: [sasl] Clarification on the use of e= in SCRAM SASL/GS2 X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 21:35:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8770D70202ADBF231308EBA7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2010-04-28 20:45, Paul Aurich wrote: > I have no problem with the changes, but in looking at the ABNF value of= the > error, I'm confused by the meaning of the > "server-does-support-channel-binding" error: > "server-does-support-channel-binding" / > ; server does not support channel binding > "channel-binding-not-supported" / >=20 > In what case is this used, and are the text value/comment in conflict o= r is > there something I'm missing? (Should the comment come after the > channel-binding-not-supported value, perhaps?) >=20 > Thanks, > ~Paul Since SCRAM is still in AUTH48, I thought I'd bring this up once more. It's a simple case of "do comments bind to the thing above or below them", but, considering that the two errors in question are "hey, I do support channel binding" and "I don't support channel binding", clearing this up would be great. For reference, I think the comment is in the wrong place here (it should appear *after* "channel-binding-not-supported") because the comment comes after the error in question for these two: "extensions-not-supported" / ; unrecognized 'm' value and "invalid-username-encoding" / ; invalid username encoding (invalid UTF-8 or ; SASLprep failed) Thanks, ~Paul --------------enig8770D70202ADBF231308EBA7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJMDWXfAAoJEEkfeuGm+zD3Or0P/2B3sW3TG9vJ7h5Wl0BY/FJR KJrMfDr1rDgGxWoxG5fr709qAvfcJHd7dw1LaeOG+Sqnx9FF6rdw8wnePQFQIXa2 q6F+Kuvu8ZVciH5v6YP98NH2RrX7KjjOu1r4+RC6MnFkZ0yzt6kyoWEv5vzVk92I naA6MeLO5MyIf4Lv0qbWXnmmZyPoRpMYvBiMNk1dbQNww4URkZ7pZv9nfh+Bevjy FDF/BeMpWi7eTqlBIG6+QFDoxmfM7gfP+kTwIUgZdXWsoNff4rEXIv21Loe2mvW8 522UhqOxaCc1qOs4Cx2jpAuHc/8eaL7Tsm9X6jUqV6AbzuknkGAIETI9mHW/fYNu 9IxTRBXnTWmL70IagoZ9HnmS9BOTmkhO16G6K6a9F0YoWBbI52eK3m4Za7hFYu9e EYHMGBrHrX/QZ4d9YON4+YOHObUQqpozvTjQcUjwQ0DiHah5SjAa7iC8zPmIjmN2 RoFESWxhsYKZ6Pc0PbfEj3ldd1vQjbK5KoI5W3JEi3M4/5vmN2QEgLYw8HDj3z+o 2taOXQyCUoEtcBQR3WGPoz+wOyDodgxP8uhF8208RoOSTvco7Ir3YSVCG9QdPCta 0epwk8ef8PxVA9ialiMqoQ8eVQwzxaPo1EZML/gtSPoBOTlX2sqq9D/DfhTyC49z XQpsuXO5OB9AnFy+ty6Z =jIVc -----END PGP SIGNATURE----- --------------enig8770D70202ADBF231308EBA7-- From tmarkmann@googlemail.com Tue Jun 8 12:36:41 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FF993A683E for ; Tue, 8 Jun 2010 12:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUw+NbOCB35A for ; Tue, 8 Jun 2010 12:36:39 -0700 (PDT) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 5CBFE3A67D4 for ; Tue, 8 Jun 2010 12:36:39 -0700 (PDT) Received: by ewy8 with SMTP id 8so1225496ewy.28 for ; Tue, 08 Jun 2010 12:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:content-type:subject :date:message-id:to:mime-version:x-mailer; bh=JCFSdq2w3qfwbJEeqLW86/PLXp7ZJ0BC5wPfROQLW/M=; b=xrDkgpw864gRNHXNnQz1E+CdkMT9l61poO81pVt/rNVtumCiPHkGbp90h0elxKKSL6 8UZ2m5fNo6oPYkiBqodLDGhhFozItWzBw++Xvr20SFaVi3rjKX4ev1QOZVbtbcDc6hc5 lZVVj7D8PWtyBBHIq+ou71HkgMVvocoa5pIZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer; b=lFvxFsaUR+lWT+kuIbGyBx4Eb2p6o/458wF0KZc/dHmvGDHox3WsmgkdFmEk33kVZA Uo/ieTwbCA/3oRUWbDAmm+92lRHFP19rROJNDbd4kECow56TChzPBjOOgWOJ3zXw4kaG y+r8EZtJA0a3/VIHLuosNZYfeKj9Bal9sTlZ0= Received: by 10.213.9.70 with SMTP id k6mr696733ebk.54.1276025796905; Tue, 08 Jun 2010 12:36:36 -0700 (PDT) Received: from [192.168.0.3] (port-11597.pppoe.wtnet.de [84.46.45.122]) by mx.google.com with ESMTPS id 13sm3542500ewy.9.2010.06.08.12.36.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 08 Jun 2010 12:36:35 -0700 (PDT) From: Tobias Markmann Content-Type: multipart/signed; boundary=Apple-Mail-3--781634400; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 8 Jun 2010 21:36:32 +0200 Message-Id: <77312093-F63B-468D-A9DC-144C83FE7207@googlemail.com> To: SASL WG Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [sasl] Importance of exact Authentication Information to ensure reaching design goals X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 19:36:41 -0000 --Apple-Mail-3--781634400 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, would it still be possible to add/change a little text in SCRAM? I think = there should be more emphasis on the fact that if you don't store the = information described as authentication information you'll loose one of = the major design goal, being point 3, "The authentication information = stored in the authentication database is not sufficient by itself to = impersonate the client.". Sure this seems obvious if you read it from = top to end but I've still the impression that the authentication = particulars for the client are described more clearly. Cheers, Tobias -- Tobias Markmann http://ayena.de --Apple-Mail-3--781634400 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO+jCCBxAw ggX4oAMCAQICAwCjdjANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTA5MTAwMzAwMDAwMVoXDTEwMTAwMzE2NDQ1M1owdDEeMBwGA1UEChMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMSkwJwYDVQQDEyBTdGFydENvbSBGcmVlIENlcnRpZmljYXRlIE1lbWJlcjEnMCUG CSqGSIb3DQEJARYYdG1hcmttYW5uQGdvb2dsZW1haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr4aPGo0CfPIkmc2uUhFVfF+8hMAfQjgj5IRZuSU4ieWShKDJPrbhUOpnlcB sy1nxb/Y9YxBx7pSNwBPuGRhB/MH/rrcyq1XAI6YIwA8lLd/hDDazkyPrmLyDsM7diZ7alYgoHfV ZsHdQIlN9yHcx0JlR3VOdE2OT1PMJYxVO9eeJqvC9q7MW4Grh5NKN+J8xERjzZFvKxAdGmZa//79 vK74XfoBJ12uJr5nISwXAy8b4AT22l2mAwYwW0771dRNsMy2QwCESo4rOMZDvtJWq+u+MjATGk/S CjHzfN14jAT/A8kGh/7jtGVrhA25Upo5066708QrB56GTmTV7e8CKwIDAQABo4IDkDCCA4wwCQYD VR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1Ud DgQWBBQkmM+SPFRl5zb2sfZ6v6e6LaPh5jAjBgNVHREEHDAagRh0bWFya21hbm5AZ29vZ2xlbWFp bC5jb20wgagGA1UdIwSBoDCBnYAUU3Ltkpzg2ssBXHx+ljVO8tS4UYKhgYGkfzB9MQswCQYDVQQG EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2Vy dGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHmCAQ0wggFHBgNVHSAEggE+MIIBOjCCATYGCysGAQQBgbU3AQIBMIIBJTAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBvAYIKwYBBQUHAgIwga8wFBYNU3RhcnRD b20gTHRkLjADAgEBGoGWTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2Fs IExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9s aWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1Ud HwRcMFowK6ApoCeGJWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwK6ApoCeG JWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8w OQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9j YTBCBggrBgEFBQcwAoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5j bGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG 9w0BAQUFAAOCAQEAvMMQSYHqL25jNrJvQQGQfOM+I6639wvbjRIWVxuCnCnGqLOgP+eKCYque5Ec J1QegfX2yqeT43wLVqMpWiIF2ph2btKqCArG9MRulVrY7jCvWD+0YUeUV6SH1vO7dmakCZWF1zEi xaDmOEhGhvb54UcxSfiPkia3Y2UX9x4zWMMun+Xo6TXTE/eGspsbQ/OYFqnS9850jedE/Y/4sBAi 76/11vqbUWUSJzqh303FtIi/Qni2hioB7eEEqKA35xXpuZWYDpSYrF+HZMw3RJ0BoM6fkD/dns7+ 5QXWLTreGlg5pcOKyXuqQ/7Q7dr05dlypK4UkmF1M+/2xB39iGvnfTCCB+IwggXKoAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NFoXDTEyMTAyMjIxMDE1 NFowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7 zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8 VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+ jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQO Jebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCA1swggNXMAwGA1UdEwQF MAMBAf8wCwYDVR0PBAQDAgGmMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjCBqAYDVR0j BIGgMIGdgBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIE AjAAMD0GCCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20v c2ZzY2EuY3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNj YS1jcmwuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNV HSAEggFUMIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29t Lm9yZy9pbnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFs IChTdGFydENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rp b24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5 LnBkZjARBglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3 DQEBBQUAA4ICAQCqmuHgW4zOHRv8HcYsMCCgt5Mm/fECts0RKL8p/8cwz/+B/wXPBRQ04KCUfp19 i4tBD91O07IxvgmiIvdPvGJUoQA6ZD635v/Es4xrSbXzOhGpbiToaXKjK9zssyt2mBiT+USHmery 0930Gg2bCKKF5emEhUf9B6VOBSQ3NMLshWmZhWwq406fETWMkVk01+plkr/k62jsLo98663XUqYF BItlqsDPRv+aOCF0Gxh8e6F07y+s68PSDmDt0DimQ4BTYR3ilIKjAFIi3IP/loXBnvmOLpirsYIb cGmLIA/2y3yH6KdzQv7uSasAwloswCa7oZmzleCxvOfTBQm9sP2HmOecwz1RpkNzGXa4sHTiq4ZR Yzo2IoZptvFBzrzQ9ht5CtC757oni6o0DHOhrlHGQEDlr/eqVuAX24kF6QKomzDHm9D2SEmuzxRM xogXNsQLlUZDOJAff/oongNQ/zk4kScLH+q5KFYDrDfXwsOdtrczprlX4qg0uGxWL9NLF/3RRsGr B1FH9w7C4aQ0mHXo2++Eio7bqiwyDrgJtmwNWsQOvu5IxXjSJ4ElOjj0jK3vsQI6HP+nKGjBrYRQ /popq/4v/BfMA8Hcs2rO6MZHQrWlvIVYq/JiZ26eAm3JJZQzD5HkOqkDZsUg4Tnql9Y8sdnE4v7z 6vv08sVf7LZXoTGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwCj djAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMDA2MDgxOTM2MzJaMCMGCSqGSIb3DQEJBDEWBBRSeQ4wAZsoQnggQJ0HaabF9bSepTCBpQYJ KwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwCjdjCBpwYLKoZI hvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAKN2MA0GCSqGSIb3 DQEBAQUABIIBAEBJOgsYOsrC3IEv+7++/o6Y3dXCooxspd2r5CV4nW+CAtp/aLa07ghz6iNaqjo5 fKq0+/h8/1I0GCZaN5Wjvi4lMU9+Sdxg/PCXXQ8YHZ+bZH405V87/Gp2DCVoOWLNhJg+K/jN2YIG psPHnL/LQqGE6Km8OUEe7weDIPrNvZJPlWBfqdtLMgh+EDqw0aO4ErBAic6MB5mcAFT1zyotNynN klH8gD0Zf6qUrt4iBcyijU2pWRps0Df5aFIqCr4IFklqQb2NE+NkCG7LJqR3nF5snabmdTuCvnOX mlh6x9cPlywH87YlStpZh1x6a6nGK7ZduG8xsWv7jwzXCaRoc6gAAAAAAAA= --Apple-Mail-3--781634400-- From Nicolas.Williams@oracle.com Tue Jun 8 12:38:55 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3EB73A67D4 for ; Tue, 8 Jun 2010 12:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NxhUY-AmOEA for ; Tue, 8 Jun 2010 12:38:52 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 7D43E3A659B for ; Tue, 8 Jun 2010 12:38:52 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o58JckqQ028980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jun 2010 19:38:49 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o58GOpau005207; Tue, 8 Jun 2010 19:38:43 GMT Received: from abhmt003.oracle.com by acsmt354.oracle.com with ESMTP id 307599351276025905; Tue, 08 Jun 2010 12:38:25 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Jun 2010 12:38:24 -0700 Date: Tue, 8 Jun 2010 14:38:15 -0500 From: Nicolas Williams To: Tobias Markmann Message-ID: <20100608193815.GN9605@oracle.com> References: <77312093-F63B-468D-A9DC-144C83FE7207@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77312093-F63B-468D-A9DC-144C83FE7207@googlemail.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090208.4C0E9C4A.0186:SCFMA922111,ss=1,fgs=0 Cc: SASL WG Subject: Re: [sasl] Importance of exact Authentication Information to ensure reaching design goals X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 19:38:55 -0000 On Tue, Jun 08, 2010 at 09:36:32PM +0200, Tobias Markmann wrote: > would it still be possible to add/change a little text in SCRAM? I > think there should be more emphasis on the fact that if you don't > store the information described as authentication information you'll > loose one of the major design goal, being point 3, "The authentication > information stored in the authentication database is not sufficient by > itself to impersonate the client.". Sure this seems obvious if you > read it from top to end but I've still the impression that the > authentication particulars for the client are described more clearly. Propose text. We're still in AUTH48. From alexey.melnikov@isode.com Fri Jun 11 10:40:42 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7702B3A67D6; Fri, 11 Jun 2010 10:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xLenSwKlsed; Fri, 11 Jun 2010 10:40:41 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 106F03A6A30; Fri, 11 Jun 2010 10:40:41 -0700 (PDT) Received: from [172.16.2.142] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 11 Jun 2010 18:40:41 +0100 Message-ID: <4C12750D.4030904@isode.com> Date: Fri, 11 Jun 2010 18:40:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Shawn Emery References: <4C04B9FE.2090804@oracle.com> In-Reply-To: <4C04B9FE.2090804@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, sasl@ietf.org Subject: Re: [sasl] Kitten Recharter X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 17:40:42 -0000 Shawn Emery wrote: > Per the recent thead on "MOGGIES Proposed Charter"; I have taken > suggestions by kitten/SASL WG members and created recharter text for > Kitten (whilst closing SASL). Please let me know if I missed anything. > > Shawn. > Kitten co-chair. Hi Sean, Thanks for the updated version. This looks much better. Some additional comments inline. >Kitten (Common Authentication Technology Next Generation) > > >Description of Working Group: > >The Generic Security Services (GSS) API and Simple Authentication and Security >Layer (SASL) provide various applications with a security framework for secure >network communication. The purpose of the Common Authentication Technology >Next Generation (Kitten) working group (WG) is to develop >extensions/improvements to the GSS-API, shepherd specific GSS-API security >mechanisms, and provide guidance for any new SASL-related submissions. > >This working is chartered to specify the following extensions and improvements >(draft-yu-kitten-api-wishlist-00) to the GSS-API: > >* Provide new interfaces for credential management, which include the following: > initializing credentials > iterating credentials > exporting/importing credentials > >* Specify interface for asynchronous calls. > >* Define interfaces for better error message reporting. > >* Provide a more programmer friendly interface for application developers. > > This point is a bit vague. Do we actually need this as an explicit goal? >This WG is also chartered to transition proposed SASL mechanisms as >GSS-API mechanisms: > >* A SASL Mechanism for OpenID > draft-lear-ietf-sasl-openid-00 >* A SASL Mechanism for SAML > draft-wierenga-ietf-sasl-saml-00 > >The transition from SASL to GSS-API mechanisms will allow a greater set of >applications to utilize said mechanisms with SASL implementations that support >the use of GSS-API mechanisms in SASL (draft-ietf-sasl-gs2). > >* Shepard draft-melnikov-digest-to-historic through standards track. > typo: shephard >This WG should review proposals for new SASL and GSS-API mechanisms. The WG >should also review non-mechanism proposals related to SASL and the GSS-API. > I think this is a bit too open-ended for IESG. I would have asked about that if I were asked to review such charter ;-). To be frank, I would delete these 2 sentences, or say the exactly opposite: other proposals would require rechartering. However chairs always have some flexibility in allowing conversations on related topics, as long as this doesn't compromise progress on major deliverables. >Deliverables: > >* GSS-API: initializing credentials >[editor: TBD] > >* GSS-API: iterating credentials >[editor: TBD] > >* GSS-API: exporting/importing credentials >[editor: TBD] > >* GSS-API: specification for asynchronous calls >[editor: TBD] > >* GSS-API: interfaces/improvements for better error message reporting >[editor: TBD] > >* GSS-API: programmer friendly interfaces >[editor: TBD] > >* GSS-API: transition SASL mechanism for OpenID >[editor: TBD] > >* GSS-API: transition SASL mechanism for SAML >[editor: TBD] > >* GSS-API: publish draft-ietf-kitten-gssapi-extensions-iana >[editor: Nicolas Williams] > >* GSS-API: publish draft-ietf-kitten-gssapi-naming-exts >[editor: Leif Johansson] > >* SASL: publish draft-melnikov-digest-to-historic >[editor: Alexey Melnikov] > >Goals and Milestones: > >June 2010 Submit publish draft-ietf-kitten-gssapi-naming-exts to the IESG as Proposed Standard >June 2010 WGLC, again, on draft-ietf-kitten-gssapi-extensions-iana >July 2010 Submit draft-ietf-kitten-gssapi-extensions-iana to the IESG as Proposed Standard >July 2010 First Meeting >TBD Other Listed Work Items > > From jhutz@cmu.edu Fri Jun 11 11:10:45 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388813A6A2F; Fri, 11 Jun 2010 11:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7R0FvvO5q3uM; Fri, 11 Jun 2010 11:10:42 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id EA89C3A6A2D; Fri, 11 Jun 2010 11:10:41 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o5BIAgGX006123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jun 2010 14:10:42 -0400 (EDT) Date: Fri, 11 Jun 2010 14:10:42 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov , Shawn Emery Message-ID: <5531409D439CF3B42925B973@minbar.fac.cs.cmu.edu> In-Reply-To: <1763_1276278048_o5BHelQL016299_4C12750D.4030904@isode.com> References: <4C04B9FE.2090804@oracle.com> <1763_1276278048_o5BHelQL016299_4C12750D.4030904@isode.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, sasl@ietf.org Subject: Re: [sasl] Kitten Recharter X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 18:10:45 -0000 --On Friday, June 11, 2010 06:40:29 PM +0100 Alexey Melnikov wrote: >> * Shepard draft-melnikov-digest-to-historic through standards track. >> > typo: shephard shepherd, with an 'e', please >> This WG should review proposals for new SASL and GSS-API mechanisms. >> The WG should also review non-mechanism proposals related to SASL and >> the GSS-API. >> > I think this is a bit too open-ended for IESG. I would have asked about > that if I were asked to review such charter ;-). > > To be frank, I would delete these 2 sentences, or say the exactly > opposite: other proposals would require rechartering. However chairs > always have some flexibility in allowing conversations on related topics, > as long as this doesn't compromise progress on major deliverables. Not at all. The intent here is not that the WG have an open-ended mandate to take on any and all mechanism work. However, we want to be clear that this is the place to take any such proposals, and that it is in scope for the WG to discuss and review them, and to consider whether it wants to work on them (in which case a charter revision would be needed). -- Jeff From alexey.melnikov@isode.com Fri Jun 11 11:13:16 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6CF93A69A0; Fri, 11 Jun 2010 11:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Av62LmpqIsid; Fri, 11 Jun 2010 11:13:14 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 467173A6A15; Fri, 11 Jun 2010 11:13:14 -0700 (PDT) Received: from [172.16.2.142] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 11 Jun 2010 19:13:16 +0100 Message-ID: <4C127CAE.6010203@isode.com> Date: Fri, 11 Jun 2010 19:13:02 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Jeffrey Hutzelman References: <4C04B9FE.2090804@oracle.com> <1763_1276278048_o5BHelQL016299_4C12750D.4030904@isode.com> <5531409D439CF3B42925B973@minbar.fac.cs.cmu.edu> In-Reply-To: <5531409D439CF3B42925B973@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, sasl@ietf.org Subject: Re: [sasl] Kitten Recharter X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 18:13:16 -0000 Jeffrey Hutzelman wrote: > --On Friday, June 11, 2010 06:40:29 PM +0100 Alexey Melnikov > wrote: > >>> * Shepard draft-melnikov-digest-to-historic through standards track. >> >> typo: shephard > > shepherd, with an 'e', please. Thanks :-) >>> This WG should review proposals for new SASL and GSS-API mechanisms. >>> The WG should also review non-mechanism proposals related to SASL and >>> the GSS-API. >>> >> I think this is a bit too open-ended for IESG. I would have asked about >> that if I were asked to review such charter ;-). >> >> To be frank, I would delete these 2 sentences, or say the exactly >> opposite: other proposals would require rechartering. However chairs >> always have some flexibility in allowing conversations on related >> topics, >> as long as this doesn't compromise progress on major deliverables. > > Not at all. The intent here is not that the WG have an open-ended > mandate to take on any and all mechanism work. However, we want to be > clear that this is the place to take any such proposals, and that it > is in scope for the WG to discuss and review them, and to consider > whether it wants to work on them (in which case a charter revision > would be needed). If that is the intent, then the text is not good enough. It doesn't explicitly says that rechartering would be needed, it seems to imply the opposite. It is also not clear to me what can be described as "non-mechanism proposals related to SASL and the GSS-API". If we are talking about SASL protocol profiles, then we should say that. From jhutz@cmu.edu Fri Jun 11 11:49:42 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5452328C122; Fri, 11 Jun 2010 11:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.624 X-Spam-Level: X-Spam-Status: No, score=-5.624 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3It3rkgN4ovJ; Fri, 11 Jun 2010 11:49:41 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id 4593C28C0F9; Fri, 11 Jun 2010 11:49:41 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o5BIngcq005400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jun 2010 14:49:42 -0400 (EDT) Date: Fri, 11 Jun 2010 14:49:42 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov Message-ID: In-Reply-To: <4C127CAE.6010203@isode.com> References: <4C04B9FE.2090804@oracle.com> <1763_1276278048_o5BHelQL016299_4C12750D.4030904@isode.com> <5531409D439CF3B42925B973@minbar.fac.cs.cmu.edu> <4C127CAE.6010203@isode.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: kitten@ietf.org, sasl@ietf.org Subject: Re: [sasl] Kitten Recharter X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 18:49:42 -0000 --On Friday, June 11, 2010 07:13:02 PM +0100 Alexey Melnikov wrote: > Jeffrey Hutzelman wrote: > >> --On Friday, June 11, 2010 06:40:29 PM +0100 Alexey Melnikov >> wrote: >> >>>> * Shepard draft-melnikov-digest-to-historic through standards track. >>> >>> typo: shephard >> >> shepherd, with an 'e', please. > > Thanks :-) > >>>> This WG should review proposals for new SASL and GSS-API mechanisms. >>>> The WG should also review non-mechanism proposals related to SASL and >>>> the GSS-API. >>>> >>> I think this is a bit too open-ended for IESG. I would have asked about >>> that if I were asked to review such charter ;-). >>> >>> To be frank, I would delete these 2 sentences, or say the exactly >>> opposite: other proposals would require rechartering. However chairs >>> always have some flexibility in allowing conversations on related >>> topics, >>> as long as this doesn't compromise progress on major deliverables. >> >> Not at all. The intent here is not that the WG have an open-ended >> mandate to take on any and all mechanism work. However, we want to be >> clear that this is the place to take any such proposals, and that it >> is in scope for the WG to discuss and review them, and to consider >> whether it wants to work on them (in which case a charter revision >> would be needed). > > If that is the intent, then the text is not good enough. It doesn't > explicitly says that rechartering would be needed, it seems to imply the > opposite. > It is also not clear to me what can be described as "non-mechanism > proposals related to SASL and the GSS-API". If we are talking about SASL > protocol profiles, then we should say that. I don't think it's talking about SASL protocol profiles. It's talking about proposals related to SASL and GSS-API, other than mechanisms. In other words, we're not restricted to considering proposals for new mechanisms; we can also consider proposals to do things like adding mechanism attribute query to GSS-API or adding the PRF or channel binding abstractions to SASL, or whatever else comes along. I do think it should be in scope for the WG to review and provide expert advice on any work which adds SASL or GSS-API support to a new or existing protocol. However, actually _doing_ such work should be explicitly out of scope, as that should happen in the appropriate WG for the application protocol in question. -- Jeff From simon@josefsson.org Thu Jun 17 06:51:04 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8A833A67D3 for ; Thu, 17 Jun 2010 06:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.924 X-Spam-Level: X-Spam-Status: No, score=-0.924 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSKlPTDLzizl for ; Thu, 17 Jun 2010 06:51:03 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 089EE3A68DD for ; Thu, 17 Jun 2010 06:51:00 -0700 (PDT) Received: from mocca (c80-216-29-48.bredband.comhem.se [80.216.29.48]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o5HDovag025210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 17 Jun 2010 15:50:59 +0200 X-Hashcash: 1:22:100617:sasl@ietf.org::388IpG5NDNNP7RZq:CxbX From: Simon Josefsson To: sasl@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Thu, 17 Jun 2010 15:50:54 +0200 Message-ID: <87zkytdayp.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.1 at yxa-v X-Virus-Status: Clean Subject: [sasl] GS2 AUTH48 nits X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 13:51:04 -0000 We are close to get GS2 out of AUTH48 (although still waiting for its dependencies...) but I noticed two things I'd like to fix. Because this is slightly more than editorial (but hopefully not controversial) I wanted to run this by the WG. 1) In section 3 about mechanism names it discuss what an implementation do when it cannot derive the SASL name. It says: If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2 implementation needs some other mechanism to map mechanism Object Identifiers (OIDs) to SASL names internally. In this case, the implementation can only support the mechanisms for which it knows the SASL name. If the GSS_Inquire_SASLname_for_mech call fails, and the GS2 implementation cannot map the OID to a SASL mechanism name using some other means; it cannot use the particular GSS-API mechanism since it does not know its SASL mechanism name. I'd like to change "cannot use" into "MUST NOT use" to make sure implementations never attempts to use such a GSS-API mechanism under its hash-derived mechanism name. OLD: some other means; it cannot use the particular GSS-API mechanism OLD: some other means; it MUST NOT use the particular GSS-API mechanism 2) The introduction section contains: All GS2 plaintext is protected via the use of GSS-API channel binding. This is actually not true anymore, since we discovered that this wasn't possible to implement (see earlier discussions about optional "F,"). I propose to change this into: GS2 plaintext is protected via the use of GSS-API channel binding. However I believe this prompts a security discussion about non-integrity protected parts. I suggest adding this paragraph to the security consideration: Some data that influence the GS2 authentication algorithm is not integrity protected by the GSS-API channel binding mechanism. This includes the SASL mechanism negotiation (which influences channel binding selection) and the initial [gs2-nonstd-flag ","] part of the GS2 header. The former problem is discussed in the core SASL specification generally. GS2 confirms the channel binding selection through the GS2 header, which is integrity protected. The initial part of the GS2 header is not integrity protected but this should not allow attackers to influence the negotiation substantially: it merely allows attackers to remove/add a fixed prefix to the initial context token, and it is assumed that this will be detected by any GSS-API mechanism. /Simon From Nicolas.Williams@oracle.com Thu Jun 17 10:10:27 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067A83A68BF for ; Thu, 17 Jun 2010 10:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPtfi-PFgdHQ for ; Thu, 17 Jun 2010 10:10:25 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 365CC3A68C3 for ; Thu, 17 Jun 2010 10:10:25 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5HHARwA004120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Jun 2010 17:10:28 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5HGrRU5021044; Thu, 17 Jun 2010 17:10:26 GMT Received: from abhmt010.oracle.com by acsmt355.oracle.com with ESMTP id 353240561276794510; Thu, 17 Jun 2010 10:08:30 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Jun 2010 10:08:29 -0700 Date: Thu, 17 Jun 2010 12:08:24 -0500 From: Nicolas Williams To: Simon Josefsson Message-ID: <20100617170824.GE25472@oracle.com> References: <87zkytdayp.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zkytdayp.fsf@mocca.josefsson.org> User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090205.4C1A5704.02A4:SCFMA922111,ss=1,fgs=0 Cc: sasl@ietf.org Subject: Re: [sasl] GS2 AUTH48 nits X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 17:10:27 -0000 On Thu, Jun 17, 2010 at 03:50:54PM +0200, Simon Josefsson wrote: > We are close to get GS2 out of AUTH48 (although still waiting for its > dependencies...) but I noticed two things I'd like to fix. Because this > is slightly more than editorial (but hopefully not controversial) I > wanted to run this by the WG. > > 1) > > In section 3 about mechanism names it discuss what an implementation do > when it cannot derive the SASL name. It says: > > If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2 > implementation needs some other mechanism to map mechanism Object > Identifiers (OIDs) to SASL names internally. In this case, the > implementation can only support the mechanisms for which it knows the > SASL name. If the GSS_Inquire_SASLname_for_mech call fails, and the > GS2 implementation cannot map the OID to a SASL mechanism name using > some other means; it cannot use the particular GSS-API mechanism > since it does not know its SASL mechanism name. > > I'd like to change "cannot use" into "MUST NOT use" to make sure > implementations never attempts to use such a GSS-API mechanism under its > hash-derived mechanism name. ASIDE: GSS_Inquire_SASLname_for_mech() can fail? (The only error code we list that it can return is GSS_S_BAD_MECH, meaning the OID passed in is not supported by the mechglue.) > OLD: > some other means; it cannot use the particular GSS-API mechanism > > OLD: > some other means; it MUST NOT use the particular GSS-API mechanism I don't think the use of indicative versu normative is a big deal here. But the punctuation in this sentence needs help. I'd remove the comma and replace the semi-colon with ", then" and clarify the antecedent of "it". How about: OLD: If the GSS_Inquire_SASLname_for_mech call fails, and the GS2 implementation cannot map the OID to a SASL mechanism name using some other means; it cannot use the particular GSS-API mechanism since it does not know its SASL mechanism name. NEW: If GSS_Inquire_SASLname_for_mech() fails and the GS2 implementation cannot map the OID to a SASL mechanism name via some other means, then the GS2 implementation cannot use the given GSS-API mechanism. It could be simplified further: If the GS2 implementation uses a GSS-API implementation and GSS_Inquire_SASLname_for_mech() fails then the GS2 implementation cannot use the given GSS-API mechanism as a SASL mechanism. Also, presumably many GS2 implementations will apply GSS_Inquire_SASLname_for_mech() to the OIDs indicated by GSS_Indicate_mechs() and then support all the resulting SASL mechanism names. We should have some advice for them, no? After all, not every GSS-API mechanism is suitable for use in SASL via GS2 (must have channel binding, must have mutual auth). But, whatever. It's getting late and I don't care for perfection :) > 2) > > The introduction section contains: > > All GS2 plaintext is protected via the use of GSS-API channel > binding. > > This is actually not true anymore, since we discovered that this wasn't > possible to implement (see earlier discussions about optional "F,"). The "F," is a compression technique for _GSS-API_ plaintext that is not explicitly protected by the GSS-API (the mechanism can and should, but doesn't have to). As such I'd not worry about "F," going unprotected. > I propose to change this into: > > GS2 plaintext is protected via the use of GSS-API channel binding. Removing "All" doesn't really help. I'd rather say that "all" or "most" "security-relevant" GS2 plaintext is protected. I propose instead: OLD: All GS2 plaintext is protected via the use of GSS-API channel binding. NEW: Most GS2 plaintext is protected via the use of GSS-API channel binding, with the exception of the "gs2-nonstd-flag" flag. GS2 does not protect any plaintext exchanged outside GS2, such as SASL mechanism negotiation plaintext, nor application messages following authentication. But using channel binding to a secure channel over which all SASL and application plaintext is sent will cause all that plaintext to be authenticated. > However I believe this prompts a security discussion about non-integrity > protected parts. I suggest adding this paragraph to the security > consideration: > > Some data that influence the GS2 authentication > algorithm is not integrity protected by the GSS-API > channel binding mechanism. This includes the SASL > mechanism negotiation (which influences channel binding > selection) and the initial [gs2-nonstd-flag ","] part of > the GS2 header. The former problem is discussed in the I don't think we need to restate the SASL security considerations regarding mechanism negotiation, but if we must then we should do so in the fourth paragraph of the security considerations section, since that one talks about this problem. In any case, the SASL mechanism negotiation does not constitute "GS2 plaintext". > core SASL specification generally. GS2 confirms the > channel binding selection through the GS2 header, which > is integrity protected. The initial part of the GS2 > header is not integrity protected but this should not > allow attackers to influence the negotiation > substantially: it merely allows attackers to remove/add > a fixed prefix to the initial context token, and it is > assumed that this will be detected by any GSS-API > mechanism. I'd rather not touch the security considerations section, except for some typos (see below), but if we must then I propose this change instead of yours: OLD: Use of channel binding will also protect the SASL mechanism negotiation -- if there is no MITM, then the external secure channel will have protected the SASL mechanism negotiation. NEW: Use of channel binding will also protect the SASL mechanism negotiation -- if there is no MITM, then the external secure channel will have protected the SASL mechanism negotiation. When channel binding is not used there is no protection for the SASL mechanism negotiation; section 5 explains how to protect against some downgrade attacks, and, as stated earlier, it is strongly RECOMMENDED that channel binding be used. Typos: GS2 does not protect against downgrade attacks of channel binding types. The complexities of negotiation a channel binding type, and ^^^^^^^^^^^ negotiating handling downgrade attacks in that negotiation, was intentionally ^^^ were left out of scope for this document. Also, "the complexities .. were .. left out of scope" is an odd phrase. This would be much better: Negotiation of channel binding type was intentionally left out of scope for this document. Nico -- From shawn.emery@oracle.com Thu Jun 17 17:44:42 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1C93A659B; Thu, 17 Jun 2010 17:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTXJGWYVgiyr; Thu, 17 Jun 2010 17:44:41 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 1E9393A67A2; Thu, 17 Jun 2010 17:44:41 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5I0iij4028219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Jun 2010 00:44:45 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5HKKKk0014638; Fri, 18 Jun 2010 00:44:43 GMT Received: from abhmt020.oracle.com by acsmt354.oracle.com with ESMTP id 354165281276821849; Thu, 17 Jun 2010 17:44:09 -0700 Received: from [129.150.48.15] (/129.150.48.15) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Jun 2010 17:44:09 -0700 Message-ID: <4C1AC158.8090009@oracle.com> Date: Thu, 17 Jun 2010 18:44:08 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <4C04B9FE.2090804@oracle.com> <4C12750D.4030904@isode.com> In-Reply-To: <4C12750D.4030904@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090204.4C1AC17E.0001:SCFMA922111,ss=1,fgs=0 Cc: kitten@ietf.org, sasl@ietf.org Subject: Re: [sasl] Kitten Recharter X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2010 00:44:42 -0000 On 06/11/10 11:40 AM, Alexey Melnikov wrote: > Shawn Emery wrote: > >> Per the recent thead on "MOGGIES Proposed Charter"; I have taken >> suggestions by kitten/SASL WG members and created recharter text for >> Kitten (whilst closing SASL). Please let me know if I missed anything. >> >> Shawn. >> Kitten co-chair. > > Hi Sean, > Thanks for the updated version. This looks much better. Thanks. > Some additional comments inline. > >> Kitten (Common Authentication Technology Next Generation) >> >> >> >> * Provide a more programmer friendly interface for application >> developers. >> >> > This point is a bit vague. Do we actually need this as an explicit goal? Do you want more details on how this will be accomplished? For example: * Provide a more programmer friendly GSS-API for application developers. This could include reducing the number of interface parameters, eliminating those whose values' are commonly used. >> This WG should review proposals for new SASL and GSS-API mechanisms. >> The WG >> should also review non-mechanism proposals related to SASL and the >> GSS-API. >> > I think this is a bit too open-ended for IESG. I would have asked > about that if I were asked to review such charter ;-). > > To be frank, I would delete these 2 sentences, or say the exactly > opposite: other proposals would require rechartering. However chairs > always have some flexibility in allowing conversations on related > topics, as long as this doesn't compromise progress on major deliverables. I've read the follow-up thread between you and Hutzelman, and concluded that the following clarification should be made: This WG should review proposals for new SASL and GSS-API mechanisms. The WG should also review non-mechanism proposals related to SASL and the GSS-API. However, work that adds SASL or GSS-API support in application protocols should be handled by the application's WG. Shawn. -- From jhutz@cmu.edu Thu Jun 17 18:22:38 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993093A6877; Thu, 17 Jun 2010 18:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.612 X-Spam-Level: X-Spam-Status: No, score=-4.612 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BxxxcmGfYNs; Thu, 17 Jun 2010 18:22:35 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 47CE23A63CB; Thu, 17 Jun 2010 18:22:35 -0700 (PDT) Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o5I1McV1024508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jun 2010 21:22:39 -0400 (EDT) Date: Thu, 17 Jun 2010 21:22:38 -0400 From: Jeffrey Hutzelman To: Shawn Emery , Alexey Melnikov Message-ID: <685B4ECEA1A018F865B69F0D@lysithea.fac.cs.cmu.edu> In-Reply-To: <31094_1276821891_o5I0io9L012053_4C1AC158.8090009@oracle.com> References: <4C04B9FE.2090804@oracle.com> <4C12750D.4030904@isode.com> <31094_1276821891_o5I0io9L012053_4C1AC158.8090009@oracle.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, sasl@ietf.org Subject: Re: [sasl] Kitten Recharter X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2010 01:22:39 -0000 --On Thursday, June 17, 2010 06:44:08 PM -0600 Shawn Emery wrote: > On 06/11/10 11:40 AM, Alexey Melnikov wrote: >> Shawn Emery wrote: >> >>> Per the recent thead on "MOGGIES Proposed Charter"; I have taken >>> suggestions by kitten/SASL WG members and created recharter text for >>> Kitten (whilst closing SASL). Please let me know if I missed anything. >>> >>> Shawn. >>> Kitten co-chair. >> >> Hi Sean, >> Thanks for the updated version. This looks much better. > > Thanks. > >> Some additional comments inline. >> >>> Kitten (Common Authentication Technology Next Generation) >>> >>> >>> >>> * Provide a more programmer friendly interface for application >>> developers. >>> >>> >> This point is a bit vague. Do we actually need this as an explicit goal? > > Do you want more details on how this will be accomplished? For example: > > * Provide a more programmer friendly GSS-API for application developers. > This could include reducing the number of interface parameters, > eliminating those whose values' are commonly used. > > >>> This WG should review proposals for new SASL and GSS-API mechanisms. >>> The WG >>> should also review non-mechanism proposals related to SASL and the >>> GSS-API. >>> >> I think this is a bit too open-ended for IESG. I would have asked >> about that if I were asked to review such charter ;-). >> >> To be frank, I would delete these 2 sentences, or say the exactly >> opposite: other proposals would require rechartering. However chairs >> always have some flexibility in allowing conversations on related >> topics, as long as this doesn't compromise progress on major >> deliverables. > > I've read the follow-up thread between you and Hutzelman, and concluded > that the following clarification should be made: > > This WG should review proposals for new SASL and GSS-API mechanisms. The > WG should also review non-mechanism proposals related to SASL and the > GSS-API. However, work that adds SASL or GSS-API support in application > protocols should be handled by the application's WG. To the first sentence, add "but may take on work on such mechanisms only through a revision of this charter". Then I think you'll have captured the gist of the discussion. -- Jeff From alexey.melnikov@isode.com Fri Jun 18 01:47:48 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DBAF3A6A11; Fri, 18 Jun 2010 01:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=0.939, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO6Q3+au9yyj; Fri, 18 Jun 2010 01:47:46 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 4B8D13A6A13; Fri, 18 Jun 2010 01:47:46 -0700 (PDT) Received: from [188.28.32.193] (188.28.32.193.threembb.co.uk [188.28.32.193]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 18 Jun 2010 09:47:35 +0100 Message-ID: <4C1B32A2.4090109@isode.com> Date: Fri, 18 Jun 2010 09:47:30 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Jeffrey Hutzelman References: <4C04B9FE.2090804@oracle.com> <4C12750D.4030904@isode.com> <31094_1276821891_o5I0io9L012053_4C1AC158.8090009@oracle.com> <685B4ECEA1A018F865B69F0D@lysithea.fac.cs.cmu.edu> In-Reply-To: <685B4ECEA1A018F865B69F0D@lysithea.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, sasl@ietf.org Subject: Re: [sasl] Kitten Recharter X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2010 08:47:48 -0000 Jeffrey Hutzelman wrote: > --On Thursday, June 17, 2010 06:44:08 PM -0600 Shawn Emery > wrote: > >> On 06/11/10 11:40 AM, Alexey Melnikov wrote: >> >>> Shawn Emery wrote: >> [...] >>>> >>>> >>>> * Provide a more programmer friendly interface for application >>>> developers. >>> >>> This point is a bit vague. Do we actually need this as an explicit >>> goal? >> >> Do you want more details on how this will be accomplished? For example: >> >> * Provide a more programmer friendly GSS-API for application developers. >> This could include reducing the number of interface parameters, >> eliminating those whose values' are commonly used. > *not* commonly used? Yes, something like that. >> >> >>>> This WG should review proposals for new SASL and GSS-API mechanisms. >>>> The WG >>>> should also review non-mechanism proposals related to SASL and the >>>> GSS-API. >>> >>> I think this is a bit too open-ended for IESG. I would have asked >>> about that if I were asked to review such charter ;-). >>> >>> To be frank, I would delete these 2 sentences, or say the exactly >>> opposite: other proposals would require rechartering. However chairs >>> always have some flexibility in allowing conversations on related >>> topics, as long as this doesn't compromise progress on major >>> deliverables. >> >> I've read the follow-up thread between you and Hutzelman, and concluded >> that the following clarification should be made: >> >> This WG should review proposals for new SASL and GSS-API mechanisms. >> The >> WG should also review non-mechanism proposals related to SASL and the >> GSS-API. However, work that adds SASL or GSS-API support in application >> protocols should be handled by the application's WG. > > To the first sentence, add "but may take on work on such mechanisms > only through a revision of this charter". Then I think you'll have > captured the gist of the discussion. +1. From simon@josefsson.org Fri Jun 18 03:01:05 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B14363A6A04 for ; Fri, 18 Jun 2010 03:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.223 X-Spam-Level: X-Spam-Status: No, score=-1.223 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2aQT5W2axI4 for ; Fri, 18 Jun 2010 03:01:04 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 518013A683C for ; Fri, 18 Jun 2010 03:01:01 -0700 (PDT) Received: from mocca (c80-216-29-48.bredband.comhem.se [80.216.29.48]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o5IA0pvN000426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 18 Jun 2010 12:00:53 +0200 From: Simon Josefsson To: Nicolas Williams References: <87zkytdayp.fsf@mocca.josefsson.org> <20100617170824.GE25472@oracle.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100618:sasl@ietf.org::sxbUyGTJpjOxDJny:41pE X-Hashcash: 1:22:100618:nicolas.williams@oracle.com::g6O3Za/tq/bFfcBn:ARnH Date: Fri, 18 Jun 2010 12:00:47 +0200 In-Reply-To: <20100617170824.GE25472@oracle.com> (Nicolas Williams's message of "Thu, 17 Jun 2010 12:08:24 -0500") Message-ID: <87k4pw8xtc.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.1 at yxa-v X-Virus-Status: Clean Cc: sasl@ietf.org Subject: Re: [sasl] GS2 AUTH48 nits X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2010 10:01:05 -0000 Nicolas Williams writes: > On Thu, Jun 17, 2010 at 03:50:54PM +0200, Simon Josefsson wrote: >> We are close to get GS2 out of AUTH48 (although still waiting for its >> dependencies...) but I noticed two things I'd like to fix. Because this >> is slightly more than editorial (but hopefully not controversial) I >> wanted to run this by the WG. >> >> 1) >> >> In section 3 about mechanism names it discuss what an implementation do >> when it cannot derive the SASL name. It says: >> >> If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2 >> implementation needs some other mechanism to map mechanism Object >> Identifiers (OIDs) to SASL names internally. In this case, the >> implementation can only support the mechanisms for which it knows the >> SASL name. If the GSS_Inquire_SASLname_for_mech call fails, and the >> GS2 implementation cannot map the OID to a SASL mechanism name using >> some other means; it cannot use the particular GSS-API mechanism >> since it does not know its SASL mechanism name. >> >> I'd like to change "cannot use" into "MUST NOT use" to make sure >> implementations never attempts to use such a GSS-API mechanism under its >> hash-derived mechanism name. > > ASIDE: GSS_Inquire_SASLname_for_mech() can fail? (The only error code > we list that it can return is GSS_S_BAD_MECH, meaning the OID passed in > is not supported by the mechglue.) I suppose that is a problem with the document, isn't it? Looking at RFC 2743, it seems all GSS-API interfaces are documented to return GSS_S_FAILURE: o GSS_S_FAILURE indicates that the requested operation failed for reasons unspecified at the GSS-API level. Each language binding may define other error situations, so failures are always _possible_. For example, C defines calling errors, other bindings may throw exceptions. Looking at GNU GSS, it will return GSS_S_FAILURE on out of memory conditions. I suggest we add GSS_S_FAILURE error codes to the new GSS-API functions. Do you agree? I can propose something separately. >> OLD: >> some other means; it cannot use the particular GSS-API mechanism >> >> OLD: >> some other means; it MUST NOT use the particular GSS-API mechanism > > I don't think the use of indicative versu normative is a big deal here. > But the punctuation in this sentence needs help. I'd remove the comma > and replace the semi-colon with ", then" and clarify the antecedent of > "it". > > How about: > > OLD: > If the GSS_Inquire_SASLname_for_mech call fails, and the > GS2 implementation cannot map the OID to a SASL mechanism name using > some other means; it cannot use the particular GSS-API mechanism > since it does not know its SASL mechanism name. > > NEW: > If GSS_Inquire_SASLname_for_mech() fails and the GS2 > implementation cannot map the OID to a SASL mechanism name via some > other means, then the GS2 implementation cannot use the given GSS-API > mechanism. That is just an editorial change, right? I don't see any significant implementation difference between those two paragraphs. I do see an implementation difference if the "cannot" is replaced by "MUST NOT": it becomes a testable condition on which to validate implementations. Thus, I would like the see something like this: NEW: If GSS_Inquire_SASLname_for_mech() fails and the GS2 implementation cannot map the OID to a SASL mechanism name via some other means, then the GS2 implementation MUST NOT use the given GSS-API mechanism. Otherwise we'll end up in the trap that GS2 implementations break the "cannot" because, well, the "cannot" is simply not true: implementations CAN use the GSS-API mechanisms in GS2 under its hash-generated name (or some random name). The document does not say that applications shouldn't use the hash-generated name in this situation. It is implied, but a "MUST NOT" would make this clear. > It could be simplified further: > > If the GS2 implementation uses a GSS-API implementation > and GSS_Inquire_SASLname_for_mech() fails then the GS2 implementation > cannot use the given GSS-API mechanism as a SASL mechanism. No -- unfortunately widely used GSS-API libraries still don't have the GSS_Inquire_SASLname_for_mech function, and it will take a long time unless it is widely available. GNU SASL maps the KRB5 OID to "GS2-KRB5" internally when used with an pre-GS2 GSS-API library, and that has to be permitted. The GSS-API interface is just a helper function, it is not required for GS2 to work. > Also, presumably many GS2 implementations will apply > GSS_Inquire_SASLname_for_mech() to the OIDs indicated by > GSS_Indicate_mechs() and then support all the resulting SASL mechanism > names. We should have some advice for them, no? After all, not every > GSS-API mechanism is suitable for use in SASL via GS2 (must have channel > binding, must have mutual auth). But, whatever. It's getting late and > I don't care for perfection :) I noticed that too, but I didn't want to bring it up. :-) The problem is mitigated since the mutual_req flag MUST be set, and that it is checked to be true after the context has established. I don't know how to query mechanisms whether they support channel bindings? GNU SASL does not support auto-discovery of unknown GSS-API mechanisms, intentionally and for several reasons. I suspect some reasons will be shared by other implementations as well, thus I'm not sure even the majority of implementations will support auto-discovery. If this turns out to be a problem in practice, it can be solved by later clarifications. >> 2) >> >> The introduction section contains: >> >> All GS2 plaintext is protected via the use of GSS-API channel >> binding. >> >> This is actually not true anymore, since we discovered that this wasn't >> possible to implement (see earlier discussions about optional "F,"). > > The "F," is a compression technique for _GSS-API_ plaintext that is not > explicitly protected by the GSS-API (the mechanism can and should, but > doesn't have to). As such I'd not worry about "F," going unprotected. Me neither, but it would be useful to talk about it in the document. An attacker can insert and remove the "F," without being detected (unless channel binding is used). We need to be sure that this only leads to a Denial-Of-Service situation, and not anything worse. >> I propose to change this into: >> >> GS2 plaintext is protected via the use of GSS-API channel binding. > > Removing "All" doesn't really help. I'd rather say that "all" or "most" > "security-relevant" GS2 plaintext is protected. > > I propose instead: > > OLD: > All GS2 plaintext is protected via the use of GSS-API channel > binding. > > NEW: > Most GS2 plaintext is protected via the use of GSS-API channel > binding, with the exception of the "gs2-nonstd-flag" flag. > > GS2 does not protect any plaintext exchanged outside GS2, such as > SASL mechanism negotiation plaintext, nor application messages > following authentication. But using channel binding to a secure > channel over which all SASL and application plaintext is sent will > cause all that plaintext to be authenticated. This text is in the introduction section... but your paragraph is quite informative! I suggest: OLD: GS2 is designed to be as simple as possible. It adds to GSS-API security context token exchanges only the bare minimum to support SASL semantics and negotiation of use of channel binding. Specifically, GS2 adds a small header (a few bytes plus the length of the client-requested SASL authorization identity) to the initial GSS- API context token and to the application channel binding data. GS2 uses SASL mechanism negotiation to implement channel binding negotiation. All GS2 plaintext is protected via the use of GSS-API channel binding. Additionally, to simplify the implementation of GS2 mechanisms for implementors who will not implement a GSS-API framework, we compress the initial security context token header required by [RFC2743], Section 3.1. NEW: GS2 is designed to be as simple as possible. It adds to GSS-API security context token exchanges only the bare minimum to support SASL semantics and negotiation of use of channel binding. Specifically, GS2 adds a small header (a few bytes plus the length of the client-requested SASL authorization identity) to the initial GSS- API context token and to the application channel binding data. GS2 uses SASL mechanism negotiation to implement channel binding negotiation. Security-relevant GS2 plaintext is protected via the use of GSS-API channel binding. Additionally, to simplify the implementation of GS2 mechanisms for implementors who will not implement a GSS-API framework, we compress the initial security context token header required by [RFC2743], Section 3.1. GS2 does not protect any plaintext exchanged outside GS2, such as SASL mechanism negotiation plaintext, nor application messages following authentication. But using channel binding to a secure channel over which all SASL and application plaintext is sent will cause all that plaintext to be authenticated. I.e., I've changed "All" to "Security-relevant", and added your last paragraph. >> However I believe this prompts a security discussion about non-integrity >> protected parts. I suggest adding this paragraph to the security >> consideration: >> >> Some data that influence the GS2 authentication >> algorithm is not integrity protected by the GSS-API >> channel binding mechanism. This includes the SASL >> mechanism negotiation (which influences channel binding >> selection) and the initial [gs2-nonstd-flag ","] part of >> the GS2 header. The former problem is discussed in the > > I don't think we need to restate the SASL security considerations > regarding mechanism negotiation, but if we must then we should do so in > the fourth paragraph of the security considerations section, since that > one talks about this problem. > > In any case, the SASL mechanism negotiation does not constitute "GS2 > plaintext". > >> core SASL specification generally. GS2 confirms the >> channel binding selection through the GS2 header, which >> is integrity protected. The initial part of the GS2 >> header is not integrity protected but this should not >> allow attackers to influence the negotiation >> substantially: it merely allows attackers to remove/add >> a fixed prefix to the initial context token, and it is >> assumed that this will be detected by any GSS-API >> mechanism. > > I'd rather not touch the security considerations section, except for > some typos (see below), but if we must then I propose this change > instead of yours: > > OLD: > Use of channel binding will also protect the SASL mechanism > negotiation -- if there is no MITM, then the external secure channel > will have protected the SASL mechanism negotiation. > > NEW: > Use of channel binding will also protect the SASL mechanism > negotiation -- if there is no MITM, then the external secure channel > will have protected the SASL mechanism negotiation. When channel > binding is not used there is no protection for the SASL mechanism > negotiation; section 5 explains how to protect against some downgrade > attacks, and, as stated earlier, it is strongly RECOMMENDED that > channel binding be used. This doesn't address what an attacker can do by inserting/removing "F," though. However maybe this is just too much detail, and it does not really affect implementations (it only improves security analysis of the document). So I'll withdraw my suggestion. Let's not bias the folks who do security analysis of the protocol and assert that this is secure. ;) > Typos: > > GS2 does not protect against downgrade attacks of channel binding > types. The complexities of negotiation a channel binding type, and > ^^^^^^^^^^^ > negotiating > handling downgrade attacks in that negotiation, was intentionally > ^^^ > were > left out of scope for this document. > > Also, "the complexities .. were .. left out of scope" is an odd phrase. > This would be much better: > > Negotiation of channel binding type was intentionally left out of > scope for this document. I agree. I've made this change in my local copy, which means I'll notice it when doing final AUTH48 checks. /Simon From alexey.melnikov@isode.com Sat Jun 19 13:45:44 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6142E3A68F8 for ; Sat, 19 Jun 2010 13:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Qql2TP73u28 for ; Sat, 19 Jun 2010 13:45:41 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 662CC3A68F2 for ; Sat, 19 Jun 2010 13:45:39 -0700 (PDT) Received: from [92.40.172.205] (92.40.172.205.sub.mbb.three.co.uk [92.40.172.205]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 19 Jun 2010 21:45:43 +0100 Message-ID: <4C1D2C42.6080509@isode.com> Date: Sat, 19 Jun 2010 21:44:50 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Simon Josefsson References: <87zkytdayp.fsf@mocca.josefsson.org> <20100617170824.GE25472@oracle.com> <87k4pw8xtc.fsf@mocca.josefsson.org> In-Reply-To: <87k4pw8xtc.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sasl@ietf.org Subject: Re: [sasl] GS2 AUTH48 nits X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 20:45:44 -0000 Simon Josefsson wrote: >Nicolas Williams writes: > > >>On Thu, Jun 17, 2010 at 03:50:54PM +0200, Simon Josefsson wrote: >> >>>We are close to get GS2 out of AUTH48 (although still waiting for its >>>dependencies...) but I noticed two things I'd like to fix. Because this >>>is slightly more than editorial (but hopefully not controversial) I >>>wanted to run this by the WG. >>> >>>1) >>> >>>In section 3 about mechanism names it discuss what an implementation do >>>when it cannot derive the SASL name. It says: >>> >>> If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2 >>> implementation needs some other mechanism to map mechanism Object >>> Identifiers (OIDs) to SASL names internally. In this case, the >>> implementation can only support the mechanisms for which it knows the >>> SASL name. If the GSS_Inquire_SASLname_for_mech call fails, and the >>> GS2 implementation cannot map the OID to a SASL mechanism name using >>> some other means; it cannot use the particular GSS-API mechanism >>> since it does not know its SASL mechanism name. >>> >>>I'd like to change "cannot use" into "MUST NOT use" to make sure >>>implementations never attempts to use such a GSS-API mechanism under its >>>hash-derived mechanism name. >>> >>> >>ASIDE: GSS_Inquire_SASLname_for_mech() can fail? (The only error code >>we list that it can return is GSS_S_BAD_MECH, meaning the OID passed in >>is not supported by the mechglue.) >> > >I suppose that is a problem with the document, isn't it? > >Looking at RFC 2743, it seems all GSS-API interfaces are documented to >return GSS_S_FAILURE: > > o GSS_S_FAILURE indicates that the requested operation failed for > reasons unspecified at the GSS-API level. > >Each language binding may define other error situations, so failures are >always _possible_. For example, C defines calling errors, other >bindings may throw exceptions. > >Looking at GNU GSS, it will return GSS_S_FAILURE on out of memory >conditions. > >I suggest we add GSS_S_FAILURE error codes to the new GSS-API functions. >Do you agree? I can propose something separately. > > Sure. >>>OLD: >>> some other means; it cannot use the particular GSS-API mechanism >>> >>>OLD: >>> some other means; it MUST NOT use the particular GSS-API mechanism >>> >>> >>I don't think the use of indicative versu normative is a big deal here. >>But the punctuation in this sentence needs help. I'd remove the comma >>and replace the semi-colon with ", then" and clarify the antecedent of >>"it". >> >>How about: >> >>OLD: >> If the GSS_Inquire_SASLname_for_mech call fails, and the >> GS2 implementation cannot map the OID to a SASL mechanism name using >> some other means; it cannot use the particular GSS-API mechanism >> since it does not know its SASL mechanism name. >> >>NEW: >> If GSS_Inquire_SASLname_for_mech() fails and the GS2 >> implementation cannot map the OID to a SASL mechanism name via some >> other means, then the GS2 implementation cannot use the given GSS-API >> mechanism. >> >> > >That is just an editorial change, right? I don't see any significant >implementation difference between those two paragraphs. > >I do see an implementation difference if the "cannot" is replaced by >"MUST NOT": it becomes a testable condition on which to validate >implementations. > >Thus, I would like the see something like this: > >NEW: > If GSS_Inquire_SASLname_for_mech() fails and the GS2 > implementation cannot map the OID to a SASL mechanism name via some > other means, then the GS2 implementation MUST NOT use the given GSS-API > mechanism. > >Otherwise we'll end up in the trap that GS2 implementations break the >"cannot" because, well, the "cannot" is simply not true: implementations >CAN use the GSS-API mechanisms in GS2 under its hash-generated name (or >some random name). The document does not say that applications >shouldn't use the hash-generated name in this situation. It is implied, >but a "MUST NOT" would make this clear. > > I am happy with your proposed text. >>It could be simplified further: >> >> If the GS2 implementation uses a GSS-API implementation >> and GSS_Inquire_SASLname_for_mech() fails then the GS2 implementation >> cannot use the given GSS-API mechanism as a SASL mechanism. >> >> > >No -- unfortunately widely used GSS-API libraries still don't have the >GSS_Inquire_SASLname_for_mech function, and it will take a long time >unless it is widely available. > >GNU SASL maps the KRB5 OID to "GS2-KRB5" internally when used with an >pre-GS2 GSS-API library, and that has to be permitted. The GSS-API >interface is just a helper function, it is not required for GS2 to work. > > Agreed. [...] >>>I propose to change this into: >>> >>> GS2 plaintext is protected via the use of GSS-API channel binding. >>> >>> >>Removing "All" doesn't really help. I'd rather say that "all" or "most" >>"security-relevant" GS2 plaintext is protected. >> >>I propose instead: >> >>OLD: >> All GS2 plaintext is protected via the use of GSS-API channel >> binding. >> >>NEW: >> Most GS2 plaintext is protected via the use of GSS-API channel >> binding, with the exception of the "gs2-nonstd-flag" flag. >> >> GS2 does not protect any plaintext exchanged outside GS2, such as >> SASL mechanism negotiation plaintext, nor application messages >> following authentication. But using channel binding to a secure >> channel over which all SASL and application plaintext is sent will >> cause all that plaintext to be authenticated. >> >> > >This text is in the introduction section... but your paragraph is quite >informative! I suggest: > >OLD: > GS2 is designed to be as simple as possible. It adds to GSS-API > security context token exchanges only the bare minimum to support > SASL semantics and negotiation of use of channel binding. > Specifically, GS2 adds a small header (a few bytes plus the length of > the client-requested SASL authorization identity) to the initial GSS- > API context token and to the application channel binding data. GS2 > uses SASL mechanism negotiation to implement channel binding > negotiation. All GS2 plaintext is protected via the use of GSS-API > channel binding. Additionally, to simplify the implementation of GS2 > mechanisms for implementors who will not implement a GSS-API > framework, we compress the initial security context token header > required by [RFC2743], Section 3.1. > >NEW: > GS2 is designed to be as simple as possible. It adds to GSS-API > security context token exchanges only the bare minimum to support > SASL semantics and negotiation of use of channel binding. > Specifically, GS2 adds a small header (a few bytes plus the length of > the client-requested SASL authorization identity) to the initial GSS- > API context token and to the application channel binding data. GS2 > uses SASL mechanism negotiation to implement channel binding > negotiation. Security-relevant GS2 plaintext is protected via the > use of GSS-API channel binding. Additionally, to simplify the > implementation of GS2 mechanisms for implementors who will not > implement a GSS-API framework, we compress the initial security > context token header required by [RFC2743], Section 3.1. > > GS2 does not protect any plaintext exchanged outside GS2, such as > SASL mechanism negotiation plaintext, nor application messages > following authentication. But using channel binding to a secure > channel over which all SASL and application plaintext is sent will > cause all that plaintext to be authenticated. > >I.e., I've changed "All" to "Security-relevant", and added your last >paragraph. > Works for me. From simon@josefsson.org Mon Jun 21 02:18:39 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F8653A6A42 for ; Mon, 21 Jun 2010 02:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[AWL=-0.761, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WfFnLy-AT1V for ; Mon, 21 Jun 2010 02:18:25 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 316D03A6839 for ; Mon, 21 Jun 2010 02:18:19 -0700 (PDT) Received: from mocca (c80-216-29-48.bredband.comhem.se [80.216.29.48]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o5L9IHoC016169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 21 Jun 2010 11:18:20 +0200 From: Simon Josefsson To: sasl@ietf.org References: <87zkytdayp.fsf@mocca.josefsson.org> <20100617170824.GE25472@oracle.com> <87k4pw8xtc.fsf@mocca.josefsson.org> <4C1D2C42.6080509@isode.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100621:sasl@ietf.org::K1vRDfnl72aUmtks:7R8g X-Hashcash: 1:22:100621:alexey.melnikov@isode.com::MW5C+9ZBixRTiAcC:BlOS Date: Mon, 21 Jun 2010 11:18:12 +0200 In-Reply-To: <4C1D2C42.6080509@isode.com> (Alexey Melnikov's message of "Sat, 19 Jun 2010 21:44:50 +0100") Message-ID: <877hlszquj.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.1 at yxa-v X-Virus-Status: Clean Subject: Re: [sasl] GS2 AUTH48 nits X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 09:18:39 -0000 Summarizing, this is what I propose we send to the RFC editor: OLD: negotiation. All GS2 plaintext is protected via the use of GSS-API NEW: negotiation. Security-relevant GS2 plaintext is protected via the use of GSS-API (And re-flow the paragraph.) ADD at the end of section 1: GS2 does not protect any plaintext exchanged outside GS2, such as SASL mechanism negotiation plaintext, nor application messages following authentication. But using channel binding to a secure channel over which all SASL and application plaintext is sent will cause all that plaintext to be authenticated. OLD: SASL name. If the GSS_Inquire_SASLname_for_mech call fails, and the GS2 implementation cannot map the OID to a SASL mechanism name using some other means; it cannot use the particular GSS-API mechanism since it does not know its SASL mechanism name. NEW: SASL name. If GSS_Inquire_SASLname_for_mech() fails and the GS2 implementation cannot map the OID to a SASL mechanism name via some other means, then the GS2 implementation MUST NOT use the given GSS- API mechanism. OLD: o GSS_S_BAD_MECH indicates that a desired_mech was unsupported by the GSS-API implementation. NEW: o GSS_S_BAD_MECH indicates that a desired_mech was unsupported by the GSS-API implementation. o GSS_S_FAILURE indicates that the operation failed for reasons unspecified at the GSS-API level. ADD, section 10.1 after the first paragraph: As mentioned in [RFC2744], routines may return GSS_S_FAILURE, indicating an implementation-specific or mechanism-specific error condition, further details of which are reported via the minor_status parameter. OLD: o GSS_S_BAD_MECH indicates that no supported GSS-API mechanism had the indicated sasl_mech_name. NEW: o GSS_S_BAD_MECH indicates that no supported GSS-API mechanism had the indicated sasl_mech_name. o GSS_S_FAILURE indicates that the operation failed for reasons unspecified at the GSS-API level. ADD, section 11.1 after the first paragraph: As mentioned in [RFC2744], routines may return GSS_S_FAILURE, indicating an implementation-specific or mechanism-specific error condition, further details of which are reported via the minor_status parameter. OLD: types. The complexities of negotiation a channel binding type, and handling downgrade attacks in that negotiation, was intentionally left out of scope for this document. NEW: types. Negotiation of channel binding type was intentionally left out of scope for this document. /Simon From jehan.marmottard@gmail.com Tue Jun 22 01:05:32 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF23C3A6959 for ; Tue, 22 Jun 2010 01:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.115 X-Spam-Level: X-Spam-Status: No, score=0.115 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cD6oYDLoI8Pi for ; Tue, 22 Jun 2010 01:05:31 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 9D6D23A6813 for ; Tue, 22 Jun 2010 01:05:31 -0700 (PDT) Received: by iwn9 with SMTP id 9so1441277iwn.31 for ; Tue, 22 Jun 2010 01:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=1Nq0hi7VRnoMWPZdqYPF5fLgWpIjB5Y+deCmC8Mrhk4=; b=X12CedZYocvefTpqCASHnocWuEpUm6n4oyw4UIkSeRM/H5/c8lNGymRz59NvY9FYnM kxzHfS5dk1RIFbVSVL9pWpNPByuYn7hq24LfkHd+LfjowG6Qdj9bGvxDqb4pMmhmWyzQ U6zPfE43b5ppNuEkyY1gfvHE0pfalwREOs4/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=iOW077UQbsQ+uWY2ng1XtVGSr2aAUdQfSmWkMaee74sr7VB9GSw+ATzcoP220DAMQo nrE8rhuZFru1CX+WKdWnZ3hF2YN5NN0qZxldYYr8a17vy+KLxh5HkA35pnHrBHZ1ET7S jJBRVq6WBtLQT1FjEBYG78xxz1wLnTVDpqoTY= MIME-Version: 1.0 Received: by 10.231.207.225 with SMTP id fz33mr6300339ibb.173.1277193936251; Tue, 22 Jun 2010 01:05:36 -0700 (PDT) Received: by 10.231.35.137 with HTTP; Tue, 22 Jun 2010 01:05:36 -0700 (PDT) Date: Tue, 22 Jun 2010 17:05:36 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: sasl@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [sasl] draft-ietf-sasl-scram-11: why don't include the authentication identity in the stored key? X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 08:05:33 -0000 Hello, I am reading the SCRAM draft for an implementation and had a remark. The SCRAM's design motivations states this: =AB The server does not gain the ability to impersonate the client to other servers (with an exception for server-authorized proxies), unless such other servers allow SCRAM authentication and use the same salt and iteration count for the user. =BB But if the username was included in the StoredKey algorithm (for instance instead of salting the password only, you could salt [authentication identity + UTF8NUL + password]), noone having the stored key (whether the server itself or someone having gained access to it on the user's computer for instance) could use it to access any service other than the one it was stored for, EVEN IF this other service has the same salt and iteration count by some extraordinary chance, unless the same authentication identity is also used on both service (which might be improbable, though not impossible, as such identity often include a service domain). Isn't it better for security (though I agree that the chances of having same salt and iteration count are weak, here they would be even weaker)? Moreover in my opinion, associating the username/authentication identity and the password seems a nicer design (by including them both into the Stored key). Am I missing something? Thanks. Jehan From alexey.melnikov@isode.com Tue Jun 22 02:06:57 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7530F3A6925 for ; Tue, 22 Jun 2010 02:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[AWL=-1.041, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njtzcQmzrJ5H for ; Tue, 22 Jun 2010 02:06:56 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 51AAC3A6875 for ; Tue, 22 Jun 2010 02:06:56 -0700 (PDT) Received: from [172.16.2.159] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 22 Jun 2010 10:07:02 +0100 Message-ID: <4C207D29.4030600@isode.com> Date: Tue, 22 Jun 2010 10:06:49 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: =?ISO-8859-1?Q?Jehan_Pag=E8s?= References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: sasl@ietf.org Subject: Re: [sasl] draft-ietf-sasl-scram-11: why don't include the authentication identity in the stored key? X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 09:06:57 -0000 Jehan Pag=E8s wrote: >Hello, > =20 > Hi Jehan, >I am reading the SCRAM draft for an implementation and had a remark. >The SCRAM's design motivations states this: > >=AB >The server does not gain the ability to impersonate the client to > other servers (with an exception for server-authorized proxies), > unless such other servers allow SCRAM authentication and use the > same salt and iteration count for the user. >=BB > >But if the username was included in the StoredKey algorithm (for >instance instead of salting the password only, you could salt >[authentication identity + UTF8NUL + password]), noone having the >stored key (whether the server itself or someone having gained access >to it on the user's computer for instance) could use it to access any >service other than the one it was stored for, EVEN IF this other >service has the same salt and iteration count by some extraordinary >chance, unless the same authentication identity is also used on both >service (which might be improbable, though not impossible, as such >identity often include a service domain). > >Isn't it better for security (though I agree that the chances of >having same salt and iteration count are weak, here they would be even >weaker)? Moreover in my opinion, associating the >username/authentication identity and the password seems a nicer design >(by including them both into the Stored key). > =20 > I think you are right about security aspect of this. What you suggest=20 was done for DIGEST-MD5. The problem with that is that any change to the=20 authentication identity invalidates the hash containing it, so sysadmins=20 can't rename the user without also resetting the corresponding password.=20 Authentication identity changes is a sufficiently important problem for=20 big enterprise and university deployments, so it was decided that it was=20 more important to make sysadmin job easier than the security aspect. From jehan.marmottard@gmail.com Tue Jun 22 04:19:38 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E40A3A68F0 for ; Tue, 22 Jun 2010 04:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.138 X-Spam-Level: X-Spam-Status: No, score=0.138 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wk3K6j8HLUn for ; Tue, 22 Jun 2010 04:19:34 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 680203A693A for ; Tue, 22 Jun 2010 04:19:23 -0700 (PDT) Received: by iwn9 with SMTP id 9so1581589iwn.31 for ; Tue, 22 Jun 2010 04:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=QOP9riKG1BDvgn6BYr7ljk1tKXqpzNOSYiMzRVIpCsY=; b=ItWvvYV/qJHBDsvl1APfpzqLFur02inZ6aQmycs5GOVDgkPB0dGYadAQ0RLD0L0nSQ Urgti+cH4WLtXQ02Hje1y5kpMtqrFGHbotaxgfvKQ6FqoZogkh7fKcf0HwPdghzkfu1W qDkXugIxWvgx0Ojg5dm2tWVzX9K7mYSQBJCIE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=tG+YyGs/JErif3u4OOzt+3gbL5WWCnGKL4FPx+K7iFmyBMQk+LvJcX5hxo2PCTEkMI BS97xndTcqZu0/vfCQHrmpleieu2GKw12GRskp+7lA8Ghvqlzm6nVW5CxpSBWVWNYJo4 8CJmM6anchI3Vj6E1ihgd+DDX2jXJTfY2QKMg= MIME-Version: 1.0 Received: by 10.231.160.205 with SMTP id o13mr6601441ibx.111.1277205568165; Tue, 22 Jun 2010 04:19:28 -0700 (PDT) Received: by 10.231.35.137 with HTTP; Tue, 22 Jun 2010 04:19:28 -0700 (PDT) In-Reply-To: <4C207D29.4030600@isode.com> References: <4C207D29.4030600@isode.com> Date: Tue, 22 Jun 2010 20:19:28 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: Alexey Melnikov , sasl@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [sasl] draft-ietf-sasl-scram-11: why don't include the authentication identity in the stored key? X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 11:19:38 -0000 Hi, 2010/6/22 Alexey Melnikov : > Jehan Pag=E8s wrote: >> But if the username was included in the StoredKey algorithm (for >> instance instead of salting the password only, you could salt >> [authentication identity + UTF8NUL + password]), noone having the >> stored key (whether the server itself or someone having gained access >> to it on the user's computer for instance) could use it to access any >> service other than the one it was stored for, EVEN IF this other >> service has the same salt and iteration count by some extraordinary >> chance, unless the same authentication identity is also used on both >> service (which might be improbable, though not impossible, as such >> identity often include a service domain). >> >> Isn't it better for security (though I agree that the chances of >> having same salt and iteration count are weak, here they would be even >> weaker)? Moreover in my opinion, associating the >> username/authentication identity and the password seems a nicer design >> (by including them both into the Stored key). >> > > I think you are right about security aspect of this. What you suggest was > done for DIGEST-MD5. The problem with that is that any change to the > authentication identity invalidates the hash containing it, so sysadmins > can't rename the user without also resetting the corresponding password. > Authentication identity changes is a sufficiently important problem for b= ig > enterprise and university deployments, so it was decided that it was more > important to make sysadmin job easier than the security aspect. > I understand the argument. So it seems this "issue" has indeed been already thought of. Is it so common to massively change authentication identities in a running system? Because considering that many users use the same password everywhere, here this stored key really makes me think of an universal key which, once acquired, enter any system whatever the login name or the service is (no authentication identity, no realm in the stored key), like some ssh key without a password (so once obtained, such ssh key enables a malicious user to enter any remote computer the actual user has the right to enter). Of course the salt/iteration count makes this issue less problematic, but it is still a weakness in my opinion. And as an afterthought, if the authentication id is changed, couldn't we imagine there could be some challenge where the user could still authenticate using the old stored key (so holding the old authentication id) until he resets with a new password (which can be the same or a different, anyway the system won't make the difference as this new password will be associated with a new auth id) once authenticated. This way the reset is handled by the user without much hassle (less than a server-side reset which would imply something like an email sent with the new authentication id and some randomly temporary generated password, then the user has to use it to reconfigure his client): it is transparent for the user which does not change his configuration, and this one would be automatically changed by the system which just pop-ups a query to set a new password (without needing to type again the old one as the authentication is still handled by the old stored key at first). In fact it might even be easier for the user than the current system, as one does not have to manually find where to change one's authentication id (the system does it for him). I hope I am clear, otherwise I could write down some client-server exchange example. Thanks. Jehan From simon@josefsson.org Tue Jun 22 04:25:42 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9975E3A69A3 for ; Tue, 22 Jun 2010 04:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.562 X-Spam-Level: X-Spam-Status: No, score=-0.562 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6ebi1eD+hUX for ; Tue, 22 Jun 2010 04:25:41 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 6A9813A69B0 for ; Tue, 22 Jun 2010 04:25:40 -0700 (PDT) Received: from mocca (c80-216-29-48.bredband.comhem.se [80.216.29.48]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o5MBPYvW012866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 22 Jun 2010 13:25:36 +0200 From: Simon Josefsson To: Jehan =?iso-8859-1?Q?Pag=E8s?= References: <4C207D29.4030600@isode.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100622:alexey.melnikov@isode.com::r18uhThFD6DDuODy:74A X-Hashcash: 1:22:100622:sasl@ietf.org::0agbLw+jc9g+5zGr:60vZ X-Hashcash: 1:22:100622:jehan.marmottard@gmail.com::PtttkKcg4W9Joh5O:FocW Date: Tue, 22 Jun 2010 13:25:27 +0200 In-Reply-To: ("Jehan =?iso-8859-1?Q?Pag=E8s=22's?= message of "Tue, 22 Jun 2010 20:19:28 +0900") Message-ID: <87d3vjnwbc.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.1 at yxa-v X-Virus-Status: Clean Cc: Alexey Melnikov , sasl@ietf.org Subject: Re: [sasl] draft-ietf-sasl-scram-11: why don't include the authentication identity in the stored key? X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 11:25:42 -0000 Jehan Pagès writes: > Hi, > > 2010/6/22 Alexey Melnikov : >> Jehan Pagès wrote: >>> But if the username was included in the StoredKey algorithm (for >>> instance instead of salting the password only, you could salt >>> [authentication identity + UTF8NUL + password]), noone having the >>> stored key (whether the server itself or someone having gained access >>> to it on the user's computer for instance) could use it to access any >>> service other than the one it was stored for, EVEN IF this other >>> service has the same salt and iteration count by some extraordinary >>> chance, unless the same authentication identity is also used on both >>> service (which might be improbable, though not impossible, as such >>> identity often include a service domain). >>> >>> Isn't it better for security (though I agree that the chances of >>> having same salt and iteration count are weak, here they would be even >>> weaker)? Moreover in my opinion, associating the >>> username/authentication identity and the password seems a nicer design >>> (by including them both into the Stored key). >>> >> >> I think you are right about security aspect of this. What you suggest was >> done for DIGEST-MD5. The problem with that is that any change to the >> authentication identity invalidates the hash containing it, so sysadmins >> can't rename the user without also resetting the corresponding password. >> Authentication identity changes is a sufficiently important problem for big >> enterprise and university deployments, so it was decided that it was more >> important to make sysadmin job easier than the security aspect. >> > > I understand the argument. So it seems this "issue" has indeed been > already thought of. Is it so common to massively change authentication > identities in a running system? Yes. I've designed a proprietary implementation which also hashed the username in the server-side hashed key, and deployment has been a pain because administrators do want the ability to move "password-hashes" between usernames. I agree with you that allowing this weakens the security somewhat, but practical matters appears to be more important. I don't view it as a significant security problem. > Because considering that many users use the same password everywhere, > here this stored key really makes me think of an universal key which, > once acquired, enter any system whatever the login name or the service > is (no authentication identity, no realm in the stored key), like some > ssh key without a password (so once obtained, such ssh key enables a > malicious user to enter any remote computer the actual user has the > right to enter). > Of course the salt/iteration count makes this issue less problematic, > but it is still a weakness in my opinion. If salt is not chosen randomly by each system, there is definitely a risk. However, this is not how we want things to be deployed, and I don't think it is how it is being deployed either? Time will tell. /Simon