[Openid-specs-ab] SIOP special topic call notes (2021-07-27)

Kristina Yasuda Kristina.Yasuda at microsoft.com
Wed Jul 28 19:53:07 UTC 2021

David Waite
Michael Barrett
Pamela Dingle
Jeremie Miller
Anthony Nadalin
Edmund Jay
John Bradley
Ran Xing
Brian Richer
Kristina Yasuda
Regrets: Mike Jones (IETF 111)

- IPR reminder & introductions/re-introductions

- Agenda bashing/adoption

- Events/External orgs

  *   ISO mDL WG want to publish a technical standard that includes SIOP by Jan 1st 2022
     *   Preliminary deadline set to publish a technical standard on "over-the-internet" transport between mID app (SIOP) and mID reader (RP) by Jan 1st 2022
     *   SIOP is already included in the relevant text and is expected to be part of the final technical standard
     *   Having outstanding issues all solved in SIOP V2 and potentially have few implementations by Jan 1st 2022 would be important, though we would not want to be bound by this timeline
     *   Need to agree on the priority to solve outstanding issues - Cross-device SIOP security considerations (potentially mitigated in mID model by the exchange of the "engagement data" prior to sending the request), client_id in SIOP, iss=self-issued.me, anything else?
  *   DIF Interop WG elected DW as a chair
  *   IETF111 GNAP WG discussed about the interoperability with vc-http-api and GNAP
     *   No overlap with SIOP because in GNAP, AS is always hosted (ie cannot be on a user's device)
  *   Next DIF Presentation Exchange/OIDF WG call on Aug. 4th
     *   everyone encouraged to comment on the issues in PE Github and Bitbucket to help editors make decisions until than

- Issues

  *   SIOP V2
     *   Security Considerations: https://bitbucket.org/openid/connect/issues/1269/add-security-considerations-for-cross
        *   John described a 'session phishing' attack caused by the lack of channel binding, where your credential is not phished but your session has been highjacked. A session can be verified, RP trusts it, but it is MITM presenting a credential that belongs to someone else
        *   We discussed mitigations for a session phishing attack
           *   Cryptographic signature on Verifiable Presentation does not help because there is still no cryptographic proof in the access channel
           *   Encryption also does not help. John said that even some binding is still problematic if it is unidirectional - SIOP can read a QR code, but has no way to verify it. you can sign/encrypt a QR code but that does not prevent it being placed on a different website.
           *   Redirect happening to the website on the device (rather than on a desktop) does not work too, because if there is a malware, reverse proxy will be the one to get the redirect and it can modify/process it.
              *   Modern MITM where browser in the cloud controlled by the malware company
           *   Have the user authenticate at the browser using a usual OIDC flow, set a signed cookie tying userID, browser and the RP, start a SIOP flow and have SIOP include userID in the SIOP response for the RP to validate is a potential mitigation, but does not work if the initial cookie is tied to a malicious website - and with the introduction of cross-device flow, there might be more incentives for such impersonation prior to the SIOP flow.
        *   We identified that problem is not in the QR code, but in the fact that channel binding is unidirectional and SIOP has no idea which origin is presenting the QR code.
           *   John's prior work on secure session transfer
           *   reason why in payments, backchannel authn works off trusted payment terminals (trusted meaning not running JavaScript or displaying HTML)
           *   Consumption Browser would need modifications to display only the QR codes that match the origin on the website itself
        *   John pointed out that the core question is how do you trust the browser on the consumption device (RP)
           *   The only secure mitigation John has been thinking of is: wallet on the consumption device creates a WebAuthn credential, uses it for re-authentication at the consumption device
           *   RP would have an audience restriction of the FIDO assertion to prevent MITM
           *   key could be on a security key (or in the platform authenticator on the phone and used via CABLE) - for those interested, new version of CABLE uses a local QR code, exchanges crypto seed, and continues to pairing over Bluetooth to create a secure channel between the browser and the phone.
        *   Jeremie suggested that the best way to address this attack is to state that in SIOP V2, backchannel authentication must not be used and only WebAuthn must be used for the session creation
           *   John agreed and pointed out that a way to make easy the creation of a WebAuthn credential that is tied to the VP going to the RP is needed -
           *   Action item to start writing such document - Kristina opened a related issue

        *   Related conversations
           *   DW mentioned that the requirement becomes that two separate devices need to have a "multi-directional" relationship to make a channel binding work
              *   With FIDO, browser handling the network traffic is also responsible for talking to WebAuthn/CTAP-based authenticator
           *   Related question: How do you re-authenticate to the same website using various devices (presenting the same credentials)?
              *   putting wallet on everysingle device sounds impractical
           *   Pam pointed out that this is not really a new problem... Old problem being revived
           *   John explained how these concerns did not stop OAuth Device Flow because it is TV that sends you to a place for authentication and you trust the TV.
     *   successful client registation response: https://bitbucket.org/openid/connect/issues/1267/successful-client-registration-response<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%2F1267%2Fsuccessful-client-registration-response&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C53f1573ae4cd44efe6e708d94cd18751%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637625285115894941%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9MSX0LrKPsCmcs5a2jBqYw2d0btXx1kbfOOeiP2ZZJY%3D&reserved=0>
        *   John to take a look if this original SIOP text is still relevant
     *   Resolved #1203 and #1262 by the merge of PR #35

Thank you!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210728/b68baf7e/attachment-0001.html>

More information about the Openid-specs-ab mailing list