According to OpenID 2.0 section 10
If the Relying Party supplied an association handle with the authentication request, the OP SHOULD attempt to look up an association based on that handle. If the association is missing or expired, the OP SHOULD send the "openid.invalidate_handle" parameter as part of the response with the value of the request's "openid.assoc_handle" parameter, and SHOULD proceed as if no association handle was specified.
This is not a security issue as the signature will fail and openid_complete will not be able to verify responses. The bug 1) is against spec and 2) blocks sign-in for certain OPs when their authentication handles expire.
Comment | File | Size | Author |
---|---|---|---|
#11 | openid-invalidate-handle-1-D6.patch | 3.4 KB | c960657 |
#8 | 730462-invalid-handle-response.patch | 2.89 KB | Damien Tournoud |
#5 | do-730462-invalidate_handle.patch | 1.76 KB | Heine |
#4 | do-730462.patch | 1.76 KB | Heine |
#2 | 730462-invalidate-handle.patch | 1.17 KB | Damien Tournoud |
Comments
Comment #1
Damien Tournoud CreditAttribution: Damien Tournoud commentedHm. The way I'm reading that is that when the request
openid.assoc_handle
is expired, the OP has to "proceed as if no association handle was specified" (ie. as if that field was not in the request), and has to put the expired association handle in the response asopenid.invalidate_handle
.As a consequence, the response should not contain any
openid.assoc_handle
, and openid_verify_assertion() will proceed with direct verification.So, except if the OP doesn't comply with the spec, nothing wrong should happen. The only issue is that we will continue to send invalid association handles to this OP, that will have to be verified in the (less performant) direct verification mode.
Comment #2
Damien Tournoud CreditAttribution: Damien Tournoud commentedAnyway, this should do it.
Comment #3
Damien Tournoud CreditAttribution: Damien Tournoud commentedJust to clarify #1, my analysis is that 1) we do not violate the spec here, because the spec only specify the behavior of the OP, not of the RP, 2) nothing wrong should happen as long as the RP comply with the spec.
Comment #4
Heine CreditAttribution: Heine commentedAlas,
If we receive an invalid_handle response, we must verify directly with the OP (we do now, assuming the OP is well-behaved and sends an empty assoc_handle).
Only then, when the OP confirms that the handle is in valid should we remove it. see section 11.4.2.2:
TODO - I still need to look into 11.4.2.1. about shared keys.
TODO - we must do ns checking - maybe in a separate issue?
Comment #5
Heine CreditAttribution: Heine commentedGah, wrong patch.
Comment #7
Heine CreditAttribution: Heine commented#5: do-730462-invalidate_handle.patch queued for re-testing.
Comment #8
Damien Tournoud CreditAttribution: Damien Tournoud commentedRerolled with a some additional comments and a smallish style issue.
Comment #9
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks!
Comment #11
c960657 CreditAttribution: c960657 commentedD6 backport.
Comment #12
pwolanin CreditAttribution: pwolanin commentedstill an open core bug