CAC Smartcard Reauthenticate
We have one browser-based application where we want to make the user reauthenticate when they enter it. So when they access that URL we want them to be presented with the PIN prompt so they have to reauthenticate. Is there a reasonable way to do that?
Added info: This is for a CAC card and the workstations have ActivIdentity and Tumbleweed on them. Also, I could add a service to the workstations if necessary. The browsers are all IE7. The web server is IIS 6 and the pages are written in ASP.NET (mostly).
Answer
There's a few different pieces of software involved here.
First is the card itself. To perform a digital signature, the CAC has to be in a "verified" state, meaning a PIN was entered after the card was inserted. Beyond that, each key on the card has a flag that indicates whether the PIN has to be entered every time the key is used. I haven't checked, but I think this is set for the "email" key pair on a CAC. Thus, you'd need to find which keys have this "always verify" flag set, and configure the path validator on the service to accept only those keys. You might be able to require a particular OID in extended key usage, or exclude some of the DoD intermediate certificates from path building (flagging them as revoked, perhaps).
The middleware on the machine talking to the card could also cache the PIN, and provide it to the card whenever the card indicates that it requires a PIN before it will complete an operation. I think that ActivClient was doing this with its PIN caching feature through version 6, but in version 7, this option seems to have gone missing. I haven't found anything like this in Windows built-in PIV support. This "feature" could compromise security, so my guess is that it was deliberately removed and there wouldn't be any registry hacks or otherwise to restore the behavior. This is something you wouldn't have control over, unless you manage the users' machines; there's no HTTP header or TLS option that you can use to enforce PIN entry. But, with newer systems, it should not be an issue.
On the server side, a complete handshake has to occur in order to make the client perform authentication. Client authentication won't happen if there's a valid TLS session. So you'd need to find a way to invalidate the TLS session (not the application session, which is probably tied to an HTTP cookie) before requesting authentication, or direct the authentication request to another interface that doesn't have sessions enabled.