Hans:

Thank you for your comments. I agree with you that "not vulnerable to
*this* man in the middle attack" is more accurate. 

Regards,
Guoping


-----Original Message-----
From: Granqvist, Hans [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 18, 2007 10:14 AM
To: Guoping Liu; OpenID specs list
Subject: RE: Proposal for improved security of association establishment
in OpenID2.0

Guoping Liu: Nice write-up!

A comment though: This is a common MITM problem with DH key exchange. 

It seems if the MAC key was derived somehow from the negotiated 
secret, then this attack would not be possible. 

I never really grokked the XOR 'encryption' step, apart from 
its ease of implementation and what seemed reasonable protection,
both of great value. 

Perhaps some early spec writers (Brad?) can shed some light? Was 
there ever a discussion pre 1.x on using a MAC key derived
from (or maybe even being!) the negotiated secret, and if so, 
what's the weakness? Am I missing something obvious?

Thanks,
Hans

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

Gutsy statement!  Maybe "not vulnerable to *this* man in the middle 
attack" would be safer? ;)





> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Guoping Liu
> Sent: Thursday, May 17, 2007 11:53 AM
> To: OpenID specs list
> Subject: Proposal for improved security of association 
> establishment in OpenID2.0
> 
> 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
> _______________________________________________
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
> 
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Reply via email to