[security] [OpenID] OpenId Association Timeout Recommendations

[David Fuelling]

Hey Hans,

Thanks for your input on this!

Can you elaborate on this attack a bit more?  What would the MITM gain by
sending a fake "valid" response, when the OP actually sent "invalid" (or
vice versa)?  

Also, why is the assoc step harder to MITM?  Isn't there a DH computation on
both the direct verification step and the association step?

Thanks!

David

> -----Original Message-----
> From: Granqvist, Hans [mailto:hgranqvist at verisign.com]
> Sent: Monday, February 05, 2007 3:03 PM
> To: thayes0993 at aol.com; sappenin at gmail.com; general at openid.net;
> security at openid.net
> Subject: RE: [OpenID] OpenId Association Timeout Recommendations
> 
> A MITM can easily change any is_valid value since those responses are
> unprotected.
> 
> There is a MITM attack on the association step, but it is much harder, as
> it
> requires DH computation and state keeping for later authentication steps.
> There are also DH variants that are more resilient to MITM attacks (SRP
> anyone? ;), and such can be added as mechanisms to the protocol.
> 
> In reality Direct Verification is useless. Very few RPs use secure
> channels.
> The message floats unprotected through the network of tubes.
> 
> Direct verification gives an attacker an incredibly simple way to
> downgrade
> the protocol without either the OP nor the RP being any wiser.
> 
> What attacker wouldn't love that?
> 
> Hans
> 
> 
> 
> 
> ________________________________
> 
> 	From: thayes0993 at aol.com [mailto:thayes0993 at aol.com]
> 	Sent: Monday, February 05, 2007 11:30 AM
> 	To: Granqvist, Hans; sappenin at gmail.com; general at openid.net;
> security at openid.net
> 	Subject: Re: [OpenID] OpenId Association Timeout Recommendations
> 
> 
> 	Hans,
> 
> 	Using the direct verification is not a "less secure mode".
> Association handles provide a way to reduce the cost of verification by
> eliminating one set of messages from the flow.  However, the association
> is established using the same basic message exchange as the verification
> itself, and so is neither more or less secure.
> 
> 	Terry
> 
> 
> 
> 	-----Original Message-----
> 	From: hgranqvist at verisign.com
> 	To: sappenin at gmail.com; general at openid.net; security at openid.net
> 	Sent: Mon, 5 Feb 2007 11:13 AM
> 	Subject: Re: [OpenID] OpenId Association Timeout Recommendations
> 
> 
> 	> I'm wondering if anyone has an opinion on a "recommended"
> 	> association timeout for OpenId OP/RP implementations?
> 
> 	David,
> 
> 	There is a slight problem with shared secrets in the OpenID
> 	authentication protocol.
> 
> 	Generally you want to make the lifespan of shared secrets as short
> 	as possible to reduce risk.
> 
> 	However, according to the OpenID protocol, when the RP uses an
> expired
> 	association handle, the OP should proceed as if no association
> handle
> 	was provided, which will then lead to the obvious security risks(*)
> 	related with direct verification:
> 	<http://openid.net/specs/openid-authentication-2_0-
> 11.html#check_auth>
> 
> 	That's the Catch-22:  You will want the shared secret to live for
> 	a short time, but you don't want to risk reducing the authentication
> 	flow into a less secure mode.
> 
> 	One way to implement a more secure OP is to refuse some
> 	security reductions of the protocol:
> 
> 	* require valid associations, and
> 	* respond with negative assertion (should the assertion be
> 	  invalid)
> 
> 	AFAIK, the language of the spec, with MAYs and SHOULDs, lets you do
> 	this and still remain compliant.
> 
> 
> 	-Hans
> 
> 	(*) meaning the fact that the OP responds whether the signature
> 	was okay with an unsigned yes/no
> 
> 
> 	>
> 	> I think it takes something like 2^80 operations to brute
> 	> force SHA1 (the least secure OpenId HMAC Association type).
> 	> Supposedly, in 2005 SHA1 was "sort of" broken by a Chinese
> 	> researcher (see here:
> 	> http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
> 	) but according to Bruce Schneier, HMAC is not affected by this >
> 	development (only digital signatures are).
> 	>
> 	> All that to say, it seems like it would still take a long
> 	> time to brute force an SHA1 association (SHA256 even longer),
> 	> so I'm wondering what people's thoughts are where OpenId
> 	> implementation should set this number by default.
> 	>
> 	> For example, one of the most popular Java OpenId 2.0
> 	> implementations currently uses a 30 minute expiration.  What
> 	> about 3 days?  7 days? Longer?
> 	>
> 	> I guess I'm trying to figure out where the "balance between
> 	> security and convenience" decision should be made.
> 	>
> 	> Thanks for your input!
> 	>
> 	> David
> 	>
> 	> _______________________________________________
> 	> general mailing list
> 	> general at openid.net <mailto:general%40openid.net>
> 	> http://openid.net/mailman/listinfo/general
> 	>
> 	_______________________________________________
> 	general mailing list
> 	general at openid.net <mailto:general%40openid.net>
> 	http://openid.net/mailman/listinfo/general
> 
> ________________________________
> 
> 	Check out the new AOL
> <http://pr.atwola.com/promoclk/1615326657x4311227241x4298082137/aol?redir=
> http%3A%2F%2Fwww%2Eaol%2Ecom%2Fnewaol> . Most comprehensive set of free
> safety and security tools, free access to millions of high-quality videos
> from across the web, free AOL Mail and more.
>