Security considerations when jumping from desktop RP to mobile wallet

[jmandel]

Apologies if there has already been discussion on this point, but looking through the security considerations at

did-siop/docs/index.html

Lines 529 to 530 in 808daa3

	<section class="informative">
	<h1>Security Considerations</h1>

I don't see notes specific to the workflow where an RP interaction begins on desktop, and moves over to a SIOP-enabled digital wallet on mobile (e.g, when the user scans a QR code displayed on the desktop screen). When this redirect happens, my understanding is that the following "callback" step of the protocol:

... means a callback from the SIOP-enabled digital wallet to a URL in the RP -- but in a different user agent session than the one that kicked off the request. (In other words, the kick-off happened in a desktop user agent session, and the redirect happens on mobile.) In this case, isn't there potential for a session fixation attack? For instance, an attacker could trick a victim into authenticating for the attacker's session (and all the victim sees is "Please sign in to [service you trust and use]", which could be well-timed to avoid suspicion). At that point, the nonce in the SIOP response id_token would tie back to the attacker's session.

It's entirely possible I'm missing something already in the spec that would mitigate this concern! I'd appreciate any advice.

[awoie]

@jmandel Your concern is valid.

Note, the authentication response, i.e., id_token, is either sent to the callback URL of the original RP via POST, or via a fragment by redirecting the mobile browser to the original RP's webpage. Technically, in the case of a fragment, some script needs to submit the id_token to the original RP. The callback URL cannot be manipulated. This is ensured by enforcing Request Objects.

In both cases, a Fake RP won't see the authentication response, i.e., id_token.

However, I can see one attack vector:

• Fake RP visits Original RP
• Original RP displays QR Code
• This step is out-of-scope of the spec but let's assume the following implementation. Original RP provides script to Fake RP that polls authentication status by providing some session cookie.
• Fake RP sends QR Code to user and tricks user to scan the QR Code
• User uses mobile app to authenticate and sends response via POST
• Script polls again and Fake RP is authenticated

Usually the state parameter is used to mitigate these attacks, i.e., binding session cookie to request/response. Unfortunately, this is not applicable.

I suggest the following:

• Mandate that the client_id MUST be included in the Request Object. Note, in SIOP, the client_id contains the callback URL.
• Add security consideration section
  -- Describe the attack.
  -- QR Code to Mobile app flow needs to display the domain the request is coming from.
  -- Use very short-lived Request Objects and exp times

Does this address your concern? Note, the QR Code flow is a pattern that is commonly used.

[awoie]

To make the QR Code flow more secure, the mobile app could generate a random number and send that number in the id_token to the Original RP. In order to conclude the authentication process on the desktop, the user has to enter the random number. That will mitigate the risk of sending QR Codes via out-of-band methods such as email because the user can verify that the web page is under the same domain as the domain in the Request Object. The question is if this is more secure than just having short-lived Request Objects and exp times of the id_token. Unfortunately, this won't mitigate the risk of some Fake RP web page with a similar domain that was able to trick the user.

[awoie]

RESOLUTION as per Auth WG call on Dec 19th, 2020:

(1) Update the spec:

• Mandate that the client_id MUST be included in the Request Object. Note, in SIOP, the client_id contains the callback URL.
• Have an optional user_code in the id_token

(2) Add informative security consideration section

• Describe attacks

• QR Code scamming
• Registration/ timing attack/ account binding --> user should repeat the user_code similar to device flow

• QR Code to Mobile app flow needs to display the domain the request is coming from.
• Use very short-lived Request Objects and exp times.
• Use "DID Configuration protocol" to ensure the binding between the domain and the DID of the requester.
• UX should enforce reconfirmation from the user

(3) Create "SIOP DID Profile best practices guide"

[jmandel]

Thanks for the detailed response here! Re: updating the informative security considerations and developing best practice guidance, I think those are two key steps.

Regarding the threat itself, I want to make sure we're on the same page. Above, you note:

Note, the authentication response, i.e., id_token, is either sent to the callback URL of the original RP via POST, or via a fragment by redirecting the mobile browser to the original RP's webpage.

