Implications of forceAuthn/AuthnInstant

[Eric Goodman]

>In particular, the IdP had certainly better not reset 
>the AuthnInstant in such a case. That would be a pretty blatant error.

I agree that conceptually it's an error, but I don't know if the IdP can be clear that it's blatantly an error or that the error-ness is clear to the IdP, the IdP operators, or in the specs.)

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? It seems there's a good chance that many IdPs are subtly "lying", in a way that would foil the SP's ability to trust AuthnInstant.

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? 

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 understand that these are not questions that are globally answerable, I'm more calling them out to help me frame the requirements for and potential value of ensuring proper support for the common "sudo"-like use case in a federation of defined entities (i.e., not all of InCommon). 


>My issue with ForceAuthn BTW is one you haven't noted. 
>The fact is that the stronger the authentication you use, 
>the weaker the presence proof.
>Consider SPNEGO/Kerberos. Totally seamless and absolutely 
>no proof the user is still there using the browser, and 
>ForceAuthn does nothing but refresh the ticket exchange 
>off a TGT that's in the cache. Same for a PKI token with 
>the PIN entered.

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. 


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).

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). 

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).

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.


Thanks for the feedback,

--- Eric