[OpenID] D-H vs SSL

Sun May 17 15:40:43 UTC 2009

Hi Peter,

At the moment openID 2.0 makes no recommendations about TLS cipher  
suite, or any certificate validation.

The spec wrongly makes assumptions that specifying https: guarantees  
you anything more than message integrity.

In common practice you do get more if both parties are good actors and  
negotiate the TLS correctly, but there is no guarantee.

If an RP allows SSL_RSA_WITH_NULL_MD5 or SSL_RSA_WITH_NULL_SHA then it  
with good reason want to us DH to encrypt the shared secret.

For TLS/SSL I would be happy specifying that RP's cant negotiate the  
NULL cypher and must check the certificate.

That is not as easy as it sounds with PHP, RUBY and other openID libs  
being loosely coupled to openSSL.  Most openID libs have no idea what  
openSSL  is negotiating via libCURL or whatever they are using.

That is one argument for retaining DH negotiation.   Personally I  
would rather fix the SSL issues because they effect more than just  
association.

For the generation of the shared secret that is entirely up to the OP  
at the moment.  The RP has no way to protect itself from OP's  
generating predictable secrets.   It would be better practice for the  
RP to also contribute entropy to the secret,  ie the RP sends some  
entropy to the OP and the OP sends some entropy to the RP and they  
both use the agreed hash function to crate a common secret based upon  
the aggregate entropy.

The question came up regarding the RP sending parameters for DH and if  
they are used by the OP to create the shared secret.
the answer was they are only used to encrypt the shared secret for the  
exchange not in generating the shared secret itself.

I think we have simpler ways to combine OP and RP entropy to create a  
better shared secret, than using TLS/SSL as you are thinking.
Your proposal may have advantages but would be very difficult to  
implement for many openID libraries.

It is also unclear if anyone is actually motivated to close some of  
these possible security holes.

John B.

On 17-May-09, at 7:35 AM, Peter Williams wrote:

> 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

-------------- 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/20090517/84101516/attachment-0002.bin>