[OpenID] D-H vs SSL

[John Bradley]

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.

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

-------------- 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/20090319/5a01112c/attachment-0002.bin>