Certificate= s do not authenticate the user. They authenticate a device. Placing a certi= ficate on my laptop is a close enough approximation to authenticating *me*,= but then I can't use the same certificate on my home computer, my phone, o= r the computer at some Internet cafe or hotel business center. Passwords, o= n the other hand, are with me wherever I go, and can be used with any devic= e.
A possible solution to the first problem would be to issue multi= ple certificates for use in phone, laptop and desktop. But this makes the m= anagement of all these certificates even more complicated, and increases th= e attack surface.
While some places of business, governments and mi= litaries are willing to spend the money and effort required to provision ce= rtificates for all employees, I don't see companies doing it for customers.= It's never a good idea to bet that something is too big for Google to do, = but I can't imagine them issuing client certificates to all gmail users. Ev= en banks, with real money at stake don't do it, because the support costs w= ould exceed the losses to phishing.
Issuing certificates does not s= olve the problem with Internet cafes. It makes no sense for me to install a= browser certificate on some random computer.

But don't take my word for it. Certificates are so inconvenient, that= people would rather use some two-factor authentication solution, where you= type in a password, and then get a one-time code on either a fob or throug= h an SMS message to your phone, which is what Marsh's company does.

= --_000_1D87D84645C840ECA0B996D61E5F6E65checkpointcom_-- From yaronf.ietf@gmail.com Mon Dec 13 07:31:32 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A940F28C113; Mon, 13 Dec 2010 07:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 oZ8HbcaePJoN; Mon, 13 Dec 2010 07:31:29 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 9A8C328C111; Mon, 13 Dec 2010 07:31:28 -0800 (PST) Received: by wyf23 with SMTP id 23so6133663wyf.31 for ; Mon, 13 Dec 2010 07:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+0szgrNyk3mkmUDxf309oDZ+9GRtr8meNZqDA8AcMUE=; b=dNDusxC6geA5feEhxkQO/3IBIf77RSA4FBQR+bRQEH5tRXO/8PbfYInvGtfM9K8trB hcCmyCPLhLZDyJghltMS9GriRS04fRXtgKCYQbBqKzCt67nUbMaoehetoJAzO/+z7NgW Qd/tH93nfYIo2etamhq1o40Uf5iY0/vfVQCus= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ordqzJOVIbEfXFOsrikEoukznWeWMJCAiKTavCcDclq3YG2b4+ifhCv+/xIbEbrVvF bUpQvvk84xgm+pBbhP2bOCrwpM3LeQDpzqpCaAtJBKdvymqaMMv5wGqUxNRmsyHZ+S/T Mco8vjpjuS7KD/s07YacFrp4iBmzd1JkDQZMU= Received: by 10.227.155.138 with SMTP id s10mr1735853wbw.61.1292254386127; Mon, 13 Dec 2010 07:33:06 -0800 (PST) Received: from [10.0.0.1] (bzq-79-176-46-32.red.bezeqint.net [79.176.46.32]) by mx.google.com with ESMTPS id m10sm4489129wbc.16.2010.12.13.07.32.56 (version=SSLv3 cipher=RC4-MD5); Mon, 13 Dec 2010 07:33:04 -0800 (PST) Message-ID: <4D063CA5.8060907@gmail.com> Date: Mon, 13 Dec 2010 17:32:53 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Yoav Nir References: <4D02AF81.6000907@stpeter.im>

<78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D056D83.2020704@extendedsubset.com> <4D062CA2.8040402@gmail.com> <1D87D846-45C8-40EC-A0B9-96D61E5F6E65@checkpoint.com> In-Reply-To: <1D87D846-45C8-40EC-A0B9-96D61E5F6E65@checkpoint.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: websec , Marsh Ray , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [http-auth] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 16:26:23 -0000 On 13/12/10 15:29, Yoav Nir wrote: > * A possible solution to the first problem would be to issue > multiple certificates for use in phone, laptop and desktop. But > this makes the management of all these certificates even more > complicated, and increases the attack surface. Just a random thought. What if there were a standard way for web server apps to bind together different client public keys? E.g. start at home, with TLS mutual auth somehow, then go to the standard "bind new device" button which returns a shortish URL that the user can cut'n'paste to a 2nd device, also using TLS mutual auth, but with the key pair from that 2nd device. Then the server could associate a set of client public keys with the same account. (The URL could probably also be made only usable on that server as well via some server-side symmetric crypto maybe.) Probably has holes galore, (and/or was tried a decade ago;-) but at least the browsers could work as-is. Well, as-is if you assume people had a way to generate and manage key pairs easily in their various browsers. Regardless of the above, I think that if there were a usable way to do TLS mutual auth that was unencumbered and worked well, (including tackling portability), that'd be great, and even if the probability of failing is high, trying for that is maybe worth a shot. S. From stpeter@stpeter.im Mon Dec 13 09:54:09 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D6A28C0E9 for ; Mon, 13 Dec 2010 09:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.781 X-Spam-Level: X-Spam-Status: No, score=-102.781 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 l5MjvPkL0LmE for ; Mon, 13 Dec 2010 09:54:08 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7CEFA28C0DF for ; Mon, 13 Dec 2010 09:54:08 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AC9AB400F6 for ; Mon, 13 Dec 2010 11:08:05 -0700 (MST) Message-ID: <4D065E24.20302@stpeter.im> Date: Mon, 13 Dec 2010 10:55:48 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: saag@ietf.org X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060704030700090403090703" Subject: [saag] HTTP auth discussions X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 17:54:09 -0000 This is a cryptographically signed message in MIME format. --------------ms060704030700090403090703 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Folks, if you're interested in the topic of HTTP auth, please don't copy SAAG on your messages but instead join the http-auth list: https://www.ietf.org/mailman/listinfo/http-auth Sorry about the noise! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060704030700090403090703 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIx MzE3NTU0OFowIwYJKoZIhvcNAQkEMRYEFO1mbbbMbEF96LgJTlwpqqiqZD1HMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQA4bV3hql0F1Viy7aPgsnwTGfleJHJBmT2rPKz3LoFeKff1eZVYG4O8msUm 7wplz/b6jdXHA91o7SKZj1chmFaodJsUg2NcPL3fbZCDRu97wrOEySWDVUb+RK+7W5ttwNWv hpgJpUbRFLN6mSpxLYgOXKBQIJm1lABmf7zyJvkOV7szkSZYWPvq6FvrZnq0E8QdncQzK02W 6b+xnoe7agLKDua78lA1N8R615FtYbgixj1DwuKsWQoLG5rBiK//wysCNhIg/SMsDeRJE0F+ I6XT+vyFFFW78QVjm0uDKQA8valLsh7XGGRrquK6zcmkV+A4BfRk5WhFYvCBQytfu8kYAAAA AAAA --------------ms060704030700090403090703-- From rbarnes@bbn.com Mon Dec 13 12:16:59 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1D7F28C116; Mon, 13 Dec 2010 12:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 zTdtTJuy9Va1; Mon, 13 Dec 2010 12:16:59 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 01F7E28C0EB; Mon, 13 Dec 2010 12:16:59 -0800 (PST) Received: from ros-dhcp192-1-51-22.bbn.com ([192.1.51.22]:64933) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PSEqx-000PO3-CZ; Mon, 13 Dec 2010 15:18:35 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4D06498B.4070900@cs.tcd.ie> Date: Mon, 13 Dec 2010 15:18:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D02AF81.6000907@stpeter.im>

