<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">This is an old thread but I will bite.<div><br></div><div>DH should not be required for transport encrypted association sessions.</div><div><br></div><div>The DH parameters in the spec have defaults but they are not fixed.</div><div><br></div><div>Yahoo and others believe that doing DH without fixed parameters could lead to a denial of service attack,</div><div>one of the reasons they don't do DH.</div><div><br></div><div>Yes we should probably fix the parameters if we continue to allow associations over non-ssl connections, or insist on validation by the OP.</div><div>Some people would be happy to ditch DH completely.</div><div><br></div><div>This should be discussed as part of 2.1.</div><div><br></div><div>That however is separate from the question of the RP contributing to the entropy of the shared secret.</div><div><br></div><div>That is not in the current spec. Perhaps it should be added to 2.1 I wouldn't have a problem with that.</div><div><br></div><div>I think that was the topic of the original thread.</div><div><br></div><div>John Bradley</div><div><br></div><div><div><div>On 15-May-09, at 4:27 PM, Breno de Medeiros wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>It is completely impractical (from a performance perspective) for an<br>RP to validate parameters generated by an OP on the fly.<br><br>For that reason, I think exchanges over plain HTTP should stick to the<br>parameters in the spec. If the spec has bad parameters then it is time<br>to change them. Or if OPs want to choose their parameters, then there<br>is a need to publish them in the discovery spec.<br><br><br><br>On Fri, Mar 20, 2009 at 9:19 AM, John Bradley <<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>> wrote:<br><blockquote type="cite"><Inline><br></blockquote><blockquote type="cite">On 20-Mar-09, at 6:57 AM, Ben Laurie wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">On Thu, Mar 19, 2009 at 7:37 PM, John Bradley <<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Ben,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The shared secret for an association is determined by the OP the RP<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">contributes nothing to the entropy of the shared secret.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><Snip><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The Relying party sends p as openid.dh_modulus and g as openid.dh_gen in<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">request.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The OP returns base64(btwoc(g ^ xb mod p) as openid.dh_gen and<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">base64(H(btwoc(g ^ (xa * xb) mod p)) XOR MAC key) as enc_mac_key.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">There is no advice about using p or g as part of the process for<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">generating<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">enc_mac_key.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Now that we have lost everyone, the bad news is that the spec has g = 2<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">and<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">p as DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61E<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">F75A2E27898B057F9891C2E27A639C3F29B60814581CD3B2CA3986D268370557<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">7D45C2E7E52DC81C7A171876E5CEA74B1448BFDFAF18828EFD2519F14E45E382<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">6634AF1949E5B535CC829A483B8A76223E5D490A257F05BDFF16F2FB22C583AB<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Yes g and p are invariant across all association requests.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">That doesn't sound like the bad news to me. What sounds bad is that g<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and p are allowed to _not_ be invariant! Even worse, there's no<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">suggestion that they should be checked for validity (e.g. that p<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">really is prime and g really is a generator - RFC 2631 actually wants<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">a bit more than that).<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">And worse still, the default value of g does not conform to RFC 2631<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and p cannot be verified to conform without more information!<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><snip><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The 2.0 spec requires the RP to send g and p to the OP in the association<br></blockquote><blockquote type="cite">request.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">In Sec 8.1.2<br></blockquote><blockquote type="cite">For p the default is the prime number above as listed in Appendix B.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">For g the default is suggested to be 2<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The value of base64(btwoc(g ^ xa mod p)) is also sent in<br></blockquote><blockquote type="cite">openid.dh_consumer_public<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The only spec guidance to the OP on how to interpret this is in Sec 8.4.2<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The Relying Party specifies a modulus, p, and a generator, g. The Relying<br></blockquote><blockquote type="cite">Party chooses a random private key xa and OpenID Provider chooses a random<br></blockquote><blockquote type="cite">private key xb, both in the range [1 .. p-1]. The shared secret used to<br></blockquote><blockquote type="cite">encrypt the MAC key is thus g ^ (xa * xb) mod p = (g ^ xa) ^ xb mod p = (g ^<br></blockquote><blockquote type="cite">xb) ^ xa mod p. For more information, see [RFC2631]. For information on the<br></blockquote><blockquote type="cite">selection of random values, see [RFC1750].<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">People creating RP libraries seem to be using the defaults from the spec.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">We need an OSIS test to see if they are, or are perhaps choosing other<br></blockquote><blockquote type="cite">values. I think choosing alternate values as long as they are valid is<br></blockquote><blockquote type="cite">allowed by the spec, however sending invalid values should be a fail.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">For OPs there is not much guidance other than the references to RFC2631 and<br></blockquote><blockquote type="cite">RFC1750.<br></blockquote><blockquote type="cite">The spec states the OP should use the values sent by the RP.<br></blockquote><blockquote type="cite">Possible OSIS testes are:<br></blockquote><blockquote type="cite">1 Is the OP accepting alternate values for p and g from the RP for its<br></blockquote><blockquote type="cite">calculation. If they have hardcoded the defaults and return a result based<br></blockquote><blockquote type="cite">on them that would be a fail.<br></blockquote><blockquote type="cite">2 is the OP rejecting associations with values other than the defaults.<br></blockquote><blockquote type="cite"> This would be against the spec but is perhaps a reasonable action by a OP<br></blockquote><blockquote type="cite">defending itself against possible Denial of service attacks.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">If others have testing ideas around DH (other than removing it from the<br></blockquote><blockquote type="cite">spec) Please get back to me.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I understand some peoples desire to just remove it, however I think it is<br></blockquote><blockquote type="cite">valuable in a number of circumstances.<br></blockquote><blockquote type="cite">So I prefer to make certain that it works as well as it can in the shipping<br></blockquote><blockquote type="cite">implementations.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I will also note that the current implementation is not doing much to stop<br></blockquote><blockquote type="cite">MITM attacks, given that the DH is just used to encrypt the secret during<br></blockquote><blockquote type="cite">the association reply and has nothing to do with the secret itself.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I personally do not see the DH encryption of the OP's secret as<br></blockquote><blockquote type="cite">incrementally adding anything to the transport encryption in the current<br></blockquote><blockquote type="cite">implementation. A different implementation where the shared secret itself<br></blockquote><blockquote type="cite">is generated using DH would be MTIM resistant, however that is not what we<br></blockquote><blockquote type="cite">have in the current spec.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">If Ben or others want to propose a improved method of generating shared<br></blockquote><blockquote type="cite">secrets that could be added to 2.1 but I am not seeing a lot of people<br></blockquote><blockquote type="cite">asking for it.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Regards<br></blockquote><blockquote type="cite">John Bradley<br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">general mailing list<br></blockquote><blockquote type="cite"><a href="mailto:general@openid.net">general@openid.net</a><br></blockquote><blockquote type="cite"><a href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><br><br><br>-- <br>--Breno<br><br>+1 (650) 214-1007 desk<br>+1 (408) 212-0135 (Grand Central)<br>MTV-41-3 : 383-A<br>PST (GMT-8) / PDT(GMT-7)<br></div></blockquote></div><br></div></body></html>