RE: attribute exchange value encoding
I agree with Claus. We may not need a base64 type. Guoping -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Claus Färber Sent: Tuesday, May 29, 2007 3:33 AM To: specs@openid.net Subject: Re: attribute exchange value encoding Johnny Bufu schrieb: The attribute metadata can be used to define attribute-specific encodings, which should deal with issues like this. Ah, so the _usual_ way is that the metadata (Can this be renamed to datatype definition? metadata is very misleading.) defines the encoding. For binary data, it will be base64Binary or hexBinary as defined in XML schema. Correct? The AX protocol has to stay simple (that was overwhelming feedback I've received at IIW). The base64 encoding is there as a convenience: if a number of OPs and RPs agree on an attribute type (the classical example being an avatar image) but don't want to go to the trouble of publishing metadata information, In other words: The metadata is implicitly agreed upon by the parties involved. If they can agree on the meaning and the base format (integer, string, *binary,...) they can also agree on an encoding (e.g. agree on base64Binary instead of *binary). So I don't think AX needs means to flag base64 data. The parties involved should know when base64Binary or hexBinary is used by out of band information (metadata/datatype definition or mutual agreement). In other words, AX should just restrict values to UTF-8 strings and recommend base64Binary (or hexBinary) for datatypes (datatypes, not data!) that can't be represented as UTF-8 strings. Claus ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: attribute exchange value encoding
Johnny: I have a couple comments on Section 3.3.2 Default Encoding of a Binary Value. First, the character set of standard Base64 encoding is not URL-safe. Specifically, '+', '/' and '=' need to be URL-encoded. So, we need to URL-encode the value after base64 encoding. Secondly, different platforms may have different binary formats for a given type of objects. There may be interoperability issues with binary values across different platforms. We may want to use a string representation of an object instead of its binary representation, like in any XML document. For example, for an integer value 1234 of attribute x we have openid.ax.x=1234. With this we will not need base64 encoding. But, we will still need URL-encoding. Regards, Guoping -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johnny Bufu Sent: Thursday, May 24, 2007 6:16 PM To: OpenID specs list Subject: attribute exchange value encoding Hello list, While at IIW, I asked around what people thought about the encoding mechanisms we've added recently, in order to allow for transferring any data types. The consensus was that everyone would prefer something simpler and lighter. So I've rewritten the encoding section, such that: - for strings, only the newline (and percent) characters are required to be escaped, (to comply with OpenID's data formats), using percent-encoding; - base64 must be used for encoding binary data, and defined an additional field for this: openid.ax.encoding.alias=base64 Please review section 3.3 Attribute Values to see if there are any issues. One remaining question is about the choice of encoding for strings. Percent-encoding (RFC3968) seems the simplest from a spec perspective, however some libraries provide (better) support for the older URL-encoding (RFC1738), which throws '+' characters into the mix. Which do you think would work best for implementers, users, and would cause less interop problems? Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Proposal for improved security of association establishment in OpenID2.0
Hans: Thank you for your comments. I agree with you that not vulnerable to *this* man in the middle attack is more accurate. Regards, Guoping -Original Message- From: Granqvist, Hans [mailto:[EMAIL PROTECTED] Sent: Friday, May 18, 2007 10:14 AM To: Guoping Liu; OpenID specs list Subject: RE: Proposal for improved security of association establishment in OpenID2.0 Guoping Liu: Nice write-up! A comment though: This is a common MITM problem with DH key exchange. It seems if the MAC key was derived somehow from the negotiated secret, then this attack would not be possible. I never really grokked the XOR 'encryption' step, apart from its ease of implementation and what seemed reasonable protection, both of great value. Perhaps some early spec writers (Brad?) can shed some light? Was there ever a discussion pre 1.x on using a MAC key derived from (or maybe even being!) the negotiated secret, and if so, what's the weakness? Am I missing something obvious? Thanks, Hans PS. We are NOT sending the MAC key over and are not vulnerable to man in the middle attacks. Gutsy statement! Maybe not vulnerable to *this* man in the middle attack would be safer? ;) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guoping Liu Sent: Thursday, May 17, 2007 11:53 AM To: OpenID specs list Subject: Proposal for improved security of association establishment in OpenID2.0 Issue: Vulnerability to man-in-the-middle attacks The association algorithm with DH-SHA1 and DH-SHA256 defined in the draft 11 is vulnerable to man-in-the-middle attacks if server authentication with HTTPS is not used. Here is how: A RP sends an associate request an OP with following parameters: openid.dh_modulus = base64(btwoc(p)) openid.dh_gen = base64(btwoc(g)) openid.dh_consumer_public = base64(btwoc(g ^ xa mod p)) A middle man M intercepts the request. M then generates xc, creates a new request to the OP with following parameters: openid.dh_modulus = base64(btwoc(p)) openid.dh_gen = base64(btwoc(g)) openid.dh_consumer_public = base64(btwoc(g ^ xc mod p)) The OP receives the request from M and sends following response to M dh_server_public = base64(btwoc(g ^ xb mod p)) enc_mac_key = base64(H(btwoc(g ^ (xc * xb) mod p)) XOR MAC_key) M decrypts the MAC_key as follows: MAC_key = H(btwoc(g ^ (xc * xb) mod p)) XOR enc_mac_key M then sends a response to the RP with following parameters: dh_server_public = base64(btwoc(g ^ xc mod p)) enc_mac_key = base64(H(btwoc(g ^ (xc * xa) mod p)) XOR MAC_key) Now, the RP, middle man M and OP all have the same MAC_key. Proposed Solution: Do not send enc_mac_key in response. Both OP and RP generate a MAC key as follows H(btwoc(g ^ (xa * xb) mod p)) We are NOT sending the MAC key over and are not vulnerable to man in the middle attacks. Guoping Liu ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
