Changing MCB assurance level per SP and by "risk" (source IP)

[Tom Scavo]

On Fri, Apr 4, 2014 at 5:52 PM, Rich Graves <rgraves at carleton.edu> wrote:
>
> I think I want one central decision point on "risky" IPs -- and certainly on dodgy globe-trotting behavior. Individual SPs, especially third-party SPs, do not know what my IdP knows about expected user behavior.

Classifying IP addresses as "risky" isn't how this works in practice.
Look how Google does it. When I get on a plane and fly to San
Francisco, Google forces me to authenticate with two factors (instead
of "previous session"). That's because my IP address indicates to
Google that my geographical location has changed drastically. Google
is protecting against a stolen password.

In a federated world, it's the IdP's job to protect the user's
password, I agree, but the same technique can be used to advantage at
the SP. If the SP senses that user's geographical location has
changed, it can send a 2FA RequestedAuthnContext to the IdP along with
ForceAuthn="true". This has exactly the same effect as if the IdP had
done it itself.

Unfortunately, there are too many IdPs and not all of them do the
Right Thing, so an SP that cares will protect itself in any case. The
same is true of 2FA itself. An SP that requires strong authentication
won't wait for all of its IdP partners to deploy 2FA. An SP that cares
will layer on a "what you have" factor if it has to. Same with IP
address checking.

Tom