+ - 0:00:00
Notes for current slide
Notes for next slide

Multi-Factor Authentication

Pilot Project Update

Etienne Dysli-Metref
etienne.dysli-metref@switch.ch

1

Project members

  • University of Geneva
  • Swiss edu-ID
  • developer: me :)
2

University of Geneva

Goal

Stronger authentication for a HR web application handling personal data of university staff

Second factors

  • Google Authenticator (OATH-TOTP)
  • SMS OTP

Authentication server with RADIUS interface to verify OTPs

3

First real use case for MFA we've heard about.

Swiss edu-ID

Goal

Offer stronger authentication methods on the edu-ID IdP

Second factors

  • First demo with Google Authenticator
  • Add more as required
4

Project links

5

If you want to be a follower too, here are some links.

IdP 3.3 enhancements for MFA

IDP-962

  • Orchestrator flow to combine login flows
  • Execute several authentication methods and aggregate results
  • Attribute resolution during authentication
  • Transition logic
6

No release date for 3.3 yet, likely Q4 2016 or later.

The SAML & MFA horror scenario

  1. SP wants “MFA”
  2. SP requests a particular AuthnContext
  3. IdP does not support this AuthnContext
  4. Failure!

How can SPs request MFA and IdPs indicate that MFA was used, without getting too precise about the actual authentication method?

The InCommon MFA interoperability profile working group tackled this problem and published two profiles to help solve it

7

Fails even if the IdP supports MFA, but with a different AuthnContext.

MFA interoperability profiles

InCommon MFA profile

  • AuthnContext http://id.incommon.org/assurance/mfa says “MFA was used”
  • Factors must be independent
  • Combination of factors mitigates single-factor-only risks related to non-real-time attacks: phishing, offline cracking, online guessing, theft
  • Limited to authentication: nothing about registration or identity proofing
  • Not technology-specific
8
  • Deliberately weak profile to start, others can be built on top later with more guarantees
  • Defined to protect against persistent threats to authentication (reusable credentials only)
  • Kept out assurance processes and registration on purpose
  • This is more interoperable than asking for "better than password" because non-Shibboleth IdPs may not support inexact AuthnContext matching and this depends on what an IdP considers "better" without constraints.
  • SP can ask for more than one profile (base + mfa) -> fallback if MFA not supported

Project members

  • University of Geneva
  • Swiss edu-ID
  • developer: me :)
2
Paused

Help

Keyboard shortcuts

, , Pg Up, k Go to previous slide
, , Pg Dn, Space, j Go to next slide
Home Go to first slide
End Go to last slide
b / m / f Toggle blackout / mirrored / fullscreen mode
c Clone slideshow
p Toggle presenter mode
t Restart the presentation timer
?, h Toggle this help
Esc Back to slideshow