What does and RP need to survive compromise of user@idp?

From IIW

Conference IIW8 Room/Time: 10/B

Convener: Luke Shepard and Breno

Notes-taker: Bill Shupp

Attendees: Luke, Breno, Allen Tom, Bill Shupp, Anthony Eden from chi.mp, lots of others

Technology Discussed/Considered: OpenID

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Key understanding: An RP needs a way to communicate to the OP that it has been compromised, or perhaps request from the OP when the last time credentials for that user changed. This is necessary so that when an RP blocks an account, it knows when the account has been “reset” at the OP.

Outstanding questions are where this fits in the protocol, and how this data is communicated from the OP to the RP. Suggestions included modifying nonces to expose it, adding an optional request parameter to checked_* modes to expose this, and abstracting the data do “credentials change more/less than X time ago”.

Here are the unedited notes taken during the meeting:

What does a RP do when user@idp is compromised?

  • What tools does the RP need when this happens?
  • User/Pass logins usually reset a password and send an email notification. Not available in OpenID.
  • Do you add additional PAPE levels after a compromise has been repaired?
  • Should OPs provide a security endpoint?
  • What's the value of resetting the password?
    • Email + OP providers have less value
    • Password reset is still useful, even if it doesn't solve this case
    • It's useful to separate the attacker from the user
  • Another attack scenario is when an attacker phishes an account, then sets up an OP to link to the account, providing a backdoor (worse case)
  • If your account was created with OpenID only
    • Communicate with the user directly if AX/SREG provided an email
    • Create a communication mechanism with the OP
    • Other mechanisms for identifying the user, send one time pass to cell phone
  • Does the RP want the responsibility of extra credentials? Or does the RP want a cooperative approach with the OP?
    • If OPs are notified, the attacker (as OP) could collect data on the RP's process/state
  • Should there be a way of exposing to RP the last credential change time at OP?
    • Could be a nonce based on the state (within PAPE?)
    • Should there be a history of changes?
    • OPs should have flexibility around how much information to expose
  • Should we be trying to arbitrarily put trust data in the protocol?
    • RPs need concrete, objective measures to know that a password/credentials reset has occurred at the OP
    • OP could certainly lie about it, but including a date could be useful
  • How is this credential change communicated to the OP?
    • In checkid_setup?
    • Should the OP just provide this data in each response, so that the RP doesn't need to make the request?
  • Response term name.
    • Instead of referencing it as "last credential changed", it could be "last time verified good"
  • We are interested in short windows of time here. Maybe use ranges? Like "credential change is > 1 day old"
    • Optional "older than you care about" value?
    • Value is abstract, not concrete.
    • OP has the option of not sending this
  • Possible flow:
    • Do checkid_immediate to see who they are
    • If needed, do another checkid_immediate to see when the credentials have changed
    • If not satisfactory, do checkid_setup requesting credential change
Retrieved from "https://iiw.idcommons.net/index.php?title=What_does_and_RP_need_to_survive_compromise_of_user@idp%3F&oldid=3676"