[OpenID] D-H vs SSL

Sun May 17 14:35:47 UTC 2009

There are probably technically-loaded terms in folks' discussion, which prejudice and thus define the judgment. But in good ol SSL, using techniques from 25+ years ago, there is no problem with an RP "validating" group parameters. In SSL, an RP would be known as the non-initiating peer entity (allowing for the fact that entities can always reverse initiating roles, given a secure channel).

For about three decades, folks have distributed group parameters in signed certificates (of one bit format or another). Secret and top-secret communities using type 2 discrete crypto typically use different groups, if only for good design hygiene (dont let the loss of one compartment - due to the assumed-improbable ice berg -  flood the next compartment.) Of course, one takes care to choose "good" parameters, through exhaustive search up front - and have some backups parameters pre-prepared.

In the internet and old-milnet world, you put the DH/KEA group values on the smartcard, provisioned according to the organizational policy level - so the entity within the card's cryptoboundary can be authenticated to the local node in the trusted system (without relying on certs, even). Then, to create a basis for wide area interworking using security services,  root/intermediate certs the same group values typically (which allows for rapid flash-override organization-wide, should there be a need). Then EE certs CAN have different groups, assuming some special need for particular transactions that perhaps need to use a custom key derivation function crafted for custom transactional-security services.

Assuming one is validating (a) the security of the connection to the phoneSIM/smartcard and (b) validating certs, RPs really only have to load the parameters dynamically into the registers of the crypto device. If certs exchanged over a layer entity protocol don't change the values, this will have even been already done by the firmware of FIPS 140-2 device, as its enters its initial state for the device-login session. If not, then the certs (indirectly) load the variant keying material for that session.

Hopefully, Im saying the obvious. Just good solid, well understood, scalable key management, for crypto-based security associations - techniques that are known to fit well with the rest of the methods used within the defense in depth concept.

Are we proposing that openid master keys per association be negotiated over a backchannel, custom-derived from the SSL state... before foreground channels - connected via browser proxying - exchange the mac'ed assertions? (This is exactly what EE-based group override was/is for, note: custom key derivation from well managed base keying material!)
________________________________________
From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of Breno de Medeiros [breno at google.com]
Sent: Friday, May 15, 2009 1:27 PM
To: John Bradley
Cc: general at openid.net
Subject: Re: [OpenID] D-H vs SSL

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)
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general