[OpenID] OpenId Association Timeout Recommendations

Granqvist, Hans hgranqvist at verisign.com
Mon Feb 5 20:03:09 UTC 2007

A MITM can easily change any is_valid value since those responses are 
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
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
The message floats unprotected through the network of tubes.
Direct verification gives an attacker an incredibly simple way to
the protocol without either the OP nor the RP being any wiser. 
What attacker wouldn't love that?


	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
	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.
	-----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?
	There is a slight problem with shared secrets in the OpenID 
	authentication protocol.
	Generally you want to make the lifespan of shared secrets as
	as possible to reduce risk.
	However, according to the OpenID protocol, when the RP uses an
	association handle, the OP should proceed as if no association
	was provided, which will then lead to the obvious security
	related with direct verification:
	That's the Catch-22:  You will want the shared secret to live
	a short time, but you don't want to risk reducing the
	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
	AFAIK, the language of the spec, with MAYs and SHOULDs, lets you
	this and still remain compliant.
	(*) 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> 

	Check out the new AOL
r=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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070205/1ff026fe/attachment-0002.htm>

More information about the general mailing list