Allen,
Inline as well:
[atom] This makes sense if RPs and OPs always use session cookies
that are cleared with the browser is closed for their authentication
credentials, however, I don't know if RPs and OPs generally do this.
Recommending that RPs only use session cookies sounds like a good
idea.
Many OPs give users the option (sometimes enabled by default) to set
permanent authentication cookies that persist long after the user's
browser and computer are shutdown and restarted, so telling users
that closing their browser will log them out would be inaccurate in
many cases.
True. I think the session cookie recommendation for RP's along with a
discussion for users and RP's of the implications of a persistent
cookie at the OP would be a nice medium.
[atom] Using HTTPS for the entire end-to-end protocol flow sounds
like a really good thing. Many RPs that care a lot about security
are requring that OPs use HTTPS for everything, however,
recommending that HTTPS be used for everything also implies that the
OpenID URL itself should be HTTPS, and there are many OpenIDs in the
wild (for instance, blog owners, etc) that don't use HTTPS.
This is intended to be best practices rather than common practices,
though, isn't it? Though I certainly agree we can't be prescriptive,
we can make very strong recommendations and make clear what the
exposure is from not using https.
Even if you can't get the RP or OP to use https, there are still
significant protective benefits from doing it on either leg of the
transaction.
4) I'd disentangle the wording about RP/OP trust from the specific
point about PAPE. Provider trust is a more general topic that is
really important, and I think it merits its own section. I'm happy
to draft that if you'd like.
[atom] One of the reasons why I wanted to include trust in the PAPE
discussion is that just because an OP supports PAPE does not imply
that the OP can be trusted to actually implement PAPE in a manner
consistent with the RP's expectations.
Agreed. I wouldn't completely remove the mention there, but I
strongly believe we should generalize the point in a separate section
as well. Even if there isn't much to write now, with reputation
services, XRDS, third party validation, etc. on the way, it will get
fleshed out in time.
6) Pull the replay warning into its own bullet, and mention the
use of a timestamp to bound the time nonces must be stored for.
[atom] Also a good point. On a related note, many large globally
distributed RPs may have a hard time implementing nonces as per the
OpenID spec, as it's technically tricky to globally replicate data,
especially if it needs to be replicated very quickly. In practice,
RPs may only find it practical to verify that the timestamp is
"current" as opposed to actually verifying that the nonce is can
only be used once.
Gulp.
This is a really interesting problem that we don't encounter in
deployments on our scale -- still large, but not so large that
replication can't be done. It argues strongly for both the use of
HTTPS and short assertion lifetimes. We've been surprised how many
deployers have issues dealing with clock synch, but that's probably a
lesser evil than serious replay.
If the entire protocol is implemented over HTTPS, including the RP's
return_to URL, then verifying that the timestamp without verifying
that rest of the nonce unique is probably sufficient.
Probably. But if it's not HTTPS, and the nonce can't be checked, the
threat surface from replay is huge. Compromised clients could pose
the same issue.
I think it's quite appropriate to make a recommendation for expires_in
in this document. But I'm not convinced that such an automated attack
that results in a long-lived session is really mitigated by a narrow
timeframe.
7) Is it worth mentioning more generally anything about session or
assertion hijacking and possible countermeasures?
[atom] Are you referring to XSS/XSRF/clickjacking?
Yes, you've got the common specific attack vectors pretty thoroughly
covered already. I'm just referring to explanatory text of the issues
surronding persisting non-secure session cookies after session
establishment, and again the replay risks of sending a bearer
assertion over plain http. This would fit naturally with the
discussion of the use of session cookies by the RP.
Spooked by the difficulty of replicating the nonce,
Nate.
_______________________________________________
security mailing list
[email protected]
http://openid.net/mailman/listinfo/security
