[OpenID] D-H vs SSL

[John Bradley]

<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
-------------- 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/20090320/0b64355c/attachment-0002.bin>