[OpenID] D-H vs SSL

Fri May 15 20:27:04 UTC 2009

It is completely impractical (from a performance perspective) for an
RP to validate parameters generated by an OP on the fly.

For that reason, I think exchanges over plain HTTP should stick to the
parameters in the spec. If the spec has bad parameters then it is time
to change them. Or if OPs want to choose their parameters, then there
is a need to publish them in the discovery spec.

On Fri, Mar 20, 2009 at 9:19 AM, John Bradley <john.bradley at wingaa.com> wrote:
> <Inline>
> On 20-Mar-09, at 6:57 AM, Ben Laurie wrote:
>
>> On Thu, Mar 19, 2009 at 7:37 PM, John Bradley <john.bradley at wingaa.com>
>> wrote:
>>>
>>> Ben,
>>>
>>> The shared secret for an association is determined by the OP the RP
>>> contributes nothing to the entropy of the shared secret.
>>>
> <Snip>
>>>
>>> The Relying party sends p as openid.dh_modulus and g as openid.dh_gen in
>>> the
>>> request.
>>> The OP returns base64(btwoc(g ^ xb mod p) as openid.dh_gen and
>>> base64(H(btwoc(g ^ (xa * xb) mod p)) XOR MAC key) as  enc_mac_key.
>>>
>>> There is no advice about using p or g as part of the process for
>>> generating
>>> enc_mac_key.
>>>
>>> Now that we have lost everyone, the bad news is that the spec has g = 2
>>> and
>>> p as DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61E
>>> F75A2E27898B057F9891C2E27A639C3F29B60814581CD3B2CA3986D268370557
>>> 7D45C2E7E52DC81C7A171876E5CEA74B1448BFDFAF18828EFD2519F14E45E382
>>> 6634AF1949E5B535CC829A483B8A76223E5D490A257F05BDFF16F2FB22C583AB
>>>
>>> Yes g and p are invariant across all association requests.
>>
>> That doesn't sound like the bad news to me. What sounds bad is that g
>> and p are allowed to _not_ be invariant! Even worse, there's no
>> suggestion that they should be checked for validity (e.g. that p
>> really is prime and g really is a generator - RFC 2631 actually wants
>> a bit more than that).
>>
>> And worse still, the default value of g does not conform to RFC 2631
>> and p cannot be verified to conform without more information!
>
> <snip>
>
> The 2.0 spec requires the RP to send g and p to the OP in the association
> request.
>
> In Sec 8.1.2
> For p the default is the prime number above as listed in Appendix B.
>
> For g the default is suggested to be 2
>
> The value of base64(btwoc(g ^ xa mod p)) is also sent in
> openid.dh_consumer_public
>
> The only spec guidance to the OP on how to interpret this is in Sec 8.4.2
>
> The Relying Party specifies a modulus, p, and a generator, g. The Relying
> Party chooses a random private key xa and OpenID Provider chooses a random
> private key xb, both in the range [1 .. p-1]. The shared secret used to
> encrypt the MAC key is thus g ^ (xa * xb) mod p = (g ^ xa) ^ xb mod p = (g ^
> xb) ^ xa mod p. For more information, see [RFC2631]. For information on the
> selection of random values, see [RFC1750].
>
> People creating RP libraries seem to be using the defaults from the spec.
>
> We need an OSIS test to see if they are,  or are perhaps choosing other
> values.   I think choosing alternate values  as long as they are valid is
> allowed by the spec,  however sending invalid values should be a fail.
>
> For OPs there is not much guidance other than the references to RFC2631 and
> RFC1750.
> The spec states the OP should use the values sent by the RP.
> Possible OSIS testes are:
> 1 Is the OP accepting alternate values for p and g from the RP for its
> calculation. If they have hardcoded the defaults and return a result based
> on them that would be a fail.
> 2 is the OP rejecting associations with values other than the defaults.
>  This would be against the spec but is perhaps a reasonable action by a OP
> defending itself against possible Denial of service attacks.
>
> If others have testing ideas around DH (other than removing it from the
> spec) Please get back to me.
>
> I understand some peoples desire to just remove it,  however I think it is
> valuable in a number of circumstances.
> So I prefer to make certain that it works as well as it can in the shipping
> implementations.
>
> I will also note that the current implementation is not doing much to stop
> MITM attacks, given that the DH is just used to encrypt the secret during
> the association reply and has nothing to do with the secret itself.
>
> I personally do not see the DH encryption of the OP's secret as
> incrementally adding anything to the transport encryption in the current
> implementation.   A different implementation where the shared secret itself
> is generated using DH would be MTIM resistant,  however that is not what we
> have in the current spec.
>
> If Ben or others want to propose a improved method of generating shared
> secrets that could be added to 2.1 but I am not seeing a lot of people
> asking for it.
>
> Regards
> John Bradley
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>

-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)