<78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D056D83.2020704@extendedsubset.com> <4D062CA2.8040402@gmail.com> <1D87D846-45C8-40EC-A0B9-96D61E5F6E65@checkpoint.com> <4D06498B.4070900@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1082) Cc: websec , Marsh Ray , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , "saag@ietf.org" Subject: Re: [saag] [http-auth] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 20:17:00 -0000 Actually, sounds like it might be a handy usage of OAuth. The whole = point of that protocol is to delegate user authorizations. This is just = the case where the user is delegating his entire set of authorizations = to another instance of himself. --Richard On Dec 13, 2010, at 11:27 AM, Stephen Farrell wrote: >=20 >=20 > On 13/12/10 15:29, Yoav Nir wrote: >=20 >> * A possible solution to the first problem would be to issue >> multiple certificates for use in phone, laptop and desktop. But >> this makes the management of all these certificates even more >> complicated, and increases the attack surface. >=20 > Just a random thought. What if there were a standard way for web = server > apps to bind together different client public keys? E.g. start at = home, > with TLS mutual auth somehow, then go to the standard "bind new = device" > button which returns a shortish URL that the user can cut'n'paste to > a 2nd device, also using TLS mutual auth, but with the key pair from > that 2nd device. Then the server could associate a set of client = public > keys with the same account. (The URL could probably also be made only > usable on that server as well via some server-side symmetric crypto > maybe.) >=20 > Probably has holes galore, (and/or was tried a decade ago;-) but at > least the browsers could work as-is. Well, as-is if you assume people > had a way to generate and manage key pairs easily in their various > browsers. >=20 > Regardless of the above, I think that if there were a usable way to > do TLS mutual auth that was unencumbered and worked well, (including > tackling portability), that'd be great, and even if the probability > of failing is high, trying for that is maybe worth a shot. >=20 > S. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From mnot@mnot.net Fri Dec 10 15:04:36 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EDF328C171; Fri, 10 Dec 2010 15:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.583 X-Spam-Level: X-Spam-Status: No, score=-104.583 tagged_above=-999 required=5 tests=[AWL=-1.984, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 O9qujG0fX4XH; Fri, 10 Dec 2010 15:04:35 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 9199D28C170; Fri, 10 Dec 2010 15:04:34 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.2.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B455722E1EB; Fri, 10 Dec 2010 18:06:03 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4D02AF81.6000907@stpeter.im> Date: Sat, 11 Dec 2010 10:06:00 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <52E9BD81-E64B-47DA-83FC-C820B15D8B18@mnot.net> References: <4D02AF81.6000907@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Thu, 16 Dec 2010 08:07:26 -0800 Cc: "apps-discuss@ietf.org" , websec@ietf.org, "kitten@ietf.org" , http-auth@ietf.org, saag@ietf.org, "ietf-http-wg@w3.org Group" Subject: Re: [saag] [apps-discuss] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 23:04:36 -0000 There was a very well-attended and wide-ranging bar BoF in Vancouver, = and lots of background discussion (/noise). My impression at that point was that the use cases that people wanted to = put into scope were so diverse, and the requirements so exacting, that = it was a non-starter.=20 That may still be the case, and I think that without a concrete target, = starting the discussion again will ultimately just waste a lot of = engineer hours*. Having said that -- since we now have OAuth shaving off some of those = use cases, it may be that a purely browsing-focused authentication = mechanism might be able to get traction, provided we can get browser = vendors on board (naturally). I'd expect them to instigate this, = however. Cheers, * Waste, of course, is subjective. A cynical person would think that the = opportunity cost of having a bunch of standards people working on = something non-productive could, in the end, be a useful diversion. = However, I'm not that person, because I'm not thinking it, I'm saying = it. But I digress. On 11/12/2010, at 9:53 AM, Peter Saint-Andre wrote: > Is it time to start thinking about next-generation authentication > technologies for HTTP? >=20 > We all know that BASIC and DIGEST are ancient and crufty and lacking > many features and security properties we might want, but there hasn't > been much discussion about more modern approaches. Here are a few = things > I've found: >=20 > 1. Way back in 2001, Keith Burdis wrote an I-D about upgrading to SASL > within HTTP: http://tools.ietf.org/id/draft-burdis-http-sasl-00.txt >=20 > 2. In 2007, Robert Sayre put together a few slides on the topic: > http://people.mozilla.com/~sayrer/2007/auth.html >=20 > 3. Yutaka Oiwa and his colleagues have been working on a protocol for > mutual auth: http://tools.ietf.org/html/draft-oiwa-http-mutualauth-08 >=20 > Other than that, I'm not aware of much activity. What have I missed? > Does it make sense to perhaps hold an exploratory BoF at the next IETF > meeting (Prague, March 2011) to get people thinking about this topic? >=20 > If you're interested, please discuss on the http-auth@ietf.org list: >=20 > https://www.ietf.org/mailman/listinfo/http-auth >=20 > Thanks! >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From marsh@extendedsubset.com Fri Dec 10 15:52:59 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C52628C16B; Fri, 10 Dec 2010 15:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 3T0nlJOeG43h; Fri, 10 Dec 2010 15:52:58 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 6FEB928C13D; Fri, 10 Dec 2010 15:52:58 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PRCnG-0007jy-Mx; Fri, 10 Dec 2010 23:54:30 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id BC33060C7; Fri, 10 Dec 2010 23:54:28 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/98GPaWAVDLHrWGRfLI2yC8jrjm0RWGOw= Message-ID: <4D02BDB3.7060801@extendedsubset.com> Date: Fri, 10 Dec 2010 17:54:27 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Peter Saint-Andre References: <4D02AF81.6000907@stpeter.im> In-Reply-To: <4D02AF81.6000907@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 16 Dec 2010 08:07:26 -0800 Cc: "apps-discuss@ietf.org" , websec@ietf.org, "kitten@ietf.org" , http-auth@ietf.org, saag@ietf.org, "ietf-http-wg@w3.org Group" Subject: Re: [saag] [websec] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 23:52:59 -0000 On 12/10/2010 04:53 PM, Peter Saint-Andre wrote: > Is it time to start thinking about next-generation authentication > technologies for HTTP? No? :-) IMHO, authentication just doesn't belong at the HTTP layer. HTTP is inherently bad at being stateful. Stateless interfaces can be fantastic, but it doesn't support the "login session" concept that most people have in mind when they talk about authentication. Unless you're properly using TLS, you have no reason to believe that the byte you just received is from the same party as the previous byte you received. So under those circumstances, what exactly are you authenticating, and to whom? I use a lot of web sites and none of them do authentication via HTTP. Every single one of them expects a username/password via HTTP(s) POST variables and returns a cookie of varying duration. But what could we possibly do for a stateless, unMACed protocol like HTTP, except integrate and bind it better with a lower layer providing real integrity? I think what the world needs are ways for web apps (literally, the Ruby code) to easily work with the strongly-authenticated identities which are supported at the TLS layer. TLS already supports "sessions" and "client authentication", but for whatever reasons they're not being utilized. We should make using those facilities as easy for web developers as doing cookie-based logins. Improving the "authentication" for a protocol lacking basic message integrity would just be giving a false sense of security. It's like improving the login authentication for telnet or FTP sessions. But I do think there are lots of improvements waiting to be made in the right directions. - Marsh From ynir@checkpoint.com Sat Dec 11 15:08:58 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB2943A6CC6; Sat, 11 Dec 2010 15:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.31 X-Spam-Level: X-Spam-Status: No, score=-9.31 tagged_above=-999 required=5 tests=[AWL=1.289, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 bNfpvjyZj955; Sat, 11 Dec 2010 15:08:57 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id E78FF3A6CC3; Sat, 11 Dec 2010 15:08:53 -0800 (PST) X-CheckPoint: {4D0404E3-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBBNAFio001572; Sun, 12 Dec 2010 01:10:15 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 12 Dec 2010 01:10:15 +0200 From: Yoav Nir To: Paul Hoffman , websec , Peter Saint-Andre Date: Sun, 12 Dec 2010 01:10:11 +0200 Thread-Topic: [saag] HTTP authentication: the next generation Thread-Index: AcuZiJEeUrzxMlnURUmsuTqhB7a9Ww== Message-ID: References: <4D02AF81.6000907@stpeter.im> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 16 Dec 2010 08:07:26 -0800 Cc: "apps-discuss@ietf.org" , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [saag] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 23:08:59 -0000 On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: > At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >> Other than that, I'm not aware of much activity. What have I missed? >=20 > TLS client certificates. TLS client certificates work, but as we've learned both with the web and wi= th IPsec clients, people would much rather not use them. A few IETFs ago (C= hicago?), a bunch of us tried to push the idea of TLS with EAP authenticati= on. http://tools.ietf.org/html/draft-nir-tls-eap At the time, the TLS working group (and an AD) told us that this would cont= radict the applicability statement of EAP, so no, you cannot use EAP for an= ything other than network access.=20 Now we have the abfab working group, so I don't think this still holds. Also, I agree with Marsh, that authentication is not enough, and you need t= he rest of TLS anyway. So yes, I think that it is time to resurrect HTTP authentication. Yoav From lukeh@padl.com Sat Dec 11 17:37:09 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C7E13A6CE2; Sat, 11 Dec 2010 17:37:09 -0800 (PST) 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 qTb5wLZeH8eU; Sat, 11 Dec 2010 17:37:05 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 55CB128C0CE; Sat, 11 Dec 2010 17:37:04 -0800 (PST) Received: by us.padl.com with ESMTP id oBC1c2GK007734; Sat, 11 Dec 2010 20:38:07 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Sun, 12 Dec 2010 12:38:07 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> References: <4D02AF81.6000907@stpeter.im>

To: Yoav Nir X-Mailer: Apple Mail (2.1082) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 X-Mailman-Approved-At: Thu, 16 Dec 2010 08:07:26 -0800 Cc: "apps-discuss@ietf.org" , websec , Paul Hoffman , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 01:37:09 -0000 On 12/12/2010, at 10:10 AM, Yoav Nir wrote: >=20 > On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: >=20 >> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >>> Other than that, I'm not aware of much activity. What have I missed? >>=20 >> TLS client certificates. >=20 > TLS client certificates work, but as we've learned both with the web = and with IPsec clients, people would much rather not use them. A few = IETFs ago (Chicago?), a bunch of us tried to push the idea of TLS with = EAP authentication. >=20 > http://tools.ietf.org/html/draft-nir-tls-eap Does draft-williams-tls-app-sasl-opt-04.txt + abfab get you the moral = equivalent? -- Luke= From yaronf.ietf@gmail.com Sat Dec 11 23:28:12 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B39C3A6D75; Sat, 11 Dec 2010 23:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.954 X-Spam-Level: X-Spam-Status: No, score=-102.954 tagged_above=-999 required=5 tests=[AWL=0.645, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 fiBC6E4S4MDM; Sat, 11 Dec 2010 23:28:11 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 418D43A69D5; Sat, 11 Dec 2010 23:28:10 -0800 (PST) Received: by wwa36 with SMTP id 36so5250627wwa.13 for ; Sat, 11 Dec 2010 23:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=4BFdEbuS5k7moTIeZMWDbonXYuvqM+FTh7HK4s3ELV0=; b=R7zZPnIdBOKNp2nPeY3K2NZhjgou7tvoXebnAJFu57k1tGQrLCFj+l0rpZR0asu1S6 2w7t4qH9SMTmg+62Ci7lXDKi8KFqbb4U3GJflfE+2VX4jvyr6NhqzA/nEe0l6QNG+9wf Jf6l+cPirQMhESjYBt+yEvnELn1yt0qMx9xWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=NUSfE1FKnrB8OjMzRVgLCWMde44hlMwveBcDaHt41pcHQnnk89wsCZhMagUfqgOjXR Zf+GPV9NVwiXT7GAOXfi4tJIs6cL5w36QmIFg5SoO9g2ZTjBOWGrcLT8iglgpe9PJHuG QjEuWGoIbHF99bjbQz2K1rmlXb6r4q6kNy5cY= Received: by 10.216.50.72 with SMTP id y50mr900755web.28.1292138984263; Sat, 11 Dec 2010 23:29:44 -0800 (PST) Received: from [10.0.0.1] (bzq-79-181-24-102.red.bezeqint.net [79.181.24.102]) by mx.google.com with ESMTPS id m10sm3466389wbc.16.2010.12.11.23.29.40 (version=SSLv3 cipher=RC4-MD5); Sat, 11 Dec 2010 23:29:42 -0800 (PST) Message-ID: <4D0479E3.4050508@gmail.com> Date: Sun, 12 Dec 2010 09:29:39 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Luke Howard References: <4D02AF81.6000907@stpeter.im>

<78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> In-Reply-To: <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 16 Dec 2010 08:07:26 -0800 Cc: "apps-discuss@ietf.org" , websec , Paul Hoffman , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 07:28:12 -0000 Hi Luke, I am not a big fan of EAP myself (although I am a co-author on Yoav's TLS-EAP), but no, for pragmatic reasons SASL is not the moral equivalent. There is a number of EAP methods that provide zero-knowledge password based mutual authentication (i.e. password based auth that's *not* susceptible to dictionary attacks). These include (see http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3): EAP-SRP-SHA1, EAP-pwd, EAP-EKE and EAP-SPEKE. As far as I can see (http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml), SASL does not provide any equivalent method. Thanks, Yaron On 12/12/2010 03:38 AM, Luke Howard wrote: > > On 12/12/2010, at 10:10 AM, Yoav Nir wrote: > >> >> On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: >> >>> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >>>> Other than that, I'm not aware of much activity. What have I missed? >>> >>> TLS client certificates. >> >> TLS client certificates work, but as we've learned both with the web and with IPsec clients, people would much rather not use them. A few IETFs ago (Chicago?), a bunch of us tried to push the idea of TLS with EAP authentication. >> >> http://tools.ietf.org/html/draft-nir-tls-eap > > Does draft-williams-tls-app-sasl-opt-04.txt + abfab get you the moral equivalent? > > -- Luke From Josh.Howlett@ja.net Sun Dec 12 00:28:29 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF9493A6D83; Sun, 12 Dec 2010 00:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.098 X-Spam-Level: X-Spam-Status: No, score=-102.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 uijQy4we-7Wr; Sun, 12 Dec 2010 00:28:28 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 845183A6D03; Sun, 12 Dec 2010 00:28:28 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 8D3C64A6BAA_D04880AB; Sun, 12 Dec 2010 08:30:02 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 3F5484A6BA3_D0487FFF; Sun, 12 Dec 2010 08:29:51 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Sun, 12 Dec 2010 08:30:08 +0000 From: Josh Howlett To: Yaron Sheffer , Luke Howard Thread-Topic: [kitten] [saag] HTTP authentication: the next generation Thread-Index: AQHLmca26Q0IJHpixEGWpmc927Vy9JOcaR2AgAAQ5U4= Date: Sun, 12 Dec 2010 08:30:07 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 16 Dec 2010 08:07:25 -0800 Cc: Josh Howlett , "apps-discuss@ietf.org" , websec , Paul Hoffman , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 08:28:29 -0000 AbFab is defining a GSS EAP mechanism that can encapsulate the EAP methods = you mention. This mechanism could be run over SASL-TLS using GS2. Josh. --- original message --- From: "Yaron Sheffer" Subject: Re: [kitten] [saag] HTTP authentication: the next generation Date: 12th December 2010 Time: 7:36:41 am Hi Luke, I am not a big fan of EAP myself (although I am a co-author on Yoav's TLS-EAP), but no, for pragmatic reasons SASL is not the moral equivalent. There is a number of EAP methods that provide zero-knowledge password based mutual authentication (i.e. password based auth that's *not* susceptible to dictionary attacks). These include (see http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3): EAP-SRP-SHA1, EAP-pwd, EAP-EKE and EAP-SPEKE. As far as I can see (http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml), SASL does not provide any equivalent method. Thanks, Yaron On 12/12/2010 03:38 AM, Luke Howard wrote: > > On 12/12/2010, at 10:10 AM, Yoav Nir wrote: > >> >> On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: >> >>> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >>>> Other than that, I'm not aware of much activity. What have I missed? >>> >>> TLS client certificates. >> >> TLS client certificates work, but as we've learned both with the web and= with IPsec clients, people would much rather not use them. A few IETFs ago= (Chicago?), a bunch of us tried to push the idea of TLS with EAP authentic= ation. >> >> http://tools.ietf.org/html/draft-nir-tls-eap > > Does draft-williams-tls-app-sasl-opt-04.txt + abfab get you the moral equ= ivalent? > > -- Luke _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From ynir@checkpoint.com Sun Dec 12 00:40:02 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C62523A6D89; Sun, 12 Dec 2010 00:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.413 X-Spam-Level: X-Spam-Status: No, score=-9.413 tagged_above=-999 required=5 tests=[AWL=1.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Iy4+jBAiaJoV; Sun, 12 Dec 2010 00:40:01 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 0CB0E3A6D03; Sun, 12 Dec 2010 00:40:00 -0800 (PST) X-CheckPoint: {4D048ABF-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBC8fOCj014846; Sun, 12 Dec 2010 10:41:24 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 12 Dec 2010 10:41:24 +0200 From: Yoav Nir To: "'Josh Howlett'" , Yaron Sheffer , Luke Howard Date: Sun, 12 Dec 2010 10:41:23 +0200 Thread-Topic: [kitten] [saag] HTTP authentication: the next generation Thread-Index: AQHLmca26Q0IJHpixEGWpmc927Vy9JOcaR2AgAAQ5U6AAAIIsA== Message-ID: <006FEB08D9C6444AB014105C9AEB133F012E6FCD449F@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 16 Dec 2010 08:07:26 -0800 Cc: "apps-discuss@ietf.org" , websec , Paul Hoffman , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 08:40:03 -0000 To quote from Abfab's charter: This working group will specify a federated identity mechanism for use by other Internet protocols not based on HTML/HTTP,=20 For just adding authentication to HTTP, I don't think it makes sense to add= federation. All kinds of services such as web mail, online gaming, and onl= ine shopping require authentication, but there's no federation involved.=20 -----Original Message----- From: Josh Howlett [mailto:Josh.Howlett@ja.net]=20 Sent: 12 December 2010 10:30 To: Yaron Sheffer; Luke Howard Cc: apps-discuss@ietf.org; pgut001@cs.auckland.ac.nz; Yoav Nir; websec; Pau= l Hoffman; kitten@ietf.org; http-auth@ietf.org; saag@ietf.org; Hannes Tscho= fenig; Josh Howlett; ietf-http-wg@w3.org Group Subject: Re: [kitten] [saag] HTTP authentication: the next generation AbFab is defining a GSS EAP mechanism that can encapsulate the EAP methods = you mention. This mechanism could be run over SASL-TLS using GS2. Josh. --- original message --- From: "Yaron Sheffer" Subject: Re: [kitten] [saag] HTTP authentication: the next generation Date: 12th December 2010 Time: 7:36:41 am Hi Luke, I am not a big fan of EAP myself (although I am a co-author on Yoav's TLS-E= AP), but no, for pragmatic reasons SASL is not the moral equivalent. There is a number of EAP methods that provide zero-knowledge password based= mutual authentication (i.e. password based auth that's *not* susceptible t= o dictionary attacks). These include (see http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3): EAP-SRP-SHA1, EAP-pwd, EAP-EKE and EAP-SPEKE. As far as I can see (http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml), SASL does not provide any equivalent method. Thanks, Yaron On 12/12/2010 03:38 AM, Luke Howard wrote: > > On 12/12/2010, at 10:10 AM, Yoav Nir wrote: > >> >> On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: >> >>> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >>>> Other than that, I'm not aware of much activity. What have I missed? >>> >>> TLS client certificates. >> >> TLS client certificates work, but as we've learned both with the web and= with IPsec clients, people would much rather not use them. A few IETFs ago= (Chicago?), a bunch of us tried to push the idea of TLS with EAP authentic= ation. >> >> http://tools.ietf.org/html/draft-nir-tls-eap > > Does draft-williams-tls-app-sasl-opt-04.txt + abfab get you the moral equ= ivalent? > > -- Luke _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten JANET(UK) is a trading name of The JNT Association, a company limited by gu= arantee which is registered in England under No. 2881024 and whose Register= ed Office is at Lumen House, Library Avenue, Harwell Science and Innovation= Campus, Didcot, Oxfordshire. OX11 0SG Scanned by Check Point Total Security Gateway. From Josh.Howlett@ja.net Sun Dec 12 01:15:19 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51F33A6C70; Sun, 12 Dec 2010 01:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.181 X-Spam-Level: X-Spam-Status: No, score=-102.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 aCxxAMcVq9eP; Sun, 12 Dec 2010 01:15:18 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 514483A6D8E; Sun, 12 Dec 2010 01:15:18 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id F0B604A6B4E_D049304B; Sun, 12 Dec 2010 09:16:52 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 9E1374A6BA3_D0492F9F; Sun, 12 Dec 2010 09:16:41 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Sun, 12 Dec 2010 09:16:58 +0000 From: Josh Howlett To: Yoav Nir , Yaron Sheffer , Luke Howard Thread-Topic: [kitten] [saag] HTTP authentication: the next generation Thread-Index: AQHLmca26Q0IJHpixEGWpmc927Vy9JOcaR2AgAAQ5U6AAAIIsIAACxBo Date: Sun, 12 Dec 2010 09:16:58 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 16 Dec 2010 08:07:25 -0800 Cc: Josh Howlett , "apps-discuss@ietf.org" , websec , Paul Hoffman , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 09:15:19 -0000 Right, HTTP authentication is out of Abfab's scope. My point was that Abfab= is doing stuff that may nonetheless be useful for some other effort lookin= g at the problem. I agree with your observation re federation, but note that EAP authenticati= on does not imply federation. Josh. --- original message --- From: "Yoav Nir" Subject: RE: [kitten] [saag] HTTP authentication: the next generation Date: 12th December 2010 Time: 8:42:08 am To quote from Abfab's charter: This working group will specify a federated identity mechanism for use by other Internet protocols not based on HTML/HTTP, For just adding authentication to HTTP, I don't think it makes sense to add= federation. All kinds of services such as web mail, online gaming, and onl= ine shopping require authentication, but there's no federation involved. -----Original Message----- From: Josh Howlett [mailto:Josh.Howlett@ja.net] Sent: 12 December 2010 10:30 To: Yaron Sheffer; Luke Howard Cc: apps-discuss@ietf.org; pgut001@cs.auckland.ac.nz; Yoav Nir; websec; Pau= l Hoffman; kitten@ietf.org; http-auth@ietf.org; saag@ietf.org; Hannes Tscho= fenig; Josh Howlett; ietf-http-wg@w3.org Group Subject: Re: [kitten] [saag] HTTP authentication: the next generation AbFab is defining a GSS EAP mechanism that can encapsulate the EAP methods = you mention. This mechanism could be run over SASL-TLS using GS2. Josh. --- original message --- From: "Yaron Sheffer" Subject: Re: [kitten] [saag] HTTP authentication: the next generation Date: 12th December 2010 Time: 7:36:41 am Hi Luke, I am not a big fan of EAP myself (although I am a co-author on Yoav's TLS-E= AP), but no, for pragmatic reasons SASL is not the moral equivalent. There is a number of EAP methods that provide zero-knowledge password based= mutual authentication (i.e. password based auth that's *not* susceptible t= o dictionary attacks). These include (see http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3): EAP-SRP-SHA1, EAP-pwd, EAP-EKE and EAP-SPEKE. As far as I can see (http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml), SASL does not provide any equivalent method. Thanks, Yaron On 12/12/2010 03:38 AM, Luke Howard wrote: > > On 12/12/2010, at 10:10 AM, Yoav Nir wrote: > >> >> On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: >> >>> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >>>> Other than that, I'm not aware of much activity. What have I missed? >>> >>> TLS client certificates. >> >> TLS client certificates work, but as we've learned both with the web and= with IPsec clients, people would much rather not use them. A few IETFs ago= (Chicago?), a bunch of us tried to push the idea of TLS with EAP authentic= ation. >> >> http://tools.ietf.org/html/draft-nir-tls-eap > > Does draft-williams-tls-app-sasl-opt-04.txt + abfab get you the moral equ= ivalent? > > -- Luke _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten JANET(UK) is a trading name of The JNT Association, a company limited by gu= arantee which is registered in England under No. 2881024 and whose Register= ed Office is at Lumen House, Library Avenue, Harwell Science and Innovation= Campus, Didcot, Oxfordshire. OX11 0SG Scanned by Check Point Total Security Gateway. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From alexey.melnikov@isode.com Sun Dec 12 06:09:09 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9AFD3A6DC1; Sun, 12 Dec 2010 06:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.804 X-Spam-Level: X-Spam-Status: No, score=-102.804 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 7RKNwzBRmOBT; Sun, 12 Dec 2010 06:09:08 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id ED60D3A6DBE; Sun, 12 Dec 2010 06:09:07 -0800 (PST) Received: from [192.168.0.102] ((unknown) [109.73.6.25]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 12 Dec 2010 14:10:42 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D04D7D6.4090105@isode.com> Date: Sun, 12 Dec 2010 17:10:30 +0300 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: Yaron Sheffer References: <4D02AF81.6000907@stpeter.im>

<78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> In-Reply-To: <4D0479E3.4050508@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 16 Dec 2010 08:07:26 -0800 Cc: "apps-discuss@ietf.org" , websec , Paul Hoffman , "kitten@ietf.org" , "http-auth@ietf.org" , Luke Howard , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 14:09:10 -0000 Yaron Sheffer wrote: > Hi Luke, > > I am not a big fan of EAP myself (although I am a co-author on Yoav's > TLS-EAP), but no, for pragmatic reasons SASL is not the moral equivalent. > > There is a number of EAP methods that provide zero-knowledge password > based mutual authentication (i.e. password based auth that's *not* > susceptible to dictionary attacks). These include (see > http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3): > EAP-SRP-SHA1, EAP-pwd, EAP-EKE and EAP-SPEKE. > > As far as I can see > (http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml), > SASL does not provide any equivalent method. There is an expired SASL SRP draft, which can be revived, if needed. > Thanks, > Yaron > > On 12/12/2010 03:38 AM, Luke Howard wrote: > >> On 12/12/2010, at 10:10 AM, Yoav Nir wrote: >> >>> On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: >>> >>>> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >>>> >>>>> Other than that, I'm not aware of much activity. What have I missed? >>>> >>>> >>>> TLS client certificates. >>> >>> >>> TLS client certificates work, but as we've learned both with the web >>> and with IPsec clients, people would much rather not use them. A few >>> IETFs ago (Chicago?), a bunch of us tried to push the idea of TLS >>> with EAP authentication. >>> >>> http://tools.ietf.org/html/draft-nir-tls-eap >> >> >> Does draft-williams-tls-app-sasl-opt-04.txt + abfab get you the moral >> equivalent? >> >> -- Luke > From lear@cisco.com Sun Dec 12 13:34:17 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00D433A6E08; Sun, 12 Dec 2010 13:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.055 X-Spam-Level: X-Spam-Status: No, score=-110.055 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 NebqHih4IIKe; Sun, 12 Dec 2010 13:34:16 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 3D5EE3A6D47; Sun, 12 Dec 2010 13:34:15 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAEAIjPBE2Q/khLgWdsb2JhbACDXKAqFQEBFiIppWmKSY9SgSGDNXQEink X-IronPort-AV: E=Sophos;i="4.59,333,1288569600"; d="scan'208";a="15112279" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 12 Dec 2010 21:35:51 +0000 Received: from ams3-vpn-dhcp4641.cisco.com (ams3-vpn-dhcp4641.cisco.com [10.61.82.32]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oBCLZoMB011735; Sun, 12 Dec 2010 21:35:50 GMT Message-ID: <4D054041.7010203@cisco.com> Date: Sun, 12 Dec 2010 22:36:01 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Alexey Melnikov References: <4D02AF81.6000907@stpeter.im>

<78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> In-Reply-To: <4D051731.1020400@isode.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 16 Dec 2010 08:07:25 -0800 Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 21:34:17 -0000 Why settle for one? On 12/12/10 7:40 PM, Alexey Melnikov wrote: > Yoav Nir wrote: > >> EAP has one advantage. It is easy to integrate with existing >> RADIUS/DIAMETER infrastructure. >> > True. > And SASL has an advantage that it is easier to integrate with LDAP > infrastructure. > > I think this just demonstrates that before an HTTP authentication > mechanism can be evaluated, people need to agree on a common > evaluation criteria for HTTP authentication. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From fielding@gbiv.com Sun Dec 12 14:37:48 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA2483A6DFA; Sun, 12 Dec 2010 14:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.908 X-Spam-Level: X-Spam-Status: No, score=-102.908 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 5F7DPk-i9+xg; Sun, 12 Dec 2010 14:37:48 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id E3FE33A6CCA; Sun, 12 Dec 2010 14:37:47 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 765EE1F0069; Sun, 12 Dec 2010 14:39:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=FYJb5G/ckuimNYH2 EAMF3uuc/bmghPYH8ir/SmwsMldYFoE+q6MzaGFSbJI9RRh/KECrXuBVc6f27dDE yhWSaZliwtQsnTI1hlclvSpj7YkVT+8KdfyzMKny2yqtt3roZAfNF7h3tWfvOKEl SiiYD3rxArbXfIIhT3q52pL2QAA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=AY54s7iPVjMmfy217h64SJv5wQw=; b=cyn7LDvPTexWvZcI80dZLqHSlJG2 E1gBEKD8jFcSwDbV5YdfvdzZHIXMaoq+R3IN+Ssx1HqjKORiTU7yYahe0XDvqbAM /XzSPPuTPFS5TVncRhVYQ6NaMqT4zN462bWQbXkR52lqQjt4FoIDFAeLLne3QyTS +587nIlVypmcR3A= Received: from [192.168.1.66] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (Authenticated sender: fielding@gbiv.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPA id 01E541F0065; Sun, 12 Dec 2010 14:39:23 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <4D051731.1020400@isode.com> Date: Sun, 12 Dec 2010 14:39:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> References: <4D02AF81.6000907@stpeter.im>

<78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Thu, 16 Dec 2010 08:07:26 -0800 Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 22:37:49 -0000 On Dec 12, 2010, at 10:40 AM, Alexey Melnikov wrote: > Yoav Nir wrote: >=20 >> EAP has one advantage. It is easy to integrate with existing = RADIUS/DIAMETER infrastructure. >>=20 > True. > And SASL has an advantage that it is easier to integrate with LDAP = infrastructure. >=20 > I think this just demonstrates that before an HTTP authentication = mechanism can be evaluated, people need to agree on a common evaluation = criteria for HTTP authentication. Define them all and let's have a bake-off. It has been 16 years since HTTP auth was taken out of our hands so that the security experts could define something perfect. Zero progress so far. We should just define everything and let the security experts do what they do best -- find the holes and tell us what not to implement. ....Roy= From lear@cisco.com Mon Dec 13 03:28:02 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92723A6E8A; Mon, 13 Dec 2010 03:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.104 X-Spam-Level: X-Spam-Status: No, score=-110.104 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 O6ZgrQY9HnNt; Mon, 13 Dec 2010 03:28:01 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 299D23A6D9A; Mon, 13 Dec 2010 03:28:00 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkEABmSBU2Q/khNgWdsb2JhbACDXKAgFQEBFiIppjSKSZAggSGDNXQEink X-IronPort-AV: E=Sophos;i="4.59,335,1288569600"; d="scan'208";a="71514783" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 13 Dec 2010 11:29:37 +0000 Received: from dhcp-10-61-107-163.cisco.com (dhcp-10-61-107-163.cisco.com [10.61.107.163]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id oBDBTack011491; Mon, 13 Dec 2010 11:29:36 GMT Message-ID: <4D0603AA.7000004@cisco.com> Date: Mon, 13 Dec 2010 12:29:46 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Yoav Nir References: <4D02AF81.6000907@stpeter.im>

<78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> In-Reply-To: <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 16 Dec 2010 08:07:25 -0800 Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 11:28:02 -0000 And here-in lies the problem: I am concerned that in a large group we will not be able to reduce down to a single requirements list – AT THIS TIME. Also- my own experience is that having some decent proposals in front of you often helps drive at least SOME consolidation. From marsh@extendedsubset.com Sun Dec 12 16:47:37 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF99E3A6D90; Sun, 12 Dec 2010 16:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 bWvmuEKtAYSh; Sun, 12 Dec 2010 16:47:35 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 653B93A6D16; Sun, 12 Dec 2010 16:47:35 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PRwbI-00080u-0i; Mon, 13 Dec 2010 00:49:12 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2788E60C6; Mon, 13 Dec 2010 00:49:09 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+LS98k8zKrRc2V9A6d+dLVfNCJcc+FPxg= Message-ID: <4D056D83.2020704@extendedsubset.com> Date: Sun, 12 Dec 2010 18:49:07 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Roy T. Fielding" References: <4D02AF81.6000907@stpeter.im>

<78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> In-Reply-To: <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 16 Dec 2010 08:07:26 -0800 Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 00:47:37 -0000 On 12/12/2010 04:39 PM, Roy T. Fielding wrote: > > Define them all and let's have a bake-off. It has been 16 years > since HTTP auth was taken out of our hands so that the security > experts could define something perfect. Zero progress so far. Perhaps it's a bad idea? > We > should just define everything and let the security experts do what > they do best -- find the holes and tell us what not to implement. I know some professional pen-testers who would love that! Check out these videos. This is what happens when you take a general-purpose authentication protocol and repurpose it for use across the internet for an insecure application protocol: http://extendedsubset.com/smb_relay_fully_patched.wmv http://extendedsubset.com/smb_reflection_arp_poisoning.wmv http://extendedsubset.com/?p=36 This case is NTLMv2, but the phenomenon is not limited to that. The problem is that most general-purpose authentication protocols do not require enough specificity about the context of the authentication: who and what are you authenticating, to whom, and how does each side know it's operating under the same beliefs as the other? This means that even if the client wants to be careful and authenticate only for the purpose of setting up a secure connection, the attacker can possibly forward that authentication to auth his own connection or transaction on some other service (on the same or even a different server). Most auth protocols don't let the client strongly verify the server's identity before the client has to authenticate with his own. This is probably at least in part because it requires some common infrastructure to do this. So Kerberos and x509 PKI systems can authenticate the server (and sometimes even the target service), but most others do not. Since HTTP lacks connection integrity, it's meaningless to speak of "an authenticated client". Perhaps the only thing that could be meaningfully authenticated is the request data itself. But auth protocols designed for setting up persistent connections typically don't have defined inputs for the message data/digest being signed, so it's often impractical to reuse them for that purpose. These issues have been mostly addressed at the protocol level for TLS client cert authentication. If it really just comes down to deployment and client usability issues, it's hard to imagine coming up with something at another layer which would have less risk than building on top of that. Deploying new uses of compatible, standard authentication protocols over insecure application protocols can be bad for the greater security ecosystem because it widens the field for cross-protocol attacks. - Marsh From dsr@w3.org Mon Dec 13 02:16:17 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CA3E28C0DD; Mon, 13 Dec 2010 02:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 1QhYXMl8RCJH; Mon, 13 Dec 2010 02:16:16 -0800 (PST) Received: from lewis.sophia.w3.org (gw.sophia.w3.org [193.51.208.72]) by core3.amsl.com (Postfix) with ESMTP id 55D863A6CF3; Mon, 13 Dec 2010 02:16:16 -0800 (PST) Received: from dsl-217-155-168-222.zen.co.uk ([217.155.168.222] helo=[192.168.1.3]) by lewis.sophia.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PS5TJ-0003FO-IJ; Mon, 13 Dec 2010 10:17:33 +0000 From: Dave Raggett To: "Roy T. Fielding" In-Reply-To: <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> References: <4D02AF81.6000907@stpeter.im>

<78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Content-Type: text/plain; charset="UTF-8" Organization: W3C Date: Mon, 13 Dec 2010 10:17:34 +0000 Message-ID: <1292235454.20343.122.camel@ivy> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 16 Dec 2010 08:07:26 -0800 Cc: Jan Camenisch , "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 10:16:17 -0000 And let's not ignore secure privacy enhancing technologies like anonymous credentials and zero knowledge proofs, see e.g: http://www.w3.org/QA/2010/11/boosting_privacy_online_-_anon.html It is often sufficient to know that someone is a member of a group or has certain attributes rather than knowing exactly who that person is. Perhaps we could add to SASL the notion of secure anonymous access for authenticated access? This involves the client generating and passing a proof to the server that satisfies the proof specification and nonce provided by the server. [ Jan, see http://datatracker.ietf.org/wg/kitten/charter/ ] n.b. this work was carried out with support from the European PrimeLife project on privacy and identity, see http://www.primelife.eu/ On Sun, 2010-12-12 at 14:39 -0800, Roy T. Fielding wrote: > On Dec 12, 2010, at 10:40 AM, Alexey Melnikov wrote: > > > Yoav Nir wrote: > > > >> EAP has one advantage. It is easy to integrate with existing > RADIUS/DIAMETER infrastructure. > >> > > True. > > And SASL has an advantage that it is easier to integrate with LDAP > infrastructure. > > > > I think this just demonstrates that before an HTTP authentication > mechanism can be evaluated, people need to agree on a common > evaluation criteria for HTTP authentication. > > Define them all and let's have a bake-off. It has been 16 years since > HTTP auth was taken out of our hands so that the security experts could > define something perfect. Zero progress so far. We should just define > everything and let the security experts do what they do best -- find the > holes and tell us what not to implement. > > ....Roy > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Dave Raggett http://www.w3.org/People/Raggett From dave@cridland.net Mon Dec 13 02:24:26 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A64D28C0E3; Mon, 13 Dec 2010 02:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 hYtbAzJLozZ9; Mon, 13 Dec 2010 02:24:25 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 7F1B33A6D7A; Mon, 13 Dec 2010 02:24:24 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 2834911680FB; Mon, 13 Dec 2010 10:26:00 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 718q9D-RRrSU; Mon, 13 Dec 2010 10:25:53 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id EDEAF1168110; Mon, 13 Dec 2010 10:25:52 +0000 (GMT) References: <4D02AF81.6000907@stpeter.im>

<78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> In-Reply-To: <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> MIME-Version: 1.0 Message-Id: <2229.1292235952.971571@puncture> Date: Mon, 13 Dec 2010 10:25:52 +0000 From: Dave Cridland To: Yoav Nir , General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" , Eliot Lear Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Mailman-Approved-At: Thu, 16 Dec 2010 08:07:26 -0800 Subject: Re: [saag] [kitten] [apps-discuss] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 10:24:26 -0000 On Sun Dec 12 22:06:29 2010, Yoav Nir wrote: > - It has to be integrated in the protocol, not the application What?! No. It must be integrated in the application. If nothing else can be learnt, then learn this one thing - we have had Basic and Digest support in the protocol for years, but because they cannot easily be integrated into the application, no serious consumer applications use them, even though what they provide is never any better than Basic. If I could wave a magic wand and have all my wishes come true, I'd embed SASL into the web browser such that: - Users are presented with visually-distinct controls embedded into a web page for authentication, much like Extended Validation. Perhaps focussing them turns the address bar red or something. - The SASL message exchanges happen over a WebSocket or equivalent low-latency bidirectional channel. (Perhaps even HTTPS, I suppose - I imagine a webbrowser gets given one or more URIs to use for communications). - The result of this is a one-time password intializer. - Subsequent requests and responses occur with traditional HTTP auth, using some OTP mechanism that requires only a single message. The two parts of the protocol can, and should, be split - many existing websites use a cookie as the result of authentication, and having a more secure variant of this alone would be extremely useful. Note that the key portion of this - embedded SASL - is not really HTTP auth at all, but a Web Application Auth - since that's really the other party to the authentication, it seems quite obvious to me that this should be the authenticating entity. > - It has to be secure against phishing - if the attacker gets you > to authenticate, they can't later use that authentication to > connect to the real server > - If the authentication succeeded, then (a) you typed your password > correctly, and (b) this is really the server > > EAP has some methods that do this. SASL can probably be made to do > this, but with an extra layer. > > SASL also has methods that will do this, I think - I'm not sure what additional layer you're referring to here. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From adrien@qbik.com Mon Dec 13 02:53:39 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E4F28C0DB; Mon, 13 Dec 2010 02:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.769 X-Spam-Level: X-Spam-Status: No, score=-5.769 tagged_above=-999 required=5 tests=[AWL=-3.170, 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 QA-g+RFm1zpx; Mon, 13 Dec 2010 02:53:37 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by core3.amsl.com (Postfix) with ESMTP id 796D63A6E85; Mon, 13 Dec 2010 02:53:36 -0800 (PST) Received: From [192.168.1.10] (unverified [125.237.244.120]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.0.0 (Build 3102)) with SMTP id <0017850742@smtp.qbik.com>; Mon, 13 Dec 2010 23:55:11 +1300 Message-ID: <4D05FB8F.3070804@qbik.com> Date: Mon, 13 Dec 2010 23:55:11 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dave Cridland References: <4D02AF81.6000907@stpeter.im>

One major advantage of this approach is = that it makes it easy for sites to move to using the new federated auth sch= eme. Most sites already store an email address that is used to validate the= account.=A0

The actual mechanism by which the authen= tication claim is verified is not very interesting, nor does it particularl= y need to be standardized. What does require standardization is the ability= to embed the protocol in 'the Web' in a fluent and secure manner.<= /div>

Here is how I suggest this be achieved:

<= /div>

1) HTTP header

The Web browser attaches = an offer of authentication by means =A0of an account attached to a specific= domain to (potentially) every request:

Auth-N: domain=3Dexample= .com

If the server does not support Auth-N, th= e header will simply be ignored. Otherwise =A0the server can ask for automa= ted authentication.

2) HTTP Response

If the server decides to use the authentication mechanism, it responds wi= th information that tells the client what level of authentication is requir= ed. For example, a bank might require a 2 factor scheme. There is going to = be at a minimum a nonce.

Auth-N: snonce=3D<128bits>= ;

3) HTTP Request

