From dix-bounces@ietf.org Wed Oct 18 13:15:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaF0u-00006u-E3; Wed, 18 Oct 2006 13:15:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaF0t-00005s-2A for dix@ietf.org; Wed, 18 Oct 2006 13:15:31 -0400 Received: from narn.hozed.org ([209.234.73.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaF0q-0004Dq-OY for dix@ietf.org; Wed, 18 Oct 2006 13:15:31 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 1000) by narn.hozed.org with local; Wed, 18 Oct 2006 12:15:23 -0500 id 00008010.4536612B.0000654F Date: Wed, 18 Oct 2006 12:15:23 -0500 From: Troy Benjegerdes To: Scott Kveton Message-ID: <20061018171523.GD25194@narn.hozed.org> References: <4533DD00.6060501@mozilla.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: dix@ietf.org, general@openid.net Subject: [dix] Re: Gathering requirements for in-browser OpenID support X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On Mon, Oct 16, 2006 at 12:31:48PM -0700, Scott Kveton wrote: > Hey Rob, > > > I'm trying to gather requirements for OpenID support. I think I have a > > reasonable understanding of the draft, but part of the appeal of OpenID > > is that it doesn't necessarily require browser vendors to do anything :) > > > > I've seen the proposed 2617-style HTTP authentication scheme on the > > wiki. What else could browser vendors do to make OpenID a smoother > > experience for users? > > As I posted on the Mozilla wiki: > > http://wiki.mozilla.org/Firefox/Feature_Brainstorming#Identity > > I'd love to see some anti-phishing mojo baked into the browser. If the user > could set their trusted IdP (or multiple as the case may be) in the browser > and then have the browser do something obvious when the users is presented > with an "untrusted" page asking for their password that would be great IMHO. I think there needs to be more overlap between the people on the OpenID list and people on the IETF DIX list... Both of these groups of people seem to have similiar ideas, and different approaches. A real solution to this distributed identity problem is going to involve both groups. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Oct 18 13:50:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFYY-0006u3-JH; Wed, 18 Oct 2006 13:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFYX-0006ty-30 for dix@ietf.org; Wed, 18 Oct 2006 13:50:17 -0400 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaFYT-0003TC-Pq for dix@ietf.org; Wed, 18 Oct 2006 13:50:17 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k9IHo7fL015092; Wed, 18 Oct 2006 13:50:07 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k9IHnuwO020732; Wed, 18 Oct 2006 13:49:56 -0400 Received: from [172.16.25.166] (dhcp-172-16-25-166.sfbay.redhat.com [172.16.25.166]) by potter.sfbay.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k9IHntrD009956; Wed, 18 Oct 2006 13:49:55 -0400 Message-ID: <45366942.50307@redhat.com> Date: Wed, 18 Oct 2006 10:49:54 -0700 From: Pete Rowley User-Agent: Thunderbird 1.5.0.7 (X11/20060911) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] Re: Gathering requirements for in-browser OpenID support References: <4533DD00.6060501@mozilla.com> <20061018171523.GD25194@narn.hozed.org> In-Reply-To: <20061018171523.GD25194@narn.hozed.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: Scott Kveton , general@openid.net X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1993786508==" Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1993786508== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030503030206080609020300" This is a cryptographically signed message in MIME format. --------------ms030503030206080609020300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Troy Benjegerdes wrote: > On Mon, Oct 16, 2006 at 12:31:48PM -0700, Scott Kveton wrote: > >> Hey Rob, >> >> >>> I'm trying to gather requirements for OpenID support. I think I have a >>> reasonable understanding of the draft, but part of the appeal of OpenID >>> is that it doesn't necessarily require browser vendors to do anything :) >>> >>> I've seen the proposed 2617-style HTTP authentication scheme on the >>> wiki. What else could browser vendors do to make OpenID a smoother >>> experience for users? >>> >> As I posted on the Mozilla wiki: >> >> http://wiki.mozilla.org/Firefox/Feature_Brainstorming#Identity >> >> I'd love to see some anti-phishing mojo baked into the browser. If the user >> could set their trusted IdP (or multiple as the case may be) in the browser >> and then have the browser do something obvious when the users is presented >> with an "untrusted" page asking for their password that would be great IMHO. >> > > I think there needs to be more overlap between the people on the OpenID > list and people on the IETF DIX list... Both of these groups of people > seem to have similiar ideas, and different approaches. A real solution > to this distributed identity problem is going to involve both groups. > > If there is going to be a "mojo" in the browser then I think it ought to just take care of the authentication itself i.e. the site never gets an opportunity to be MITM because users appear to them to always be previously authenticated. I also think it _is_ a requirement that the browser vendors support this - right now you have to trust that the RP is a white hat. -- Pete --------------ms030503030206080609020300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBzCC At4wggJHoAMCAQICEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oX DTA2MTIxODAxMzE1M1owRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8G CSqGSIb3DQEJARYScHJvd2xleUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAz5qzj9DVTZ6HS76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FW pszLXfKUgYnLBqgXXaSN7+Ve1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1 gLOjF6Yze9cHpio66W9orNdf1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55 j+Oj9+xGHeHK4lI96ljkWhTdgVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwup adY+BFiwBJRVMUTHlgSC99RJBgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQAB oy8wLTAdBgNVHREEFjAUgRJwcm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQCcnTFjF+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkz D3HLJYXu/9H1ltmXtDJMtOw/U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvks HDyJmWz1CvXmKzVHXnSaeK21vR/TKV3Z2Zu/7bXQGtRMmzCCAt4wggJHoAMCAQICEA20YTBn SYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oXDTA2MTIxODAxMzE1M1owRDEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScHJvd2xl eUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz5qzj9DVTZ6H S76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FWpszLXfKUgYnLBqgXXaSN7+Ve 1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1gLOjF6Yze9cHpio66W9orNdf 1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55j+Oj9+xGHeHK4lI96ljkWhTd gVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwupadY+BFiwBJRVMUTHlgSC99RJ BgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQABoy8wLTAdBgNVHREEFjAUgRJw cm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCcnTFj F+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkzD3HLJYXu/9H1ltmXtDJMtOw/ U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvksHDyJmWz1CvXmKzVHXnSaeK21 vR/TKV3Z2Zu/7bXQGtRMmzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQDbRhMGdJ hVdHgcD8KrKxXjAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wNjEwMTgxNzQ5NTRaMCMGCSqGSIb3DQEJBDEWBBS6RJEd552AKf6T o6lfgL5fD79Q8zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAnFFxskSR8j1Lcrs0lZ5L9k77JQ8aruCht0f/ete0uPa//XeogAS/fIxHMRUJ eIO7MFXue67/XgIOPPoj29xc0auM6q8389kWDkb15AhQHBfhvjeukTfXBkVAbXJKABoBQvu7 p5Lg5PT9YrVV3pr2HTZrU6YGXeEdB7wnxwxILTeT/ujPUC53EdzTmQdbHixpq/oEz1Jq+TEK 6tGrGaS7m4ji5Qwy5ujwQD5GU6AJBpshREAOkKoKbarR1V7+g8765Cbj/nbxtgL5+lZHdT0b zOmE/OtSMgONxZD4U5cvlRE2hIJUJXJgnyjuOwI0hEusP6bU2gXU+h6eJl+tV6IRmAAAAAAA AA== --------------ms030503030206080609020300-- --===============1993786508== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============1993786508==-- From dix-bounces@ietf.org Wed Oct 18 14:49:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaGTX-0003nI-QP; Wed, 18 Oct 2006 14:49:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaGTW-0003nD-AB for dix@ietf.org; Wed, 18 Oct 2006 14:49:10 -0400 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaGTU-0006Ik-2S for dix@ietf.org; Wed, 18 Oct 2006 14:49:10 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k9IIn580014322; Wed, 18 Oct 2006 14:49:05 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k9IIn44N018128; Wed, 18 Oct 2006 14:49:05 -0400 Received: from [172.16.25.166] (dhcp-172-16-25-166.sfbay.redhat.com [172.16.25.166]) by potter.sfbay.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k9IIn1q9013364; Wed, 18 Oct 2006 14:49:02 -0400 Message-ID: <4536771C.1000505@redhat.com> Date: Wed, 18 Oct 2006 11:49:00 -0700 From: Pete Rowley User-Agent: Thunderbird 1.5.0.7 (X11/20060911) MIME-Version: 1.0 To: Mike Glover Subject: Re: [dix] Re: Gathering requirements for in-browser OpenID support References: <4533DD00.6060501@mozilla.com> <20061018171523.GD25194@narn.hozed.org> <45366942.50307@redhat.com> <20061018110159.453e322b@rabbit.janrain.com> In-Reply-To: <20061018110159.453e322b@rabbit.janrain.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Digital Identity Exchange , general@openid.net X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0221815543==" Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0221815543== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080100090305060102060400" This is a cryptographically signed message in MIME format. --------------ms080100090305060102060400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mike Glover wrote: > Pete- > > Why do you have to trust the RP at all? All the RP ever sees is an assertion that you control the identity URL that you provided. That is what the RP sees if they play along with the scheme. > Do you see a vulnerability that I'm missing? > > It is vulnerable to a man in the middle attack - the RP, instead of redirecting to the IdP redirects to itself or some other site in cahoots, then proxies the conversation between the user and the IdP thereby compromising the users (global) credentials as they pass through. There really needs to be user-agent support to avoid that - either something CardSpace like, or browser plugin that only ever presents a pre-authenticated user. > -mike > > On Wed, 18 Oct 2006 10:49:54 -0700 > Pete Rowley wrote: > I also think it _is_ a requirement that the > >> browser vendors support this - right now you have to trust that the RP >> is a white hat. >> >> -- Pete --------------ms080100090305060102060400 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBzCC At4wggJHoAMCAQICEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oX DTA2MTIxODAxMzE1M1owRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8G CSqGSIb3DQEJARYScHJvd2xleUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAz5qzj9DVTZ6HS76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FW pszLXfKUgYnLBqgXXaSN7+Ve1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1 gLOjF6Yze9cHpio66W9orNdf1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55 j+Oj9+xGHeHK4lI96ljkWhTdgVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwup adY+BFiwBJRVMUTHlgSC99RJBgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQAB oy8wLTAdBgNVHREEFjAUgRJwcm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQCcnTFjF+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkz D3HLJYXu/9H1ltmXtDJMtOw/U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvks HDyJmWz1CvXmKzVHXnSaeK21vR/TKV3Z2Zu/7bXQGtRMmzCCAt4wggJHoAMCAQICEA20YTBn SYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oXDTA2MTIxODAxMzE1M1owRDEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScHJvd2xl eUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz5qzj9DVTZ6H S76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FWpszLXfKUgYnLBqgXXaSN7+Ve 1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1gLOjF6Yze9cHpio66W9orNdf 1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55j+Oj9+xGHeHK4lI96ljkWhTd gVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwupadY+BFiwBJRVMUTHlgSC99RJ BgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQABoy8wLTAdBgNVHREEFjAUgRJw cm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCcnTFj F+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkzD3HLJYXu/9H1ltmXtDJMtOw/ U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvksHDyJmWz1CvXmKzVHXnSaeK21 vR/TKV3Z2Zu/7bXQGtRMmzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQDbRhMGdJ hVdHgcD8KrKxXjAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wNjEwMTgxODQ5MDBaMCMGCSqGSIb3DQEJBDEWBBTW2nbPrdquBS6W KvTxrOL/Lz89ATBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAWixPxg+C940A+xbCTWgMadAO4OZ77sqW2hAwjV3BwkAAqh3chhD2DOOoqnQ7 pbVEnUmOg8/+JEHivi2iLCtZ1/g9n2zBdQXk9FSG/IrQLcQ0LlyRF+NAyApSLa7S5OREf4sH YPzbph0c7Nn+MwZST+2xkxFmu2CrpGISVJUjcCUXfVewxQOnPTFW/DjlvXKefMibzp0oWhCl IwWuxVPelN0dg+uKPceO9wbtRWqdz6+zTrp1yX1ONP9g80gOqPb/W3qSx128OCNQ47HvJhh9 H5dvswt7ptXN3KGlTAIw0wAoUGHulcRfd5f0kUHsRb+txiyj+R5VKiOh56qQuXQpFgAAAAAA AA== --------------ms080100090305060102060400-- --===============0221815543== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0221815543==-- From dix-bounces@ietf.org Wed Oct 18 22:21:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaNXF-0001Tn-Kx; Wed, 18 Oct 2006 22:21:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaNXD-0001Tc-QR for dix@ietf.org; Wed, 18 Oct 2006 22:21:27 -0400 Received: from copa.geek.net.au ([203.217.18.13] helo=srve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaNWK-0000ub-Vo for dix@ietf.org; Wed, 18 Oct 2006 22:20:39 -0400 Received: from BLANK (203-217-18-9.perm.iinet.net.au [203.217.18.9]) by srve.com (8.13.6/8.12.11) with ESMTP id k9J2KKac012710 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 19 Oct 2006 02:20:21 GMT Date: Thu, 19 Oct 2006 12:20:27 +1000 From: Chris Drake X-Priority: 3 (Normal) Message-ID: <1911839956.20061019122027@pobox.com> To: Scott Kveton Subject: Re[2]: [dix] Re: Gathering requirements for in-browser OpenID support In-Reply-To: References: <4536771C.1000505@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: specs@openid.net, general@openid.net, Mike Glover , Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Hi Scott, All solutions for client-based MITM and phishing prevention can easily be built on top of OpenID 2.0 if we adopt the OpenIDHTTPAuth proposal. We can then leave these people to build their tools and protection howsoever they like, safe in the knowledge that when it's *done*, there will be a range of new plugins that will immediately work with all OpenID 2.0 enabled sites - and best of all - it does not have to hold up the OpenID 2.0 development in the meantime. The only thing we need to give to these tools is a way to get the login process started - that is - OpenIDHTTPAuth: the downloaded plugin needs to be able to get an entry point for the OpenID CGI code on the web site. ----------- Here is a copy of my vote to include the above proposal, which contains more info abut it too: Hi, Why's this proposal "depreciated" ? ( http://www.lifewiki.net/openid/OpenIDProposals ) I'm casting my vote here: +1 to [PROPOSAL] bare response / bare request Besides the listed uses, it also allows IdPs to layer privacy and delegation easily on top of OpenID, as well as permitting cool future features (like letting a user change something at their IdP, and have that change be "pushed out" to all relevant RPs). This is a small and simple to implement "hook" which I believe will be the dominating bit of OpenID protocol use in future. Alternatively - if we can standardize a way for the OpenIDHTTPAuth proposed extension to discover the RP's OpenID "entry point" [so as to reliably eliminate the "optional" first step proposed here http://www.lifewiki.net/openid/OpenIDHTTPAuth ] - this is a good working alterative way to accommodate the "bare response" part that we need. So... +1 to OpenIDHTTPAuth - on the proviso RP's publish an endpoint URL that's somehow available to scripts, plugins, software agents that encounter OpenID login pages. Suggestion: (for OpenID-enabled login pages):- ----------- Kind Regards, Chris Drake Thursday, October 19, 2006, 6:07:08 AM: >> It is vulnerable to a man in the middle attack - the RP, instead of >> redirecting to the IdP redirects to itself or some other site in >> cahoots, then proxies the conversation between the user and the IdP >> thereby compromising the users (global) credentials as they pass through. SK> Right, we've known about this for quite some time unfortunately there hasn't SK> be a particularly easy solution to it and I classify this as one of those SK> "The Internet Sucks" problems. I'm not saying we shouldn't/couldn't do SK> anything about it I just think the right solution that mixes SK> ease-of-implementation and user need hasn't been found yet. >> There really needs to be user-agent support to avoid that - either >> something CardSpace like, or browser plugin that only ever presents a >> pre-authenticated user. SK> I think we're headed in this direction. However, we have to crawl before we SK> can walk. At least solving a big chunk of the use cases, getting some SK> momentum behind the platform and solving a specific problem for users SK> *today* is better than trying to build the perfect tool. We can talk and SK> talk on these lists but we really don't know how users are going to use this SK> stuff (or abuse it for that matter) until its out there and working in the SK> wild. SK> I can't emphasize more the fact that with every passing day that we don't SK> have OpenID v2.0 out the door, we're losing momentum from fixing specific SK> user problems that are solved in the existing specification. SK> - Scott SK> _______________________________________________ SK> general mailing list SK> general@openid.net SK> http://openid.net/mailman/listinfo/general _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Oct 18 23:56:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaP13-0002hI-Ao; Wed, 18 Oct 2006 23:56:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaP12-0002hC-PK for dix@ietf.org; Wed, 18 Oct 2006 23:56:20 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaP10-0003h6-Cb for dix@ietf.org; Wed, 18 Oct 2006 23:56:20 -0400 Received: from [192.168.1.106] (d207-6-234-158.bchsia.telus.net [207.6.234.158]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k9J3uA3W073865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Oct 2006 20:56:10 -0700 (PDT) (envelope-from dick@sxip.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <494BE94B-A5B6-4336-8205-2C5BF6D568C8@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Re: Gathering requirements for in-browser OpenID support Date: Wed, 18 Oct 2006 20:56:05 -0700 To: Scott Kveton X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: general@openid.net, Mike Glover , Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org The MITM attack vector resolution is out of scope of OpenID Authentication as it is a ceremony between the user and the IdP. The user and IdP need to know they are talking directly to each other. -- Dick On 18-Oct-06, at 1:07 PM, Scott Kveton wrote: >> It is vulnerable to a man in the middle attack - the RP, instead of >> redirecting to the IdP redirects to itself or some other site in >> cahoots, then proxies the conversation between the user and the IdP >> thereby compromising the users (global) credentials as they pass >> through. > > Right, we've known about this for quite some time unfortunately > there hasn't > be a particularly easy solution to it and I classify this as one of > those > "The Internet Sucks" problems. I'm not saying we shouldn't/ > couldn't do > anything about it I just think the right solution that mixes > ease-of-implementation and user need hasn't been found yet. > >> There really needs to be user-agent support to avoid that - either >> something CardSpace like, or browser plugin that only ever presents a >> pre-authenticated user. > > I think we're headed in this direction. However, we have to crawl > before we > can walk. At least solving a big chunk of the use cases, getting some > momentum behind the platform and solving a specific problem for users > *today* is better than trying to build the perfect tool. We can > talk and > talk on these lists but we really don't know how users are going to > use this > stuff (or abuse it for that matter) until its out there and working > in the > wild. > > I can't emphasize more the fact that with every passing day that we > don't > have OpenID v2.0 out the door, we're losing momentum from fixing > specific > user problems that are solved in the existing specification. > > - Scott > > _______________________________________________ > general mailing list > general@openid.net > http://openid.net/mailman/listinfo/general > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Oct 19 00:16:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaPKd-0006km-9a; Thu, 19 Oct 2006 00:16:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaPKb-0006jv-En for dix@ietf.org; Thu, 19 Oct 2006 00:16:33 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaPKZ-0000kE-IG for dix@ietf.org; Thu, 19 Oct 2006 00:16:33 -0400 Received: from [192.168.1.106] (d207-6-234-158.bchsia.telus.net [207.6.234.158]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k9J4GIQY074461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Oct 2006 21:16:18 -0700 (PDT) (envelope-from dick@sxip.com) In-Reply-To: <20061018171523.GD25194@narn.hozed.org> References: <4533DD00.6060501@mozilla.com> <20061018171523.GD25194@narn.hozed.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Date: Wed, 18 Oct 2006 21:16:13 -0700 To: Troy Benjegerdes X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Scott Kveton , dix@ietf.org, general@openid.net Subject: [dix] Re: Gathering requirements for in-browser OpenID support X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 18-Oct-06, at 10:15 AM, Troy Benjegerdes wrote: > I think there needs to be more overlap between the people on the > OpenID > list and people on the IETF DIX list... Both of these groups of people > seem to have similiar ideas, and different approaches. A real solution > to this distributed identity problem is going to involve both groups. Hi Troy All the DIX work was merged into the OpenID 2.0 work. I posted this Sept 11th: http://www1.ietf.org/mail-archive/web/dix/current/msg00863.html -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Oct 19 12:35:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaarg-0004M0-MW; Thu, 19 Oct 2006 12:35:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaarf-0004Do-AK for dix@ietf.org; Thu, 19 Oct 2006 12:35:27 -0400 Received: from copa.geek.net.au ([203.217.18.13] helo=srve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaarZ-0004CR-Je for dix@ietf.org; Thu, 19 Oct 2006 12:35:27 -0400 Received: from BLANK (203-217-18-9.perm.iinet.net.au [203.217.18.9]) by srve.com (8.13.6/8.12.11) with ESMTP id k9JGZFuX005164 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 19 Oct 2006 16:35:15 GMT Date: Fri, 20 Oct 2006 02:35:24 +1000 From: Chris Drake X-Priority: 3 (Normal) Message-ID: <1441909800.20061020023524@pobox.com> To: Dick Hardt Subject: Re[2]: [dix] Re: Gathering requirements for in-browser OpenID support In-Reply-To: <494BE94B-A5B6-4336-8205-2C5BF6D568C8@sxip.com> References: <494BE94B-A5B6-4336-8205-2C5BF6D568C8@sxip.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Scott Kveton , Digital Identity Exchange , general@openid.net X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Hi Dick, I disagree - the RP is *responsible* for directing the user to the IdP; This is the highest risk point of MITM attack. OpenID MUST include something to "enable" a "safe redirect" or browser-chrome activation or whathaveyou. Granted - chrome etc shouldn't be in the spec, but *enabling* it for the future MUST. Kind Regards, Chris Drake Thursday, October 19, 2006, 1:56:05 PM, you wrote: DH> The MITM attack vector resolution is out of scope of OpenID DH> Authentication as it is a ceremony between the user and the IdP. The DH> user and IdP need to know they are talking directly to each other. DH> -- Dick DH> On 18-Oct-06, at 1:07 PM, Scott Kveton wrote: >>> It is vulnerable to a man in the middle attack - the RP, instead of >>> redirecting to the IdP redirects to itself or some other site in >>> cahoots, then proxies the conversation between the user and the IdP >>> thereby compromising the users (global) credentials as they pass >>> through. >> >> Right, we've known about this for quite some time unfortunately >> there hasn't >> be a particularly easy solution to it and I classify this as one of >> those >> "The Internet Sucks" problems. I'm not saying we shouldn't/ >> couldn't do >> anything about it I just think the right solution that mixes >> ease-of-implementation and user need hasn't been found yet. >> >>> There really needs to be user-agent support to avoid that - either >>> something CardSpace like, or browser plugin that only ever presents a >>> pre-authenticated user. >> >> I think we're headed in this direction. However, we have to crawl >> before we >> can walk. At least solving a big chunk of the use cases, getting some >> momentum behind the platform and solving a specific problem for users >> *today* is better than trying to build the perfect tool. We can >> talk and >> talk on these lists but we really don't know how users are going to >> use this >> stuff (or abuse it for that matter) until its out there and working >> in the >> wild. >> >> I can't emphasize more the fact that with every passing day that we >> don't >> have OpenID v2.0 out the door, we're losing momentum from fixing >> specific >> user problems that are solved in the existing specification. >> >> - Scott >> >> _______________________________________________ >> general mailing list >> general@openid.net >> http://openid.net/mailman/listinfo/general >> >> DH> _______________________________________________ DH> general mailing list DH> general@openid.net DH> http://openid.net/mailman/listinfo/general _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Oct 19 12:53:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gab9P-000376-SL; Thu, 19 Oct 2006 12:53:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gab7n-0001qK-GO for dix@ietf.org; Thu, 19 Oct 2006 12:52:07 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gab1P-0006nN-LN for dix@ietf.org; Thu, 19 Oct 2006 12:45:33 -0400 Received: from [192.168.1.105] (d207-6-234-158.bchsia.telus.net [207.6.234.158]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k9JGjT7Q097435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Oct 2006 09:45:29 -0700 (PDT) (envelope-from dick@sxip.com) In-Reply-To: <000d01c6f39d$3a1f4260$d27d11ac@AMSOFTWachob> References: <000d01c6f39d$3a1f4260$d27d11ac@AMSOFTWachob> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1272B7BB-A670-4F00-A482-2AAE6AFAE5FC@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: Re[2]: [dix] Re: Gathering requirements for in-browser OpenID support Date: Thu, 19 Oct 2006 09:45:23 -0700 To: "Gabe Wachob" X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: general@openid.net, 'Digital Identity Exchange' X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Just to keep beating that dead horse some more, this demonstrates why *how* to solve the issue is out of scope, but that there is an issue MUST be in the spec. :-) btw: that is a cool extension, but wait until you see ours! ;-) -- Dick On 19-Oct-06, at 9:40 AM, Gabe Wachob wrote: > And not to beat a dead horse to a pulp, but the Ph-Off Firefox > extension > from OOTao provides exactly this sort of trustable (based on SSL > certs) > visual indicator that you are actually talking to your real OpenID > IDP. Its > obviously an early iteration, but it *is* there and performs the > function > adequately. > > http://chile.ootao.com/phoff/ > > -Gabe > > >> -----Original Message----- >> From: general-bounces@openid.net [mailto:general- >> bounces@openid.net] On >> Behalf Of Chris Drake >> Sent: Thursday, October 19, 2006 9:35 AM >> To: Dick Hardt >> Cc: Digital Identity Exchange; general@openid.net >> Subject: Re[2]: [dix] Re: Gathering requirements for in-browser >> OpenID >> support >> >> Hi Dick, >> >> I disagree - the RP is *responsible* for directing the user to the >> IdP; This is the highest risk point of MITM attack. OpenID MUST >> include something to "enable" a "safe redirect" or browser-chrome >> activation or whathaveyou. Granted - chrome etc shouldn't be in the >> spec, but *enabling* it for the future MUST. >> >> Kind Regards, >> Chris Drake >> >> >> Thursday, October 19, 2006, 1:56:05 PM, you wrote: >> >> DH> The MITM attack vector resolution is out of scope of OpenID >> DH> Authentication as it is a ceremony between the user and the >> IdP. The >> DH> user and IdP need to know they are talking directly to each >> other. >> >> DH> -- Dick >> >> DH> On 18-Oct-06, at 1:07 PM, Scott Kveton wrote: >> >>>>> It is vulnerable to a man in the middle attack - the RP, >>>>> instead of >>>>> redirecting to the IdP redirects to itself or some other site in >>>>> cahoots, then proxies the conversation between the user and the >>>>> IdP >>>>> thereby compromising the users (global) credentials as they pass >>>>> through. >>>> >>>> Right, we've known about this for quite some time unfortunately >>>> there hasn't >>>> be a particularly easy solution to it and I classify this as one of >>>> those >>>> "The Internet Sucks" problems. I'm not saying we shouldn't/ >>>> couldn't do >>>> anything about it I just think the right solution that mixes >>>> ease-of-implementation and user need hasn't been found yet. >>>> >>>>> There really needs to be user-agent support to avoid that - either >>>>> something CardSpace like, or browser plugin that only ever >>>>> presents a >>>>> pre-authenticated user. >>>> >>>> I think we're headed in this direction. However, we have to crawl >>>> before we >>>> can walk. At least solving a big chunk of the use cases, >>>> getting some >>>> momentum behind the platform and solving a specific problem for >>>> users >>>> *today* is better than trying to build the perfect tool. We can >>>> talk and >>>> talk on these lists but we really don't know how users are going to >>>> use this >>>> stuff (or abuse it for that matter) until its out there and working >>>> in the >>>> wild. >>>> >>>> I can't emphasize more the fact that with every passing day that we >>>> don't >>>> have OpenID v2.0 out the door, we're losing momentum from fixing >>>> specific >>>> user problems that are solved in the existing specification. >>>> >>>> - Scott >>>> >>>> _______________________________________________ >>>> general mailing list >>>> general@openid.net >>>> http://openid.net/mailman/listinfo/general >>>> >>>> >> >> DH> _______________________________________________ >> DH> general mailing list >> DH> general@openid.net >> DH> http://openid.net/mailman/listinfo/general >> >> >> >> _______________________________________________ >> general mailing list >> general@openid.net >> http://openid.net/mailman/listinfo/general > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Oct 19 12:54:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GabAP-000829-8y; Thu, 19 Oct 2006 12:54:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gab7p-0001sI-AB for dix@ietf.org; Thu, 19 Oct 2006 12:52:09 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gaazj-0006Om-Tr for dix@ietf.org; Thu, 19 Oct 2006 12:43:50 -0400 Received: from [192.168.1.105] (d207-6-234-158.bchsia.telus.net [207.6.234.158]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k9JGhbh7097272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Oct 2006 09:43:37 -0700 (PDT) (envelope-from dick@sxip.com) In-Reply-To: <1441909800.20061020023524@pobox.com> References: <494BE94B-A5B6-4336-8205-2C5BF6D568C8@sxip.com> <1441909800.20061020023524@pobox.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: Re[2]: [dix] Re: Gathering requirements for in-browser OpenID support Date: Thu, 19 Oct 2006 09:43:31 -0700 To: Chris Drake X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Scott Kveton , Digital Identity Exchange , general@openid.net X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Hi Chris I agree this is a risk point, but that it belongs in the security considerations that the IdP must ensure it is talking directly to the user. There is no reason why there needs to be a standard way of solving this though. One IdP may do it one way, another a different way. It could also be solved by the browser. It is out of scope of the specification ust like how the user authenticates to the IdP is out of scope. If you have an idea on something that the RP would do, I'd love to hear it, and then it would be in scope. -- Dick On 19-Oct-06, at 9:35 AM, Chris Drake wrote: > Hi Dick, > > I disagree - the RP is *responsible* for directing the user to the > IdP; This is the highest risk point of MITM attack. OpenID MUST > include something to "enable" a "safe redirect" or browser-chrome > activation or whathaveyou. Granted - chrome etc shouldn't be in the > spec, but *enabling* it for the future MUST. > > Kind Regards, > Chris Drake > > > Thursday, October 19, 2006, 1:56:05 PM, you wrote: > > DH> The MITM attack vector resolution is out of scope of OpenID > DH> Authentication as it is a ceremony between the user and the > IdP. The > DH> user and IdP need to know they are talking directly to each other. > > DH> -- Dick > > DH> On 18-Oct-06, at 1:07 PM, Scott Kveton wrote: > >>>> It is vulnerable to a man in the middle attack - the RP, instead of >>>> redirecting to the IdP redirects to itself or some other site in >>>> cahoots, then proxies the conversation between the user and the IdP >>>> thereby compromising the users (global) credentials as they pass >>>> through. >>> >>> Right, we've known about this for quite some time unfortunately >>> there hasn't >>> be a particularly easy solution to it and I classify this as one of >>> those >>> "The Internet Sucks" problems. I'm not saying we shouldn't/ >>> couldn't do >>> anything about it I just think the right solution that mixes >>> ease-of-implementation and user need hasn't been found yet. >>> >>>> There really needs to be user-agent support to avoid that - either >>>> something CardSpace like, or browser plugin that only ever >>>> presents a >>>> pre-authenticated user. >>> >>> I think we're headed in this direction. However, we have to crawl >>> before we >>> can walk. At least solving a big chunk of the use cases, getting >>> some >>> momentum behind the platform and solving a specific problem for >>> users >>> *today* is better than trying to build the perfect tool. We can >>> talk and >>> talk on these lists but we really don't know how users are going to >>> use this >>> stuff (or abuse it for that matter) until its out there and working >>> in the >>> wild. >>> >>> I can't emphasize more the fact that with every passing day that we >>> don't >>> have OpenID v2.0 out the door, we're losing momentum from fixing >>> specific >>> user problems that are solved in the existing specification. >>> >>> - Scott >>> >>> _______________________________________________ >>> general mailing list >>> general@openid.net >>> http://openid.net/mailman/listinfo/general >>> >>> > > DH> _______________________________________________ > DH> general mailing list > DH> general@openid.net > DH> http://openid.net/mailman/listinfo/general > > > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Oct 19 14:32:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GacgO-0001Jy-8A; Thu, 19 Oct 2006 14:31:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GacgN-0001Jt-25 for dix@ietf.org; Thu, 19 Oct 2006 14:31:55 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GacgK-000415-3a for dix@ietf.org; Thu, 19 Oct 2006 14:31:55 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k9JIVp4l011078; Thu, 19 Oct 2006 11:31:51 -0700 Received: from MOU1WNEXMB14.vcorp.ad.vrsn.com ([10.25.13.245]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 11:30:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Re[2]: [dix] Re: Gathering requirements for in-browser OpenIDsupport Date: Thu, 19 Oct 2006 11:30:13 -0700 Message-ID: <7E7CA24460925C44AEB4F202BA7E45F302B51D@MOU1WNEXMB14.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re[2]: [dix] Re: Gathering requirements for in-browser OpenIDsupport Thread-Index: Acbzq7a5AYmgiabOTkOTVyMDkTvF/gAAMnzA From: "Recordon, David" To: X-OriginalArrivalTime: 19 Oct 2006 18:30:13.0524 (UTC) FILETIME=[9DDF9D40:01C6F3AC] X-Spam-Score: 0.3 (/) X-Scan-Signature: ea36de7a5e28e9b4461c8d685f4e97f1 Cc: Digital Identity Exchange , specs@openid.net, general@openid.net X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2141606242==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============2141606242== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F3AC.9DA00DC8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F3AC.9DA00DC8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Andy, I think it is incredibly useful in showing the technology needed to help protect users with systems like this. I'd love to see it as part of the Heraldry project, you are already a committer, assuming you'd be willing to contribute it. =20 --David ________________________________ From: specs-bounces@openid.net [mailto:specs-bounces@openid.net] On Behalf Of andy.dale@ootao.com Sent: Wednesday, October 18, 2006 11:44 PM To: Digital Identity Exchange Cc: Digital Identity Exchange; specs@openid.net; general@openid.net Subject: Re: Re[2]: [dix] Re: Gathering requirements for in-browser OpenIDsupport I'd be interested to hear if people think the ph-off plugin is useful or not.... If not why not?=20 If people think it's useful then I will happily extend it and make it more usable and I will put it into whatever open source project would like to house it.=20 I built it as a proof of concept that it _could_ be done... Now the question of _should_ it be done :-)=20 http://chile.ootao.com/phoff/=20 Andy Dale ooTao, Inc. Phone: 877-213-7935 Fax: 877-213-7935 i-name: =3DAndy.Dale http://xri.net/=3Dandy.dale ************************************************************************ *** If you don't have an i-name yet use this link to visit one of our partners and buy one: http://www.ezibroker.net/partners.html ************************************************************************ *** Chris Drake =20 10/18/2006 07:20 PM=20 Please respond to Digital Identity Exchange To Scott Kveton =20 cc specs@openid.net, general@openid.net, Mike Glover , Digital Identity Exchange =20 Subject Re[2]: [dix] Re: Gathering requirements for in-browser OpenID support =09 Hi Scott, All solutions for client-based MITM and phishing prevention can easily be built on top of OpenID 2.0 if we adopt the OpenIDHTTPAuth proposal. We can then leave these people to build their tools and protection howsoever they like, safe in the knowledge that when it's *done*, there will be a range of new plugins that will immediately work with all OpenID 2.0 enabled sites - and best of all - it does not have to hold up the OpenID 2.0 development in the meantime. The only thing we need to give to these tools is a way to get the login process started - that is - OpenIDHTTPAuth: the downloaded plugin needs to be able to get an entry point for the OpenID CGI code on the web site. ----------- Here is a copy of my vote to include the above proposal, which contains more info abut it too: Hi, Why's this proposal "depreciated" ? ( http://www.lifewiki.net/openid/OpenIDProposals ) I'm casting my vote here: +1 to [PROPOSAL] bare response / bare request Besides the listed uses, it also allows IdPs to layer privacy and delegation easily on top of OpenID, as well as permitting cool future features (like letting a user change something at their IdP, and have that change be "pushed out" to all relevant RPs). This is a small and simple to implement "hook" which I believe will be the dominating bit of OpenID protocol use in future. Alternatively - if we can standardize a way for the OpenIDHTTPAuth proposed extension to discover the RP's OpenID "entry point" [so as to reliably eliminate the "optional" first step proposed here http://www.lifewiki.net/openid/OpenIDHTTPAuth ] - this is a good working alterative way to accommodate the "bare response" part that we need. So... +1 to OpenIDHTTPAuth - on the proviso RP's publish an endpoint URL that's somehow available to scripts, plugins, software agents that encounter OpenID login pages. Suggestion: (for OpenID-enabled login pages):- ----------- Kind Regards, Chris Drake Thursday, October 19, 2006, 6:07:08 AM: >> It is vulnerable to a man in the middle attack - the RP, instead of >> redirecting to the IdP redirects to itself or some other site in >> cahoots, then proxies the conversation between the user and the IdP >> thereby compromising the users (global) credentials as they pass through. SK> Right, we've known about this for quite some time unfortunately there hasn't SK> be a particularly easy solution to it and I classify this as one of those SK> "The Internet Sucks" problems. I'm not saying we shouldn't/couldn't do SK> anything about it I just think the right solution that mixes SK> ease-of-implementation and user need hasn't been found yet. >> There really needs to be user-agent support to avoid that - either >> something CardSpace like, or browser plugin that only ever presents a >> pre-authenticated user. SK> I think we're headed in this direction. However, we have to crawl before we SK> can walk. At least solving a big chunk of the use cases, getting some SK> momentum behind the platform and solving a specific problem for users SK> *today* is better than trying to build the perfect tool. We can talk and SK> talk on these lists but we really don't know how users are going to use this SK> stuff (or abuse it for that matter) until its out there and working in the SK> wild. SK> I can't emphasize more the fact that with every passing day that we don't SK> have OpenID v2.0 out the door, we're losing momentum from fixing specific SK> user problems that are solved in the existing specification. SK> - Scott SK> _______________________________________________ SK> general mailing list SK> general@openid.net SK> http://openid.net/mailman/listinfo/general _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix ------_=_NextPart_001_01C6F3AC.9DA00DC8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Andy,
I think it is incredibly useful in showing the = technology=20 needed to help protect users with systems like this.  I'd love to = see it as=20 part of the Heraldry project, you are already a committer, assuming = you'd=20 be willing to contribute it.
 
