[OpenID] D-H vs SSL

Fri May 15 22:00:11 UTC 2009

This is an old thread but I will bite.

DH should not be required for transport encrypted association sessions.

The DH parameters in the spec have defaults but they are not fixed.

Yahoo and others believe that doing DH without fixed parameters could  
lead to a denial of service attack,
one of the reasons they don't do DH.

Yes we should probably fix the parameters if we continue to allow  
associations over non-ssl connections, or insist on validation by the  
OP.
Some people would be happy to ditch DH completely.

This should be discussed as part of 2.1.

That however is separate from the question of the RP contributing to  
the entropy of the shared secret.

That is not in the current spec.  Perhaps it should be added to 2.1  I  
wouldn't have a problem with that.

I think that was the topic of the original thread.

John Bradley

On 15-May-09, at 4:27 PM, Breno de Medeiros wrote:

> 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)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090515/d125a352/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2486 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090515/d125a352/attachment-0002.bin>