It should be possible for the client to prove that i= t has ownership of the authentication token corresponding to the account.= =A0

It is not necessarily the case that the account owner w= ants to reveal to the site all their information. For example, it may not e= ven want the site to know the account name. This is all fairly easy to set = up using symmetric techniques.

Auth-N: domain=3Dexample.com; blindedaccount=3D<> snonce=3D<12= 8bits>; cnonce=3D<128bits>

One feature that the OpenID work has highlighted the need for is some form= of user directed account manager. If the user is going to be in control of= this process, they need to be able to specify what information is made ava= ilable to specific sites.

Conclusion:

I t= hink that what we require here is not yet another authentication framework = or protocol. What we need is the glue to bind it into an infrastructure tha= t makes it useful.

The most important design decision is to make use of RF= C822 email address format as the format for federated authentication accoun= ts.=A0

Once that decision is made, the rest will s= imply fall out of stating the requirements precisely.=A0

The risk here is that yet again we end up redo-ing the = parts that we know how to build rather than focus on the real problem which= is fitting them together.=A0

Above all, the user = has to be the first priority in any design.=A0

--00163662e65b3d7fce0497b20fd7-- From adrien@qbik.com Sun Dec 19 03:10:18 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2EB3A6853; Sun, 19 Dec 2010 03:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.845 X-Spam-Level: X-Spam-Status: No, score=-4.845 tagged_above=-999 required=5 tests=[AWL=-3.704, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 MCZWRmsCQ7a2; Sun, 19 Dec 2010 03:10:17 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by core3.amsl.com (Postfix) with ESMTP id 048063A6852; Sun, 19 Dec 2010 03:10:15 -0800 (PST) Received: From [192.168.1.10] (unverified [125.237.244.120]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.0.0 (Build 3109)) with SMTP id <0017864197@smtp.qbik.com>; Mon, 20 Dec 2010 00:12:02 +1300 Message-ID: <4D0DE882.50201@qbik.com> Date: Mon, 20 Dec 2010 00:12:02 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4D02AF81.6000907@stpeter.im>

I think that we need to distinguish between an authentication mechanism and an authentication infrastructure.

Part of the problem with HTTP authentication is that it was quickly superseded by HTML based authentication mechanisms. And these in turn suffer from the problem that password authentication fails when people share their passwords across sites, which of course they have no choice but to do when every stupid web site requires them to create yet another stupid account.

Since Digest Authentication became an RFC, I don't think there has ever been more than about 6 weeks elapsed without someone suggesting to me that we include SHA1 or SHA2 as a digest algorithm. Which is of course pointless when the major flaw in the authentication infrastructure is the lack of an authentication infrastructure. The original reason for designing Digest the way that I did was that public key cryptography was encumbered. Had public key cryptography been available, I would have used it.

By authentication infrastructure, I mean an infrastructure that allows the user to employ the same credentials at multiple sites with minimal or no user interaction. I do not mean a framework that allows for the use of 20 different protocols for verifying a username and password.

We do have almost as many proposals for federated authentication as authentication schemes of course. But each time there seems to be an obsession with things that technocrats obsess about and at best contempt for the actual user.

OpenID almost succeeded. But why on earth did we have to adopt URIs as the means of representing a user account? And why was it necessary to design a spec around the notion that what mattered most in the design of the spec was the ability to hack together an account manager using obsolete versions of common scripting languages?

Another feature of that debate I cannot understand is why we had to start talking about 'identity' as if it was some new and somehow profound problem that had only just been discovered.

There is of course a standard for representing federated user accounts that has already emerged on the net. And once that is realized, the technical requirements of a solution become rather obvious.

As Web sites discover that their account holders cannot remember their username, most have adopted email addresses as account identifiers. That is what we should use as the basis for federated web authentication.

So if the user account identifier looks like username@example.com, how does an entity verify that a purported user has a valid claim to that account?

The obvious mechanism in my view is to use DNS based discovery of an authentication service. For example, we might use the ESRV scheme I have been working on:

_auth._ws.example.com ESRV 0 prot "_saml._ws"

_auth._ws.example.com ESRV 0 prot "_xcat._ws"

Which declares that the SAML and 'XCAT' (presumably kitten in XML) protocols may be used to resolve authentication requests.

One major advantage of this approach is that it makes it easy for sites to move to using the new federated auth scheme. Most sites already store an email address that is used to validate the account.

The actual mechanism by which the authentication claim is verified is not very interesting, nor does it particularly need to be standardized. What does require standardization is the ability to embed the protocol in 'the Web' in a fluent and secure manner.

Here is how I suggest this be achieved:

1) HTTP header

