Proposal for improved security of association establishment in OpenID 2.0

[Guoping Liu]

Issue: Vulnerability to man-in-the-middle attacks

The association algorithm with DH-SHA1 and DH-SHA256 defined in the
draft 11 is vulnerable to man-in-the-middle attacks if server
authentication with HTTPS is not used. Here is how:

A RP sends an associate request an OP with following parameters:

        openid.dh_modulus = base64(btwoc(p)) 
        openid.dh_gen = base64(btwoc(g)) 
        openid.dh_consumer_public = base64(btwoc(g ^ xa mod p))

A middle man M intercepts the request. M then generates xc, creates a
new request to the OP with following parameters:

        openid.dh_modulus = base64(btwoc(p)) 
        openid.dh_gen = base64(btwoc(g)) 
        openid.dh_consumer_public = base64(btwoc(g ^ xc mod p))

The OP receives the request from M and sends following response to M

        dh_server_public = base64(btwoc(g ^ xb mod p)) 
        enc_mac_key = base64(H(btwoc(g ^ (xc * xb) mod p)) XOR MAC_key)

M decrypts the MAC_key as follows:

        MAC_key = H(btwoc(g ^ (xc * xb) mod p)) XOR enc_mac_key

M then sends a response to the RP with following parameters:

        dh_server_public = base64(btwoc(g ^ xc mod p)) 
        enc_mac_key = base64(H(btwoc(g ^ (xc * xa) mod p)) XOR MAC_key)

Now, the RP, middle man M and OP all have the same MAC_key.


Proposed Solution:

Do not send enc_mac_key in response. Both OP and RP generate a MAC key
as follows

        H(btwoc(g ^ (xa * xb) mod p))

We are NOT sending the MAC key over and are not vulnerable to man in the
middle attacks.

Guoping Liu