Implications of forceAuthn/AuthnInstant

[Cantor, Scott]

On 10/2/13 1:29 PM, "Eric Goodman" <Eric.Goodman at ucop.edu> wrote:
>
>If the IdP doesn't issue a forced reset (a la CAS "renew=true" from
>Michael's response) on EVERY external authentication, then what is the
>appropriate value to put in AuthnInstant for any authentication event
>that doesn't assert this?

The appropriate value is the time the session was first established,
unless you assert PreviousSession as the AuthnContext.

>To some extent I guess this is a "practices" question: in the event that
>a Shib IdP calls out to a CAS (or equivalent) backend without setting the
>forceAuthn equivalent, do IdP's query the backend channel to pull out an
>actual AuthnInstant value?

Not by default certainly.

>Again, it seems a simple attack on such an SP would be to generate a
>non-forceAuthn-containing IdP-initiated SSO request. The IdP seems likely
>to generate an AuthnInstant of "right now" in this case.

I would note though that using ForceAuthn has generally been associated
with using signed requests (and by extension not allowing unsigned
requests).

As a practical matter, the SP doesn't need this to be the case *if* the
IdP doesn't lie. If an IdP does lie, then it needs to not support
ForceAuthn *and* not support unsigned requests, you're right, or it will
contaminate the system.

>From my point of view, the simpler option is not to lie, and not to deploy
in a way that makes lying an outcome. But most people using REMOTE_USER
probably have a problem. I hadn't ever taken the time to think through the
implications of that beyond just not claiming to handle ForceAuthn at
runtime.

>Understood. Given the example I gave above, I think this is largely
>another case of the scenario I was positing: IdP configurations that can
>(are likely) to generate assertions without the Shib server knowing when
>the base authentication event took place. I do understand your point that
>at least in the previous (CAS/Webauth) case the IdP has more ability
>configuration-wise to control the interaction so it can correctly
>populate the assertion.

Yes. And you're right that my example is similar in that it means the IdP
will essentially "lie" without knowing it's lying. However the difference
is that you shouldn't be using a PasswordProtectedTransport AuthnContext
class in such a case. You'd use Kerberos, or PKI, or whatever was
relevant. So in that situation, you probably aren't using ForceAuthn or
relying on the AuthnInstant. The totality of the system is just different.

>And your point here highlights the other area I was calling about the
>desktop becoming the access control point and not the SSO system. (In
>fact, if you read the draft update of the AD Silver compliance document
>that just went out to the assurance list this AM, you'll see that we're
>explicitly recommending you not support SPNEGO/GSSAPI for reasons that
>could be argued on somewhat similar grounds).

I'll look at it, that seems like a surprising outcome.

>So my followup for you and others:
>
>Does your campus have a specific security approach to/stance on the use
>of forceAuthn? (And again, I'm really more interested in the context of a
>system or a federation, rather than internal support of apps).

No. We don't support logout so by extension I see no reason to do much
else. The desktop/device is the only control point for the web today,
whether people like that fact or not.

>For those that don't support or promote forceAuthn, is there any user- or
>executive- focused effort to explain the need for desktop controls or
>other mitigations? (Again, mostly I see developer-focused efforts).

Nope. Lots of complaining but no willingness to understand or face up to
the issue.

>Again, I'm asking largely to help with framing the discussion of whether
>forceAuthn support "should" be required of IdPs in a (defined)
>federation, and what the implications of such a requirement would be.

I think you've teased out, on a purely technical level, some issues to
include in such a conversation.

-- Scott