RFD 180: SSO as MFA Method

[Joerger]

RFD for implementing SSO as an MFA method for Per-session MFA and other MFA related features.

[github-actions]

The PR changelog entry failed validation: Changelog entry not found in the PR body. Please add a "no-changelog" label to the PR, or changelog lines starting with changelog: followed by the changelog entries for the PR.

[github-actions]

The PR changelog entry failed validation: Changelog entry not found in the PR body. Please add a "no-changelog" label to the PR, or changelog lines starting with changelog: followed by the changelog entries for the PR.

[Joerger]

FYI I am in the middle of making small-large changes in every section, so hold off on reviewing for now.

[Joerger]

This is ready for re-review now. I left a few TODOs for details I have not yet POC'd.

[Joerger]

@klizhentas @xinding33 friendly ping for review

[francesco-doyensec]

hello team! 👋 Here my two bits about the RFD. Overall a great work and feature.
The main missing aspects are:

• Missing dedicated section to the security characteristics of the flow (anti-replay, anti-phishing, IdP configuration assumptions)
• References to the IdP behaviour and documentation to further describe the tech supporting the flow dip-side

[francesco-doyensec]

Not clear how the successful IdP Auth response should go directly to Teleport. Same for the callback at step 9.

Additionally:

• since the SSO MFA flow and the per-session MFA flow are separated, it is not clear how the final step is protected against phishing. Probably it is in the plan by using the request ID, but I would state it as requirement in the RFD
• How will replay attempts be treated? As per-session, the token should not be usable two times in a row, same for the certs. What is the plan in that sense (I would add it to the RFD)

[Joerger]

since the SSO MFA flow and the per-session MFA flow are separated, it is not clear how the final step is protected against phishing. Probably it is in the plan by using the request ID, but I would state it as requirement in the RFD

For tsh and Teleport Connect, the client passes a secret key in the sso mfa challenge request, and the server encodes the MFA token with that key before sending it back. The request id is also provided by the server and should only be known by the requesting client, the mfa token alone is useless without knowledge of the request id.

For the Web, we don't encode the mfa token with a secret key, we just depend on the request id being unknown by anyone but the client.

Also note that the mfa token is only valid for the user who requested it. So the requesting user with active key+certs can cash in the mfa token w/ request ID to get their MFA verified certs.

Does this all sound good? This was my main concern that I wanted a second opinion on, so thanks for spotting it out. I'll update the document with agreed upon details.

How will replay attempts be treated? As per-session, the token should not be usable two times in a row, same for the certs. What is the plan in that sense (I would add it to the RFD)

For the most part, the MFA token will be discarded as soon as it's verified for mfa-verified certs, etc. However, we also track the MFA scope for SSO MFA requests and allow reuse in certain contexts. e.g. MFA for back-to-back admin actions: create user -> create reset password token for registration.

Let me know if you are not convinced that SSO MFA is phishing resistant enough to allow reuse like we do with WebAuthn, with the details above in mind.

[anaximand3r]

Hi @Joerger! The described approach looks legitimate to me, I agree with the request ID usage and anti-replay strategy

[Joerger]

@francesco-doyensec Please take another look when you get a chance. I addressed your concerns in the recent commits. In summary:

Teleport doesn't make any assumptions on the exact way MFA is implemented IdP-side. This is left as an exercise for the IdP administrators since it depends on the IdP and desired outcome. The security of this feature depends on proper configuration from the cluster administrators, and as such there will be warnings in the documentation.

We do add a small guardrail to improper configurations; forcing re-authentication by default so that even if MFA is not configured IdP-side, users will be forced to re-login via SSO for each MFA check. IIUC, even this is IdP dependent and some providers might not respect the re-authentication requirement.

Whether or not this is phishing-resistant depends on the IdP-side configuration.

Replay attacks are prevented by immediately discarding validated SSO MFA tokens (unless reuse is explicitly allowed).

Let me know if you have any more concerns as this has been implemented and is planned to be included in v17.0.0, which will be released in the coming weeks. The full implementation (tsh and tctl only) is now on master if you'd like to take a look at the code or test it.

[anaximand3r]

@Joerger, just finished reviewing the updated version. It covers my initial concerns, I agree about the extra guardrail requiring SSO MFA at each interaction. Well structured and described!