The Web browser attaches an offer of authentication by means of an account attached to a specific domain to (potentially) every request:

Auth-N: domain=example.com

If the server does not support Auth-N, the header will simply be ignored. Otherwise the server can ask for automated authentication.

2) HTTP Response

If the server decides to use the authentication mechanism, it responds with information that tells the client what level of authentication is required. For example, a bank might require a 2 factor scheme. There is going to be at a minimum a nonce.

Auth-N: snonce=<128bits>

3) HTTP Request

It should be possible for the client to prove that it has ownership of the authentication token corresponding to the account.

It is not necessarily the case that the account owner wants to reveal to the site all their information. For example, it may not even want the site to know the account name. This is all fairly easy to set up using symmetric techniques.

Auth-N: domain=example.com; blindedaccount=<> snonce=<128bits>; cnonce=<128bits>

One feature that the OpenID work has highlighted the need for is some form of user directed account manager. If the user is going to be in control of this process, they need to be able to specify what information is made available to specific sites.

Conclusion:

I think that what we require here is not yet another authentication framework or protocol. What we need is the glue to bind it into an infrastructure that makes it useful.

The most important design decision is to make use of RFC822 email address format as the format for federated authentication accounts.

Once that decision is made, the rest will simply fall out of stating the requirements precisely.