Here's my concern. When the authentication response is sent to the callback URL of the original RP via POST that POST is happening on a mobile device rather than on the device that originated the workflow. ,So, the POST is performed either in a headless fashion, or perhaps in a mobile-device browser session -- and in either case, the POST shares no session cookies with the desktop device that originated the flow. So the callback URL is not being manipulated, but the attacker does not need to manipulate the callback URL to execute this attack. Instead, the attacker can trick the victim into authenticating into the attacker's existing, genuine session with the genuine RP. The only difference from a genuine authentication workflow is that the victim is one signing in. In this case, displaying the domain of the RP in the mobile wallet wouldn't help, because the RP domain will be legitimate. Does this make sense?

[awoie]

@jmandel right, that is a slightly different attack than the one I described above but share the same underlying issue. The one you described could be mitigated by having the user_code approach. The attacker does not have access to the id_token as the id_token is sent from the mobile device to the backend of the RP. The RP needs to prompt the user to repeat the user_code on their web page to finish the authentication process. That is however out-of-scope of OIDC but can be in-scope of the security considerations section, or the best practice guide that we mentioned above. Would you agree with that?

Updated (more context):

The user_code is a random number generated on the mobile device by the mobile wallet, presented to the user and included in the id_token. Because OIDC does not talk about what happens after the id_token was obtained, it is out-of-scope of the spec. However, the desktop browser will probably have a web socket connection with the RP to check whether the authentication has been finished. To finish the process, the RP would additionally prompt the user to enter the random number that was generated on the mobile device.

Updated (more context):

However, we could further include a verification_uri and a verification_complete_uri in a similar way to device flow. These URLs will be called by the mobile wallet before the id_token is transmitted. Calling them would trigger that the RP prompts the user to enter the user_code on the desktop browser and can be used by the mobile wallet to test whether the user has responded.

Note, we cannot use device flow as in the device flow the device is the RP and in our case the device is the OP.

[jmandel]

Thanks! Sorry for the long-winded response below; despite the wall of text, I think we're getting close here ;-)

Because OIDC does not talk about what happens after the id_token was obtained, it is out-of-scope of the spec.

I'm not sure I agree with this statement in general, because part of OIDC's job is to only deliver an id_token into a session when that token is valid for the session. (In other words for OIDC, preventing session fixation attacks is obviously in-scope; OIDC requires the use of a nonce claim that, for single-device flows, protects against these attacks, so an id_token isn't considered valid until the nonce has been checked; it would be a similar story with user_code.). When extending OIDC to multi-device flows where nonce can't protect against session fixations, I think something needs to be said. For that I see two possibilities:

1. As long as SIOP leaves "desktop-to-mobile-and-back" workflows out of scope (as it does today), then adding security considerations is good enough.

2. Nonetheless, I'd argue it's worthwhile for SIOP to actually define a "desktop-to-mobile-and-back" workflow if this is in fact going to be common practice (as it appears to be from early demos). In this case, getting into the details of how to apply a user_code (or whatever) would be more than just "best practice"; rather, it'd be a carefully-specified protocol extension.

Regarding the details of what that best practice (or protocol extension) would look like, the user_code approach could do the trick. One subtlety is that with the user_code approach you outlined above (random, short number), it would be unsafe for the RP to let the id_token reach the browser until after the user_code had been verified, which is surprising (insofar as OIDC id_tokens are normally safe to move back and forth between browser and backend). This could be tweaked by having the OP authcrypt the user_code for the RP before putting it into the token. Alternatively, the session fixation attack could be mitigated with a post-connection confirmation step.

(In all cases, there's still a class of man-in-the-middle attacks that are harder to prevent.)

[jmandel]

(We've been editing at the same time -- so following up in a separate comment! Yes, the verification_uri approach would address my concern about "unsafe" handling of id_tokens above.)

[awoie]

@jmandel I agree with you just said. We should do what I suggested in my second Update. Would you agree with that?

[awoie]

Alright, I will then include that in the spec. Thanks for calling that out!

[awoie]

PR is pending: #16. Can you please review @jmandel .