--David

From: specs-bounces@openid.net=20 [mailto:specs-bounces@openid.net] On Behalf Of=20 andy.dale@ootao.com
Sent: Wednesday, October 18, 2006 = 11:44=20 PM
To: Digital Identity Exchange
Cc: Digital = Identity=20 Exchange; specs@openid.net; general@openid.net
Subject: Re: = Re[2]:=20 [dix] Re: Gathering requirements for in-browser=20 OpenIDsupport


I'd be interested to = hear if people=20 think the ph-off plugin is useful or not.... If not why not?=20

If people think it's = useful then I=20 will happily extend it and make it more usable and I will put it into = whatever=20 open source project would like to house it.

I built it as a proof of concept that it _could_ be done... Now = the=20 question of _should_ it be done :-)

http://chile.ootao.com/phoff/


Andy Dale
ooTao, Inc.

Phone: 877-213-7935
Fax:=20 877-213-7935

i-name:=20 =3DAndy.Dale
http://xri.net/=3Dandy.dale

**********************= *****************************************************
If=20 you don't have an i-name yet use this link to visit one of our partners = and buy=20 one:

 =20 http://www.ezibroker.net/partners.html

***************************= ************************************************



Chris Drake=20 <christopher@pobox.com>

10/18/2006 07:20 PM=20
Please = respond=20 to
Digital Identity Exchange=20 <dix@ietf.org>
To
Scott Kveton=20 <scott@janrain.com>=20
cc
specs@openid.net,=20 general@openid.net, Mike Glover <mpg4@janrain.com>, = Digital=20 Identity Exchange <dix@ietf.org>=20
Subject
Re[2]: [dix] Re: = Gathering=20 requirements for in-browser OpenID = support