The risk here is that yet again we end up redo-ing the parts that we know how to build rather than focus on the real problem which is fitting them together.

Above all, the user has to be the first priority in any design.

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

From nathan@webr3.org Sun Dec 19 05:45:24 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED69E3A68F5 for ; Sun, 19 Dec 2010 05:45:24 -0800 (PST) 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=[AWL=0.000, 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 zScBzYoHs4s0 for ; Sun, 19 Dec 2010 05:45:23 -0800 (PST) Received: from p3plsmtpa01-10.prod.phx3.secureserver.net (p3plsmtpa01-10.prod.phx3.secureserver.net [72.167.82.90]) by core3.amsl.com (Postfix) with SMTP id 4505C3A68F1 for ; Sun, 19 Dec 2010 05:45:23 -0800 (PST) Received: (qmail 8465 invoked from network); 19 Dec 2010 13:47:14 -0000 Received: from unknown (86.156.126.71) by p3plsmtpa01-10.prod.phx3.secureserver.net (72.167.82.90) with ESMTP; 19 Dec 2010 13:47:13 -0000 Message-ID: <4D0E0CDA.6030605@webr3.org> Date: Sun, 19 Dec 2010 13:47:06 +0000 From: Nathan Organization: webr3 User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adrien de Croy References: <4D02AF81.6000907@stpeter.im>

<78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <4D0DE882.50201@qbik.com> In-Reply-To: <4D0DE882.50201@qbik.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 19 Dec 2010 12:58:58 -0800 Cc: General discussion of application-layer protocols , websec , foaf-protocols , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , Phillip Hallam-Baker , Story Henry , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [websec] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: nathan@webr3.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 13:45:25 -0000 Hi Adrien, All, What you describe sounds very much like WebID Protocol (formerly FOAF+SSL) - there's an incubator group just starting at the W3C [1] although the protocol [2] has been under development for some time. Essentially it leverages X509 certificates on the client side, which contains an identifier (in the form of a URI) which can then be dereferenced to machine readable data (containing the public key from the x509 and any other data the entity wishes to expose), it serves as decentralized stateless authentication / identification, compatible with and built on the deployed stack of internet technologies, and further enables all kinds of trust & reputation hooks. cc'd: Henry Story, foaf-protocols [1] http://bblfish.net/tmp/2010/12/15/webid-charter-draft.html [2] http://getwebid.org/spec/drafts/ED-webid-20100809/index.html Best, Nathan Adrien de Croy wrote: > I think we need to go a bit further and consider the issue of trust. > > one problem with delegating account-holding back to a domain under the control > of the account-holder, is you have no trust. I could be hacker@hackyou.com or > spammer@spamyou.com. I can set up whatever account I like. Websites have no > information about whether I'm trustworthy or not, and have to build up their own > individual profile of me. > > To be really useful, the account-holding must be with a trusted independent > organisation able to be relied on by other websites. > > The organisation then has the opportunity to add value by > > a) verifying the true identity of the account holder > b) maintaining reputation information about the account holder > c) revoking abusive accounts. > > Ends up looking a lot like X.509 certificate infrastructure. Imagine if > everyone needed a client certificate to send any mail. We'd have no spam. > > Of course these sorts of concepts are completely unpalatable to many people on > account of privacy issues. Some of these activities are the sort of things that > governments should really be doing (and already are in many cases). > > Solving this problem has implications for all internet use, not just HTTP. > > Regards > > Adrien > > On 19/12/2010 5:48 a.m., Phillip Hallam-Baker wrote: >> I think that we need to distinguish between an authentication mechanism and an >> authentication infrastructure. >> >> Part of the problem with HTTP authentication is that it was quickly superseded >> by HTML based authentication mechanisms. And these in turn suffer from the >> problem that password authentication fails when people share their passwords >> across sites, which of course they have no choice but to do when every stupid >> web site requires them to create yet another stupid account. >> >> Since Digest Authentication became an RFC, I don't think there has ever been >> more than about 6 weeks elapsed without someone suggesting to me that we >> include SHA1 or SHA2 as a digest algorithm. Which is of course pointless when >> the major flaw in the authentication infrastructure is the lack of an >> authentication infrastructure. The original reason for designing Digest the >> way that I did was that public key cryptography was encumbered. Had public key >> cryptography been available, I would have used it. >> >> By authentication infrastructure, I mean an infrastructure that allows the >> user to employ the same credentials at multiple sites with minimal or no user >> interaction. I do not mean a framework that allows for the use of 20 different >> protocols for verifying a username and password. >> >> >> We do have almost as many proposals for federated authentication as >> authentication schemes of course. But each time there seems to be an obsession >> with things that technocrats obsess about and at best contempt for the actual >> user. >> >> OpenID almost succeeded. But why on earth did we have to adopt URIs as the >> means of representing a user account? And why was it necessary to design a >> spec around the notion that what mattered most in the design of the spec was >> the ability to hack together an account manager using obsolete versions of >> common scripting languages? >> >> Another feature of that debate I cannot understand is why we had to start >> talking about 'identity' as if it was some new and somehow profound problem >> that had only just been discovered. >> >> >> There is of course a standard for representing federated user accounts that >> has already emerged on the net. And once that is realized, the technical >> requirements of a solution become rather obvious. >> >> As Web sites discover that their account holders cannot remember their >> username, most have adopted email addresses as account identifiers. That is >> what we should use as the basis for federated web authentication. >> >> >> So if the user account identifier looks like username@example.com >> , how does an entity verify that a purported user >> has a valid claim to that account? >> >> The obvious mechanism in my view is to use DNS based discovery of an >> authentication service. For example, we might use the ESRV scheme I have been >> working on: >> >> _auth._ws.example.com ESRV 0 prot "_saml._ws" >> _auth._ws.example.com ESRV 0 prot "_xcat._ws" >> >> Which declares that the SAML and 'XCAT' (presumably kitten in XML) protocols >> may be used to resolve authentication requests. >> >> >> One major advantage of this approach is that it makes it easy for sites to >> move to using the new federated auth scheme. Most sites already store an email >> address that is used to validate the account. >> >> >> The actual mechanism by which the authentication claim is verified is not very >> interesting, nor does it particularly need to be standardized. What does >> require standardization is the ability to embed the protocol in 'the Web' in a >> fluent and secure manner. >> >> Here is how I suggest this be achieved: >> >> 1) HTTP header >> >> The Web browser attaches an offer of authentication by means of an account >> attached to a specific domain to (potentially) every request: >> >> Auth-N: domain=example.com >> >> If the server does not support Auth-N, the header will simply be ignored. >> Otherwise the server can ask for automated authentication. >> >> >> 2) HTTP Response >> >> If the server decides to use the authentication mechanism, it responds with >> information that tells the client what level of authentication is required. >> For example, a bank might require a 2 factor scheme. There is going to be at a >> minimum a nonce. >> >> Auth-N: snonce=<128bits> >> >> >> >> 3) HTTP Request >> >> It should be possible for the client to prove that it has ownership of the >> authentication token corresponding to the account. >> >> It is not necessarily the case that the account owner wants to reveal to the >> site all their information. For example, it may not even want the site to know >> the account name. This is all fairly easy to set up using symmetric techniques. >> >> Auth-N: domain=example.com ; blindedaccount=<> >> snonce=<128bits>; cnonce=<128bits> >> >> >> One feature that the OpenID work has highlighted the need for is some form of >> user directed account manager. If the user is going to be in control of this >> process, they need to be able to specify what information is made available to >> specific sites. >> >> >> Conclusion: >> >> I think that what we require here is not yet another authentication framework >> or protocol. What we need is the glue to bind it into an infrastructure that >> makes it useful. >> >> The most important design decision is to make use of RFC822 email address >> format as the format for federated authentication accounts. >> >> Once that decision is made, the rest will simply fall out of stating the >> requirements precisely. >> >> The risk here is that yet again we end up redo-ing the parts that we know how >> to build rather than focus on the real problem which is fitting them together. >> >> Above all, the user has to be the first priority in any design. > > -- > Adrien de Croy - WinGate Proxy Server - http://www.wingate.com > From benl@google.com Sun Dec 19 14:28:00 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1D63A692F for ; Sun, 19 Dec 2010 14:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.552 X-Spam-Level: X-Spam-Status: No, score=-104.552 tagged_above=-999 required=5 tests=[AWL=-3.788, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_OBFU_MILLIONS=1.213, USER_IN_WHITELIST=-100] 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 GsaGuHEJ-BJw for ; Sun, 19 Dec 2010 14:28:00 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 9F19D3A692E for ; Sun, 19 Dec 2010 14:27:58 -0800 (PST) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id oBJLnvQf011093 for ; Sun, 19 Dec 2010 13:49:58 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1292795398; bh=uWfAZT2M3FpdI4YhLUhCaX5+M+w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=OD1uee4PbeTNIzspa9tXpfqfld3OoNVEeo9VJpa48wXtODEiONuRIfoOimAhPwD/q YndRSlESn9E7uh84txA4A== Received: from qwj9 (qwj9.prod.google.com [10.241.195.73]) by kpbe13.cbf.corp.google.com with ESMTP id oBJLnuPQ020480 for ; Sun, 19 Dec 2010 13:49:56 -0800 Received: by qwj9 with SMTP id 9so2150561qwj.8 for ; Sun, 19 Dec 2010 13:49:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MfXLHtS0HhUmrdwYRuE7bZ/eaVoK3BSZWCEkYhNpwsM=; b=RS5mloI+ufvR0ZaoyqZrPac8GNuGrEPoI57fwDihC+87Dj4AEkALfT8JXCW5yfAdIp ccynlurtA78G5JQuY/Ww== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jEZ4eidTTY/ulcVKzn0G7Y5AUrzK1L8k2PDf1jp/J1txMZwtXuRzacanp9VZi89s0d NVl9hMudenCxuH3MfY+w== MIME-Version: 1.0 Received: by 10.229.81.12 with SMTP id v12mr3084026qck.35.1292795396286; Sun, 19 Dec 2010 13:49:56 -0800 (PST) Received: by 10.220.126.219 with HTTP; Sun, 19 Dec 2010 13:49:56 -0800 (PST) In-Reply-To: <4D0DE882.50201@qbik.com> References: <4D02AF81.6000907@stpeter.im>