Re: password-free login without SSL and OP reliance (an anti-phishing solution)
Douglas Otis wrote: 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. While I believe that key-value pairs is a common enough term that confusion is unlikely by any knowledgeable developer, I suggest that if it be changed it be changed to name-value form encoding, since I think this is more commonly used than keyword-value. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: password-free login without SSL and OP reliance (an anti-phishing solution)
On Sat, 2007-04-07 at 11:43 +0100, Martin Atkins wrote: Douglas Otis wrote: 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. While I believe that key-value pairs is a common enough term that confusion is unlikely by any knowledgeable developer, I suggest that if it be changed it be changed to name-value form encoding, since I think this is more commonly used than keyword-value. For me, he term key-value was a bit confusing because it was not explicit. This term key currently refers to either fields or sub-fields in sections- 4.1.2., 5.1.1., 5.1.2., 5.1.2.2., 5.2., 7.1., 10.1., 11.2., 11.4.1., 11.4.2.1., 14.2., 15.1.2. There are sub-fields identified as name where the term name would get confusing in section 5.2.2., 7.1., 9.2., 12. and A.5. How about this: --- 4.1. Protocol Messages The OpenID Authentication protocol messages are mappings of plain-text labels to plain-text values. The keys and values permit the full Unicode character set (UCS). When the keys and values need to be converted to/from bytes, they MUST be encoded using UTF-8(Yergeau, F., “UTF-8, a transformation format of Unicode and ISO 10646,” .) [RFC3629]. Messages MUST NOT contain multiple parameters with the same label. Throughout this document, all OpenID message parameters are REQUIRED, unless specifically marked as OPTIONAL. 4.1.1. Label-Value Form Encoding A message in Label-Value form is a sequence of lines. Each line begins with a field label, followed by a colon, and the value associated with the label. The line is terminated by a single newline (UCS codepoint 10, \n). A label or value MUST NOT contain a newline and a label also MUST NOT contain a colon. Additional characters, including whitespace, MUST NOT be added before or after the colon or newline. The message MUST be encoded in UTF-8 to produce a byte string. Label-Value Form encoding is used for signature calculation and for direct responses(Direct Response) to Relying Parties. For brevity, this specification may refer to sub-components of the label. For example, the field label openid.mode may be referenced as just mode. --- This would then require all locations that use the term key when referring to a field label to be changed to label. -Doug ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
password-free login without SSL and OP reliance (an anti-phishing solution)
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