=




Hi Scott,

All solutions for client-based MITM and = phishing=20 prevention can easily
be built on top of OpenID 2.0 if we adopt the=20 OpenIDHTTPAuth proposal.

We can then leave these people to build = their=20 tools and protection
howsoever they like, safe in the knowledge that = when=20 it's *done*,
there will be a range of new plugins that will = immediately work=20 with
all OpenID 2.0 enabled sites - and best of all - it does not = have=20 to
hold up the OpenID 2.0 development in the meantime.

The = only thing=20 we need to give to these tools is a way to get the
login process = started -=20 that is - OpenIDHTTPAuth: the downloaded
plugin needs to be able to = get an=20 entry point for the OpenID CGI code
on the web=20 site.

-----------

Here is a copy of my vote to include the = above=20 proposal, which
contains more info abut it = too:


Hi,

Why's=20 this proposal "depreciated" ?
(=20 http://www.lifewiki.net/openid/OpenIDProposals )

I'm casting my = vote=20 here:

+1 to [PROPOSAL] bare response / bare = request

Besides the=20 listed uses, it also allows IdPs to layer privacy and
delegation = easily on=20 top of OpenID, as well as permitting cool future
features (like = letting a=20 user change something at their IdP, and have
that change be "pushed = out" to=20 all relevant RPs).

This is a small and simple to implement "hook" = which I=20 believe will be
the dominating bit of OpenID protocol use in=20 future.

Alternatively - if we can standardize a way for the=20 OpenIDHTTPAuth
proposed extension to discover the RP's OpenID "entry = point"=20 [so as to
reliably eliminate the "optional" first step proposed=20 here
http://www.lifewiki.net/openid/OpenIDHTTPAuth ] - this is a=20 good
working alterative way to accommodate the "bare response" part = that=20 we
need.

So...

+1 to OpenIDHTTPAuth - on the proviso = RP's=20 publish an endpoint URL
            =  =20         that's somehow available to scripts,=20 plugins,
                =  =20     software agents that encounter OpenID login
  =  =20                  =20 pages.

                =  =20     Suggestion: (for OpenID-enabled login=20 pages):-

 <link rel=3D"openid.httpauth"=20 href=3D"http://my.rp.com/openid/blah.cgi">

-----------

<= BR>Kind=20 Regards,
Chris Drake


Thursday, October 19, 2006, 6:07:08=20 AM:

>> It is vulnerable to a man in the middle attack - the = RP,=20 instead of
>> redirecting to the IdP redirects to itself or = some other=20 site in
>> cahoots, then proxies the conversation between the = user and=20 the IdP
>> thereby compromising the users (global) credentials = as they=20 pass through.

SK> Right, we've known about this for quite some = time=20 unfortunately there hasn't
SK> be a particularly easy solution to = it and I=20 classify this as one of those
SK> "The Internet Sucks" problems. =  I'm=20 not saying we shouldn't/couldn't do
SK> anything about it I just = think the=20 right solution that mixes
SK> ease-of-implementation and user need = hasn't=20 been found yet.

>> There really needs to be user-agent = support to=20 avoid that - either
>> something CardSpace like, or browser = plugin that=20 only ever presents a
>> pre-authenticated user.

SK> I = think=20 we're headed in this direction.  However, we have to crawl before=20 we
SK> can walk.  At least solving a big chunk of the use = cases,=20 getting some
SK> momentum behind the platform and solving a = specific=20 problem for users
SK> *today* is better than trying to build the = perfect=20 tool.  We can talk and
SK> talk on these lists but we really = don't=20 know how users are going to use this
SK> stuff (or abuse it for = that=20 matter) until its out there and working in the
SK> = wild.

SK> I=20 can't emphasize more the fact that with every passing day that we=20 don't
SK> have OpenID v2.0 out the door, we're losing momentum = from fixing=20 specific
SK> user problems that are solved in the existing=20 specification.

SK> - Scott

SK>=20 _______________________________________________
SK> general = mailing=20 list
SK> general@openid.net
SK>=20 http://openid.net/mailman/listinfo/general




___________= ____________________________________
dix=20 mailing=20 list
dix@ietf.org
https://www1.ietf.org/mailman/listinfo/dix

------_=_NextPart_001_01C6F3AC.9DA00DC8-- --===============2141606242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============2141606242==-- From dix-bounces@ietf.org Thu Oct 19 14:52:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaczs-0003VD-9z; Thu, 19 Oct 2006 14:52:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaczq-0003V8-VM for dix@ietf.org; Thu, 19 Oct 2006 14:52:02 -0400 Received: from copa.geek.net.au ([203.217.18.13] helo=srve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gaczo-0007Aq-OJ for dix@ietf.org; Thu, 19 Oct 2006 14:52:02 -0400 Received: from GRUNT (203-217-18-9.perm.iinet.net.au [203.217.18.9]) by srve.com (8.13.6/8.12.11) with ESMTP id k9JIpmeg018899 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 19 Oct 2006 18:51:49 GMT Date: Thu, 19 Oct 2006 18:52:01 +1000 From: Chris Drake X-Priority: 3 (Normal) Message-ID: <927247889.20061019185201@pobox.com> To: Dick Hardt Subject: Re[4]: [dix] Re: Gathering requirements for in-browser OpenID support In-Reply-To: <1272B7BB-A670-4F00-A482-2AAE6AFAE5FC@sxip.com> References: <000d01c6f39d$3a1f4260$d27d11ac@AMSOFTWachob> <1272B7BB-A670-4F00-A482-2AAE6AFAE5FC@sxip.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.4 (+) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: 'Digital Identity Exchange' , public-usable-authentication@w3.org, Gabe Wachob , general@openid.net X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Dick: Sounds like you've got a cool extension for OpenID. Andy: We've seen and congratulate you on yours Myself: I've got one as well Here's a list with a dozen or more folks with similar:- public-usable-authentication@w3.org SO - technology that takes AWAY from the RP the opportunity to initiate the OpenID login is a good way to safely prevent MITM attacks - the only thing that remains is to nut out exactly how we want to achieve this. We need... 1. A way for a software agent to recognize an RP (and hence take the user to their real chosen IdP with chrome switched on etc) 2. A way for an IdP to initiate the login with the RP How shall we all agree to handle this? Who wants to write it up? This seems like a simple tweak to the existing "OpenIDHTTPAuth" extension, or even the "Bare Request" proposal. I think we should maybe unify all this into a single proposal - does that sounds sensible? My proposal is: RP's login page MUST contain This solves 1 & 2 since agents can tell immediately that this is an OpenID 2.0 enabled page (without the overhead of fetching yadis documents etc), and at the same time find out how to kick the login process off. For *me* - this is sufficient. Dick? Andy? I'm guessing you need something extra - maybe a flag so you know whether or not the user is already logged in?, or whether the page currently displayed is actually requesting that a new login takes place?, or perhaps some info about which identity a user selected to be logged in with: you guys know your own chrome ideas best - do you need this, or anything else? Kind Regards, Chris Drake Friday, October 20, 2006, 2:45:23 AM, you wrote: DH> Just to keep beating that dead horse some more, this demonstrates why DH> *how* to solve the issue is out of scope, but that there is an issue DH> MUST be in the spec. :-) DH> btw: that is a cool extension, but wait until you see ours! ;-) DH> -- Dick DH> On 19-Oct-06, at 9:40 AM, Gabe Wachob wrote: >> And not to beat a dead horse to a pulp, but the Ph-Off Firefox >> extension >> from OOTao provides exactly this sort of trustable (based on SSL >> certs) >> visual indicator that you are actually talking to your real OpenID >> IDP. Its >> obviously an early iteration, but it *is* there and performs the >> function >> adequately. >> >> http://chile.ootao.com/phoff/ >> >> -Gabe >> >> >>> -----Original Message----- >>> From: general-bounces@openid.net [mailto:general- >>> bounces@openid.net] On >>> Behalf Of Chris Drake >>> Sent: Thursday, October 19, 2006 9:35 AM >>> To: Dick Hardt >>> Cc: Digital Identity Exchange; general@openid.net >>> Subject: Re[2]: [dix] Re: Gathering requirements for in-browser >>> OpenID >>> support >>> >>> Hi Dick, >>> >>> I disagree - the RP is *responsible* for directing the user to the >>> IdP; This is the highest risk point of MITM attack. OpenID MUST >>> include something to "enable" a "safe redirect" or browser-chrome >>> activation or whathaveyou. Granted - chrome etc shouldn't be in the >>> spec, but *enabling* it for the future MUST. >>> >>> Kind Regards, >>> Chris Drake >>> >>> >>> Thursday, October 19, 2006, 1:56:05 PM, you wrote: >>> >>> DH> The MITM attack vector resolution is out of scope of OpenID >>> DH> Authentication as it is a ceremony between the user and the >>> IdP. The >>> DH> user and IdP need to know they are talking directly to each >>> other. >>> >>> DH> -- Dick >>> >>> DH> On 18-Oct-06, at 1:07 PM, Scott Kveton wrote: >>> >>>>>> It is vulnerable to a man in the middle attack - the RP, >>>>>> instead of >>>>>> redirecting to the IdP redirects to itself or some other site in >>>>>> cahoots, then proxies the conversation between the user and the >>>>>> IdP >>>>>> thereby compromising the users (global) credentials as they pass >>>>>> through. >>>>> >>>>> Right, we've known about this for quite some time unfortunately >>>>> there hasn't >>>>> be a particularly easy solution to it and I classify this as one of >>>>> those >>>>> "The Internet Sucks" problems. I'm not saying we shouldn't/ >>>>> couldn't do >>>>> anything about it I just think the right solution that mixes >>>>> ease-of-implementation and user need hasn't been found yet. >>>>> >>>>>> There really needs to be user-agent support to avoid that - either >>>>>> something CardSpace like, or browser plugin that only ever >>>>>> presents a >>>>>> pre-authenticated user. >>>>> >>>>> I think we're headed in this direction. However, we have to crawl >>>>> before we >>>>> can walk. At least solving a big chunk of the use cases, >>>>> getting some >>>>> momentum behind the platform and solving a specific problem for >>>>> users >>>>> *today* is better than trying to build the perfect tool. We can >>>>> talk and >>>>> talk on these lists but we really don't know how users are going to >>>>> use this >>>>> stuff (or abuse it for that matter) until its out there and working >>>>> in the >>>>> wild. >>>>> >>>>> I can't emphasize more the fact that with every passing day that we >>>>> don't >>>>> have OpenID v2.0 out the door, we're losing momentum from fixing >>>>> specific >>>>> user problems that are solved in the existing specification. >>>>> >>>>> - Scott >>>>> >>>>> _______________________________________________ >>>>> general mailing list >>>>> general@openid.net >>>>> http://openid.net/mailman/listinfo/general >>>>> >>>>> >>> >>> DH> _______________________________________________ >>> DH> general mailing list >>> DH> general@openid.net >>> DH> http://openid.net/mailman/listinfo/general >>> >>> >>> >>> _______________________________________________ >>> general mailing list >>> general@openid.net >>> http://openid.net/mailman/listinfo/general >> >> _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Oct 22 13:08:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbgo6-0002tp-AE; Sun, 22 Oct 2006 13:08:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbgo5-0002tk-1z for dix@ietf.org; Sun, 22 Oct 2006 13:08:17 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbgnv-00034c-Qd for dix@ietf.org; Sun, 22 Oct 2006 13:08:17 -0400 Received: from [192.168.1.103] (d207-6-234-158.bchsia.telus.net [207.6.234.158]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k9MH80mt015801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 22 Oct 2006 10:08:00 -0700 (PDT) (envelope-from dick@sxip.com) In-Reply-To: <927247889.20061019185201@pobox.com> References: <000d01c6f39d$3a1f4260$d27d11ac@AMSOFTWachob> <1272B7BB-A670-4F00-A482-2AAE6AFAE5FC@sxip.com> <927247889.20061019185201@pobox.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1503EA34-081C-43C7-AC2E-610DEF0030A1@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: Re[4]: [dix] Re: Gathering requirements for in-browser OpenID support Date: Sun, 22 Oct 2006 10:07:55 -0700 To: Chris Drake X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: 'Digital Identity Exchange' , public-usable-authentication@w3.org, Gabe Wachob , general@openid.net X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Hi Chris One of the features of looking at the OpenID form and detecting openid_identifier field is that we can place some a graphical element on top of the form rather then making the user goto the chrome to login. Our UX testing has found that to be really useful. Since the entrypoint is where the action is, all we needed was for RPs that wanted to use AJAX and check_imediate to have an action entry in the form that would work for browsers with JavaScript disabled, a good practice regardless. -- Dick On 19-Oct-06, at 1:52 AM, Chris Drake wrote: > > > Dick: Sounds like you've got a cool extension for OpenID. > Andy: We've seen and congratulate you on yours > Myself: I've got one as well > Here's a list with a dozen or more folks with similar:- > public-usable-authentication@w3.org > > SO - technology that takes AWAY from the RP the opportunity to > initiate the OpenID login is a good way to safely prevent MITM > attacks - the only thing that remains is to nut out exactly how we > want to achieve this. > > We need... > 1. A way for a software agent to recognize an RP (and hence take the > user to their real chosen IdP with chrome switched on etc) > 2. A way for an IdP to initiate the login with the RP > > How shall we all agree to handle this? Who wants to write it up? > This seems like a simple tweak to the existing "OpenIDHTTPAuth" > extension, or even the "Bare Request" proposal. I think we should > maybe unify all this into a single proposal - does that sounds > sensible? > > My proposal is: > RP's login page MUST contain > > > > This solves 1 & 2 since agents can tell immediately that this is an > OpenID 2.0 enabled page (without the overhead of fetching yadis > documents etc), and at the same time find out how to kick the login > process off. For *me* - this is sufficient. Dick? Andy? I'm guessing > you need something extra - maybe a flag so you know whether or not the > user is already logged in?, or whether the page currently displayed is > actually requesting that a new login takes place?, or perhaps some > info about which identity a user selected to be logged in with: you > guys know your own chrome ideas best - do you need this, or anything > else? > > Kind Regards, > Chris Drake > > > Friday, October 20, 2006, 2:45:23 AM, you wrote: > > DH> Just to keep beating that dead horse some more, this > demonstrates why > DH> *how* to solve the issue is out of scope, but that there is an > issue > DH> MUST be in the spec. :-) > > DH> btw: that is a cool extension, but wait until you see ours! ;-) > > DH> -- Dick > > DH> On 19-Oct-06, at 9:40 AM, Gabe Wachob wrote: > >>> And not to beat a dead horse to a pulp, but the Ph-Off Firefox >>> extension >>> from OOTao provides exactly this sort of trustable (based on SSL >>> certs) >>> visual indicator that you are actually talking to your real OpenID >>> IDP. Its >>> obviously an early iteration, but it *is* there and performs the >>> function >>> adequately. >>> >>> http://chile.ootao.com/phoff/ >>> >>> -Gabe >>> >>> >>>> -----Original Message----- >>>> From: general-bounces@openid.net [mailto:general- >>>> bounces@openid.net] On >>>> Behalf Of Chris Drake >>>> Sent: Thursday, October 19, 2006 9:35 AM >>>> To: Dick Hardt >>>> Cc: Digital Identity Exchange; general@openid.net >>>> Subject: Re[2]: [dix] Re: Gathering requirements for in-browser >>>> OpenID >>>> support >>>> >>>> Hi Dick, >>>> >>>> I disagree - the RP is *responsible* for directing the user to the >>>> IdP; This is the highest risk point of MITM attack. OpenID MUST >>>> include something to "enable" a "safe redirect" or browser-chrome >>>> activation or whathaveyou. Granted - chrome etc shouldn't be in >>>> the >>>> spec, but *enabling* it for the future MUST. >>>> >>>> Kind Regards, >>>> Chris Drake >>>> >>>> >>>> Thursday, October 19, 2006, 1:56:05 PM, you wrote: >>>> >>>> DH> The MITM attack vector resolution is out of scope of OpenID >>>> DH> Authentication as it is a ceremony between the user and the >>>> IdP. The >>>> DH> user and IdP need to know they are talking directly to each >>>> other. >>>> >>>> DH> -- Dick >>>> >>>> DH> On 18-Oct-06, at 1:07 PM, Scott Kveton wrote: >>>> >>>>>>> It is vulnerable to a man in the middle attack - the RP, >>>>>>> instead of >>>>>>> redirecting to the IdP redirects to itself or some other site in >>>>>>> cahoots, then proxies the conversation between the user and the >>>>>>> IdP >>>>>>> thereby compromising the users (global) credentials as they pass >>>>>>> through. >>>>>> >>>>>> Right, we've known about this for quite some time unfortunately >>>>>> there hasn't >>>>>> be a particularly easy solution to it and I classify this as >>>>>> one of >>>>>> those >>>>>> "The Internet Sucks" problems. I'm not saying we shouldn't/ >>>>>> couldn't do >>>>>> anything about it I just think the right solution that mixes >>>>>> ease-of-implementation and user need hasn't been found yet. >>>>>> >>>>>>> There really needs to be user-agent support to avoid that - >>>>>>> either >>>>>>> something CardSpace like, or browser plugin that only ever >>>>>>> presents a >>>>>>> pre-authenticated user. >>>>>> >>>>>> I think we're headed in this direction. However, we have to >>>>>> crawl >>>>>> before we >>>>>> can walk. At least solving a big chunk of the use cases, >>>>>> getting some >>>>>> momentum behind the platform and solving a specific problem for >>>>>> users >>>>>> *today* is better than trying to build the perfect tool. We can >>>>>> talk and >>>>>> talk on these lists but we really don't know how users are >>>>>> going to >>>>>> use this >>>>>> stuff (or abuse it for that matter) until its out there and >>>>>> working >>>>>> in the >>>>>> wild. >>>>>> >>>>>> I can't emphasize more the fact that with every passing day >>>>>> that we >>>>>> don't >>>>>> have OpenID v2.0 out the door, we're losing momentum from fixing >>>>>> specific >>>>>> user problems that are solved in the existing specification. >>>>>> >>>>>> - Scott >>>>>> >>>>>> _______________________________________________ >>>>>> general mailing list >>>>>> general@openid.net >>>>>> http://openid.net/mailman/listinfo/general >>>>>> >>>>>> >>>> >>>> DH> _______________________________________________ >>>> DH> general mailing list >>>> DH> general@openid.net >>>> DH> http://openid.net/mailman/listinfo/general >>>> >>>> >>>> >>>> _______________________________________________ >>>> general mailing list >>>> general@openid.net >>>> http://openid.net/mailman/listinfo/general >>> >>> > > > > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix