[OpenID] D-H vs SSL

[Ben Laurie]

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.
>
> The OP has two options for association types (openid.assoc_type) HMAC-SHA1
> or HMAC-SHA256.
>
> The question is one of how the HMAC shared key is communicated from the OP
> to the RP.
>
> There are three options for this:
> 1, no-encryption
> 2, DH-SHA1
> 3, DH-SHA256
>
> The RP passes this in openid.session_type in the association request.
>
> In cases where SSL is used DH is optional in the 2.0 spec.
>
> Sec 8.4.1 states that " "no-encryption" association sessions MUST NOT be
> used unless the messages are using transport layer encryption."
>
> I created an OSIS test that checks OPs on this "MUST NOT" from the spec.
> That is part of what has stirred the pot on this.
>
> I believe the spec is clear, if a OP performs a association over a channel
> not employing transport level encryption they MUST use DH-SHA1 or DH-SHA256
> (depending on assoc_type) to transmit the shared secret from the OP to the
> RP.
>
> I know you are wondering about the set up of the DH keys.  (You crypto
> devil)
>
> Others please stop reading.  Math stuff alert.
>
> 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!

> They don't need to be but I have yet to find a lib that is not using the
> defaults for every association request.
>
> Andrew Arnott and I were discussing this today and will probably add an OSIS
> test to see if OP's blow up with anything other than the defaults,  and if
> RP's are sending the defaults.
>
> You can see why yahoo only wants to do associations over SSL and would
> prefer not to bother with DH as the current RP libs are potentially a bit
> dodgy anyway.
>
> Don't shoot me I am only the tester!
>
> John Bradley
> On 19-Mar-09, at 11:39 AM, general-request at openid.net wrote:
>
>> Date: Thu, 19 Mar 2009 17:31:49 +0000
>> From: Ben Laurie <benl at google.com>
>> Subject: Re: [OpenID] D-H vs SSL
>> To: Martin Atkins <mart at degeneration.co.uk>
>> Cc: OpenID List <general at openid.net>
>> Message-ID:
>>        <1b587cab0903191031u6056a35cmf29dae5474c64939 at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> On Thu, Mar 19, 2009 at 5:22 PM, Martin Atkins <mart at degeneration.co.uk>
>> wrote:
>>>
>>> Ben Laurie wrote:
>>>>
>>>> On Thu, Mar 19, 2009 at 2:17 PM, Andrew Arnott <andrewarnott at gmail.com>
>>>> wrote:
>>>>>
>>>>> Maybe it's just me, but I don't like the terminology we're using. ?DH
>>>>> and
>>>>> SSL are only redundant when used together.
>>>>
>>>> I don't understand why. As I said, DH over SSL gives you a shared
>>>> secret, which SSL alone does not. Of course there are cheaper ways to
>>>> arrive at a shared secret over SSL, but that's not the point.
>>>>
>>>>> ?Otherwise they're complementary.
>>>>> ?If SSL cannot be used, for whatever reason, DH is mandatory.
>>>>
>>>> But does not protect against MitM, and so is not equivalent. Which is
>>>> not what "complementary" means to me.
>>>>
>>>
>>> I believe what's being discussed here is using the secure channel to
>>> exchange a shared secret in "cleartext" (as far as the application layer
>>> is
>>> concerned).
>>>
>>> This is actually already permitted by the spec, but the spec does not say
>>> that it is *required* to use the "cleartext" session mode when on a
>>> secure
>>> channel. This is the change that I think is being proposed here.
>>
>> Ah. I see.
>>
>> So, I am going to be lazy, because I have not checked the spec, but
>> its considered good practice when establishing a shared secret for
>> both sides to contribute to that secret. Is that true for the
>> cleartext secret?
>>
>>
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>