Semantics of ForceAuthn with two-factor authentication

[Jim Fox]

Our pubcookie two-factor, using an Entrush token, does this:

1) Requires entry of a token always - reauth assumed.
2) If the user's password was entered more than ten minutes prior
    it must be re-entered as well.

#2 is as far as we go with user convenience.

Jim

On Mon, 21 Jul 2014, Eric Goodman wrote:

> Date: Mon, 21 Jul 2014 08:46:59 -0700
> From: Eric Goodman <Eric.Goodman at ucop.edu>
> To: Shib Users <users at shibboleth.net>
> Reply-To: Shib Users <users at shibboleth.net>
> Subject: RE: Semantics of ForceAuthn with two-factor authentication
> 
> I'm really interested in the answers to this question.
>
> My thought is similar to yours; while I can see that conceptually there may be sense to only reauthing one factor in some cases, it makes the most scalable sense (at least lacking another indicator) to reauth all factors.
>
>
> I'll even throw in a followup:
>
> In this same scenario, if one assumes that the first and second factors were authenticated at separate times, what's the appropriate "AuthnInstant" to put in the assertion -- the original or the more recent AuthN event's occurrence?
>
> In answer to my own question, I think it similarly makes more sense to from a scalability standpoint to return the oldest AuthnInstant.
>
>
> I think it's easier to argue against either stance if one assumes that the second factor is inherently the "more secure" factor, but I don't think we can really presume which factor is the one about which the SP is "more concerned".
>
>
> --- Eric
>
> -----Original Message-----
> From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Christopher Bongaarts
> Sent: Monday, July 21, 2014 8:31 AM
> To: Shib Users
> Subject: Semantics of ForceAuthn with two-factor authentication
>
> SAML 2.0 defines ForceAuthn thusly:
>
>> If "true", the identity provider MUST authenticate the presenter
>> directly rather than rely on a previous security context.
>
> Our Duo implementation currently uses a previous security context
> (cookie) to determine how to proceed.  The logic looks like this
> (simplified):
>
> If the SP wants two-factor, then
>   if the user is already authed with two-factor
>     let them in (SSO)
>   else if the user is already authed with their password (first factor)
>     prompt them for the second factor
>   else
>     prompt them for the first factor
> else
>   prompt them for the first factor
>
> Now, the question that has come up is:  if an  SP wants two-factor, and also requests ForceAuthn (the particular use case is enforcing an inactivity timeout at the app), should we force re-authentication of
> *both* factors, or is there a case that only the second factor could be reauthenticated (assuming that the first factor auth is still valid from the IdP point of view)?
>
> My most literal reading of the spec is that both must be reauthed (since accepting the previous first-factor auth would be relying on a previous security context).  Scalability to additional factors would also tend to favor this reading (if I ask for seven-factor auth, how do i decided if it's acceptable to re-use factors 1-4 but not 5 and 6?).
>
> Any reasons besides "user convenience" to support a looser reading?
>
> -- 
> %%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
> %%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
> %%  University of Minnesota    %%  +1 (612) 625-1809    %%
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>