Re: encoding newlines in attribute values
On Apr 19, 2007, at 10:46 AM, Josh Hoyt wrote: On 4/19/07, Marius Scurtescu [EMAIL PROTECTED] wrote: I think we do need pre-URL-encoding, mainly because of signatures. In order to calculate the signature the parameters must be put together in a special way and new line characters are not allowed. Yes. The key-value encoding that's used for POST responses (to associate and check_authentication) is also used in signature generation. This is the source of the restriction on newlines in values, not anything to do with URL encoding. Each attribute already has to define its encoding rules and data- type. The mechanism for encoding a newline can be part of this encoding, if newlines are allowed in the value. Once there is one attribute that has a defined encoding for newline, when new attributes are defined, they can re-use this encoding. Does that sound reasonable? That sounds fair, however consistent encoding methods with a standardized syntax should be recommended. Elements like icons, voice, signatures blobs could adopt some type of standardized an overlay template. -Doug ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Fwd: PROPOSAL schema.openid.net for AX (and other extensions)
On Apr 9, 2007, at 9:45 AM, Brian Hernacki wrote: For what it's worth, as an implementer... I think it makes sense to come to agreement within the OpenID community and get something working first. While I appreciate the issues involved with having multiple protocols and attribute definitions, I worry that if this becomes coupled to other efforts it would cause delays. Better to at least come to that table with a sound version of what we think works. Given that, discussing it here (openid.net) seems natural. Register profile field names. Fields placed within a profile should not be affected by additional requests made by various websites. Allow each website to query for additional information when needed. Establish a registry for profile field names, and allow users to add to their profile based upon prescribed fields supported by the OP. Don't use the OP as a repository for adhoc additional information that is requested at each site with an intent to share this information! This will lead to a greater amount of information being shared than intended. Such a feature will surely create compatibility issues, especially when there are many ways to establishing this dubious feature. -Doug ___ 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
Label replacing Key
On Sat, 2007-04-07 at 08:58 -0700, Douglas Otis wrote: Oops. I missed two references to keys. --- 4.1. Protocol Messages The OpenID Authentication protocol messages are mappings of plain-text labels to plain-text values. The labels and values permit the full Unicode character set (UCS). When the labels 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Label replacing Key
On Sat, 2007-04-07 at 10:30 -0700, Josh Hoyt wrote: On 4/7/07, Douglas Otis [EMAIL PROTECTED] wrote: This would then require all locations that use the term key when referring to a field label to be changed to label -1 If it needs to be changed, Martin's suggestion of name instead is much better. Okay, but the use of name should be explicitly defined. The use of just name creates some ambiguity with the name attribute. Review sections 5.2.2. and 7.1.. Or with DNS name in 9.2. and and 12. The OpenID draft refers to the field name and to the right most labels of the field name as being synonymous with key. This short-hand should be clearly defined using other terms. Key is not a term used in w3.org definitions, that tend to use the all encompassing keyword instead. Key normally refers to keyboard keys, or cryptographic keys. Unfortunately Name does not permit an explicit definition due to conflicts within the spec and the ambiguity when using subordinate naming elements. note: rfc2822 (2.2.) for email defines roughly the same structure as field name followed by a field body. rfc1034 (3.1.) for dns defines names as a tree structure of labels. How about: Additional terms clarified within the terminology section such as: --- 2. Terminology ... Attribute: Attributes hold associated properties of HTML elements and may have values. Attribute/value pairs appear before the final of an element's start tag. Any number of (legal) attribute value pairs, separated by spaces, may appear in any order within an element's start tag. Message Parameter: Message Parameters are in Field Name-Value Form as a sequence of lines terminated by a single newline (UCS codepoint 10, \n). Each line begins with a field name, followed by a colon, and a single value or a comma separated list associated with the field name. Short Name: A Short Name is resolved by removing or assuming an openid prefix of an associated Field Name. --- --- 4.1. Protocol Messages The OpenID Authentication protocol messages parameters are mappings of plain-text field names to plain-text field values. The field names and field values permit the full unicode character set (UCS). When the field names and field 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 values within the same field name. Throughout this document, all OpenID message parameters are REQUIRED, unless specifically marked as OPTIONAL. 4.1.1. Field Name-Value Form Encoding A message in Field Name-Value Form is a sequence of lines. Each line begins with a field name, followed by a colon, and the field value associated with the field name. The line is terminated by a single newline (UCS codepoint 10, \n). A field name or field value MUST NOT contain a newline and a field name 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. A Short Name-Value Form of encoding is used for signature calculation and for direct responses(Direct Response) to Relying Parties. See sections 5.1.2, 5.1.2.2, 6.1, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 11.4.2.2. --- This change requires all locations that use the term key when referring to a field name to be changed to field name. When referring to a derived short name to be changed to short name. -Doug ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Label replacing Key
On Sat, 2007-04-07 at 18:22 -0700, Douglas Otis wrote: Oops. 4.1. Protocol Messages (second paragraph) Messages MUST NOT contain multiple values within the same field name. Messages MUST NOT contain message parameters with the same field name. -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 http
Re: Server-to-server channel
On Wed, 2007-04-04 at 20:02 +, Vinay Gupta wrote: On Apr 4, 2007, at 7:43 PM, Douglas Otis wrote: Hm. Well, I don't to suggest that we tear off fixing or expressing the whole semantics of PKI, but I do think that some care should be taken to make sure that it's clear what the security status of a returned key is. Problems like Confused Deputy can easily arise when you start dealing with registry systems which aren't under really tight control. I don't have a neatly packaged solution for this, but we're dealing with situations which can have very significant legal repercussions: digital signatures are legal for some kinds of transactions in some jurisdictions, and however this is handled is has to have some approach to the questions of what is they key good for, and who says OpenID appears fairly prone to phishing exploits, as it expects a user to pay close attention to where they end up and the other URL involved. OpenID could evolve into offering public keys during the initial logins along with other identity attributes that could help solve this problem. The RP could retain keys for some period since last use to suppress the number of times OpenID is invoked. Rather than an expiry, the attribute might want to be defined differently. Some key agent would be needed that replicates the authentication process now available using SSH. This does not depend upon certificates, but rather a simple list of public keys. Once this concept becomes routine, other applications will likely include this mode of operation where identifying the application becomes important. This would _not_ be a certificate as you seem to imply. Try to keep it simple, but if an attribute can include a Time to Live or Expiry parameter, then it would be nice to have a class of attributes identified as public keys with sub-attributes for the application, where the default would be some OpenID compliant HTTP access scheme. An application that would not require development, other than maintaining a list of keys, would be SSH. Although perhaps too complex for the average user, SSH could also be used to authenticate web access. This is standard for any Unix based OS, and could be found by using Putty and Pageant on a Windows platform. There is even an interesting version of this that runs from a USB flash: http://www.chiark.greenend.org.uk/%7Esgtatham/putty/ 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. -Doug ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On Apr 4, 2007, at 12:45 AM, Martin Atkins wrote: Anders Feder wrote: Imagine an RP requesting your bank account number X from your OP. Time goes by, and your OP goes out of business. Later, you switch banks and your account number X is assigned to someone else. In the meantime, the RP has been preparing a payment for a job you have done for them. The RP look up your account number in its database, and see X. And since the RP has not received any updates to your bank account information, it reasons that your account number is still X and consequently disburse your payment on a stranger's account ... The age of the information needs to be taken into account here. If information is old, then the RP would presumably be hesitant to act on it without verification. What constitutes old information depends on the attribute... things like Full Name are, for many people, changed never or at most once in their lives. However, things like a credit card number tend to change every few years as cards expire. Some information has a built-in expiry date (such as credit card details), while other information just has a likelyhood of change. This implies to me that the following three things are needed: * The possibility of a hard expiry date on a particular piece of information. * soft expiry dates which are more like refresh this every n months, where the RP gets less and less convinced about the accuracy of the data as it ages, but may continue to use it for some time even when it's a bit old. * The ability for an RP to request a refresh of attributes it stores without necessarily including the user in the transaction. (The user presumably will have made approval/revoking decisions out of band at an earlier time.) This may seem to be off topic, but I really don't see reluctance in using public key cryptography. DKIM would be one such example. Nearly every gateway, and access point can utilize this means of authentication. Think of this as yet another means to control an account without relying upon OpenID. OpenID opens the door, where you then hand them your public key. One might also wish to specifically define attributes containing public keys used by the identity. This would be information uploaded by the individual after creating their id_rsa.pub key information using either system tools or specialized applications. This would provide an alternative access method that would not rely upon OpenID exchanges. Here again, an expiry might prove handy, and so would a means to revoke the key. Perhaps this would be done by overlaying it. There could be keys used to authorize some other automated service, or to act as a replacement for OpenID once the key has been established. One might be defined for email, IM, VoIP, etc. -Doug ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On Apr 4, 2007, at 11:44 AM, Vinay Gupta wrote: On Apr 4, 2007, at 6:13 PM, Douglas Otis wrote: There could be keys used to authorize some other automated service, or to act as a replacement for OpenID once the key has been established. One might be defined for email, IM, VoIP, etc. It's not the public key management in a scheme like this that concerns me... Two issues: private key management - are the keys scattered, like your VOIP key lives in Gizmo, and your SSH key lives in your .ssh, and so on? Or do we by logical extension begin to impose some order here and have one key pair per person... you see where this goes, right? Related services that can be enabled by using OpenID as a key distribution scheme. Keys would need to relate to services handled by the consumer or RP. A sub-attribute could help facilitate correct placement of the keys and to allow different keys for different purposes. Secondly X509 certificates are very, very broken in terms of delegation semantics and certification semantics (at least in many people's eyes, mine included.) So.. SPKI? (yes, I've been over this territory and that's pretty much what I'm doing here.) How these keys are handled internally could be left to the consumer or RP. Either the OpenID server or the Consumer or RP could fashion their own certs based upon this information where it is administered and integrated with other services. The individual end-user would only need to submit their set of public keys for this to become possible. -Doug ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
