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

[Tom Scavo]

[sorry, this is way off topic but I couldn't resist]

On Sat, Apr 5, 2014 at 4:23 AM, Rich Graves <rgraves at carleton.edu> wrote:
> Yes, I will do that too, but the first hit would always be free; i.e., they
> would get at least one login to webmail from country N and one login to
> Elsevier from country C without challenge.

Checking the origin IP address is useful but only marginally so. (It
wouldn't pick up the San Francisco scenario outlined earlier.) If OTOH
you compare the current IP address against the *previous* IP address
(which is what Google does), you actually have something that protects
against a stolen password, it seems.

Of course the IdP that performs this check must maintain state, and as
noted earlier, SPs can benefit from such an IP address check, so one
conclusion is that a special purpose global IdP could handle this
factor. Then all entities (IdP and SP) would benefit.

You're right about the "first hit," that requires extra factors. The
location-based IdP (i.e., the IdP that does IP address checking) would
fail in that case, leaving it to downstream entities (IdP or SP) to
handle. For example, Google requires 2FA in that case. If the user
doesn't have 2FA enabled, I assume the session is tagged as risky (or
at least something less than "fully confident").

If you're willing to trade off some privacy for accuracy, efficiency,
and simplicity, a mobile phone is an obvious alternative to IP address
checking. This is what the commercial product Toopher does, in fact.

> "Losing their certification" for
> single-factor auth could be a more effective and user-friendly approach.

I can't recover the stream of consciousness that led to the above
statement :-) but device checking is another (but separate) risk-based
authentication factor. Analogous to "previous-location," a factor
called "previous-device" helps to restore some of the SSO that is lost
due to multifactor. As long as there's a soft binding between device
and user (as evidenced by a cookie, e.g.), the user need not actively
prove possession of the device. Of course cookies are, well, cookies,
so there's a trade-off. If you require a *strong* binding between
device and user, an active proof of possession is required.

You have the same bootstrap problem here as with previous-location.
Multiple factors are required to initialize previous-device. Google
does this. Duo does this, too. Duo can be configured for a fixed
30-day previous-device window. I don't know why the window is fixed to
30 days.

Like previous-location, the previous-device factor would be useful to
both IdPs and SPs. I suspect that SPs, in particular, would find these
RBA factors to be useful. The information obtained from a passive
request to an IdP that tracked these RBA factors could be used to
dynamically formulate an intelligent AuthnRequest and maybe even to
adjust the local user session on-the-fly.

Tom