Doug, I'd like to work through this approach with you in some detail offline. The project I'm currently working on is about biometric digital identity in the developing world, and one of the pieces we're looking at is nation-state-at-a-time deployment of an extremely simplified public key infrastructure.
I'm going to need to sit down with your proposal in a great deal of detail, reread some kerberos docs, and hopefully I'll have something more concrete for you next week. Vinay -- Vinay Gupta - Designer, Hexayurt Project - an excellent public domain refugee shelter system Gizmo Project VOIP: 775-743-1851 (usually works!) Cell: Iceland (+354) 869-4605 http://howtolivewiki.com/hexayurt - old http://appropedia.org/ Hexayurt_Project - new Skype/Gizmo/Gtalk: hexayurt I have a proof which unfortunately this signature is too short On Apr 7, 2007, at 2:59 AM, Douglas Otis wrote: > > On Apr 5, 2007, at 3:49 AM, Vinay Gupta wrote: >> On Apr 5, 2007, at 10:40 AM, Douglas Otis wrote: >> >>> Although the world demands GUI, terminal interfaces already offer >>> a powerful set of tools for doing exactly what is needed. Public >>> key cryptography reduces the overhead and security concerns >>> substantially. This may also provide an alternative for rather >>> complex OpenID extensions that will likely over reach with >>> respect to security. >> >> The literature on both Capability Based Operating Systems and >> Kerberos should be considered pretty closely here. It's very easy >> to design systems which are subject to man in the middle attacks >> and replay attacks, and the semantics of security are equally >> important (like "what did the user just cryptographically >> authorize? they thought they authorized access to their name, but >> the request lied about what it was for...") >> >> Kerberos has an exquisite design for handling network >> authentication and should probably be considered as a template for >> subsequent systems. It is old and well examined, and still >> trusted. Perhaps it would make sense to implement Kerberos over >> OpenID to solve some or all of these security problems? > > To automate secure access between servers, kerberos provides > centralized access control by containing all client's secrets. > Shared secrets and a centralized point of failure are sizable flaws > for large scale deployment. In addition, OpenID is prone to > downgrade attacks should acknowledgment become automated. OpenID > depends upon phishing prone wet-ware to authenticate URL queries > and the SSL certificate of the OP. > > That said, OpenID overcomes administering replicate signup > processes, where each user and website is expected to remember user- > names and passwords. The user-name/password approach is fairly > prone to phishing attacks, where OpenID's use of redirection > actually increases this vulnerability which may then affect all > websites that the user accesses in this manner. In addition, > without an alternative means of access, users are required to > maintain a domain in order to delegate OPs as a means to ensure > continued access. This would be very important when an OP is DoS > attacked or when an OP goes out of service. Otherwise, OpenID > remains a dangerous convenience where a user-name/password must > still be established as an alternative method for each account. > > All of these problems are overcome by adding an optional extension > to OpenID. > > For clarity, OpenID Authentication 2.0 - Draft 11 "4.1.1. Key-Value > Form Encoding" should change to something like "Keyword-Value Form > Encoding". Avoid using the word "key" to mean field or label. > This will cause confusion. > > Here is a rough outline: > > 1) OpenID defines an OP response field openid.rsa_pub, obtained > from its user's profile containing a SSH2 public key. > > 2) The RP may retain this public key and signal the user-agent by > offering an OpenID key-symbol button for posting a value obtained > from a "openid.key-auth" URI defining a file whose content verifies > that the identity of the user-agent has been authenticated in the > process of obtaining this file. The size of this file should be > less that 256 bytes. > > 3) The user-agent obtains the "openid.key-auth" file's content and > posts this as a response when the OpenID key-symbol button is > pressed, instead of the OpenID login button. > > This scheme would depend upon the same host and client key pairs as > used for ssh, scp, sftp, etc. The following is a hack to allow > direct utilization of SCP. The OpenID identity is converted to a > SHA-1 hash translated to a base64 character string prefaced with > OpenID. This would require operating systems able to handle 38 > character user names. This hash locates a repository for where > keys are concatenated. An MD5 hash of the OpenID identity further > defines the path component below .openid/ for the authentication > value. As some point in the future, verification of host and > client keys should be done in-band. The location of the > "openid.key-auth" should not change and be within the RP domain, > but this is not a requirement. > > When a different OpenID identity is desired to obtain access to an > account on an RP, the user would still be able to login using the > OpenID key access method, and then request that the account be > associated with a different OpenID after verifying the other OpenID > identity. This would eliminate the need to delegate OpenID OPs for > an orderly transition to a different identity. > > This method eliminates: > - redirection for subsequent accesses > - man-in-the middle attacks > - continuous dependence upon the OP > - dedicating a domain for delegation > - most key entry related threats > - phishing attacks > > To work with Windows, a little putty is needed :) > http://www.chiark.greenend.org.uk/%7Esgtatham/putty/ > > -Doug _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
