Will, This is probably a specs list conversation. I recommend moving it there.
In the profile we considered a number of issues. 1. The RP MUST use TLS for the association. The RP is protected against an attacker spoofing the OP by the OP's certificate. 2. We specified minimum cypher-suites for TLS. Nothing in the openID spec requires encryption over TLS. (Most libs rely on default configs and don't check) 3. We did not ban HMAC-SHA1 associations immediately. Remember that in openID I can discover the association handle that any given RP uses with any OP because they are sent in the clear in the request. This allows an attacker to craft arbitrary authentication requests as the RP the the OP will respond to via the attacker. As long as the OP includes the nonce as one of the signed elements the attacker is probably limited to a brute force attack. If the OP also supports openID 1.0 without a nonce that opens other theoretical attacks. The spec provides no upper limit. This makes it difficult to quantify resistance to a brute force attack against. Even SSL certs expire for similar reasons. I looked at common practice amongst the large IdP. That ranged from hours to 4 weeks. In conversation with the IdP 24h was agreed to be a reasonable lifetime. The extra processing of renewing associations once a day was not considered significant. In your SSH example it is up to the user to determine if they are still talking to the intended host if the keys change. Using long lived HMAC keys and requiring some sort of manual (or meta-data) rekeying requires changes to the openID 2.0 spec to be beneficial in a similar way to ssh. If we were not requiring a SSL association against a known whitelist by the RP the answer might not have been so clear. One option would be to move to SHA256 and extend the association. However there is no way in the existing spec to take advantage of that. If you like you can blame me for picking an arbitrary number:) John B. On 2009-11-29, at 3:34 PM, Will Norris wrote: > One question has been bugging me for a while after reading the ICAM OpenID > profile[0]. The ICAM profile specifies that associations must expire within > at least 24 hours. What's the rationale behind this? > > Or put another way, what about the benefits of using long-lived associations? > Take SSH host keys for example. They MUST be long lived to actually serve > the purpose they are intended for... to ensure that host you're talking to > today is the same host you talked to yesterday, and the day before that. Now > for the really paranoid, you would verify the SSH host key out of band some > way, but I'm certainly not suggesting that (I've gotten my fill of that with > SAML metadata exchange). But even without the out of band verification, > there is a lot of value just in having the host key long lived. > > Why are these same principals not applied to OpenID associations? Am I > overloading the purpose of the association? > > [0]: http://www.idmanagement.gov/documents/ICAM_OpenID20Profile.pdf > > -will > _______________________________________________ > general mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-general
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
