Using Kerberos for authenticating the distribution of controlled substances, etc.

[Russ Allbery]

Jeffrey Altman <jaltman at secure-endpoints.com> writes:

> One serious question is how do we design the user experience such that
> these multiple authentications can be performed for a single transaction
> and ensure that the credentials retrieved for the transaction are
> discarded after a single use.  Current single sign-on models as applied
> to authentication and data confidentiality for network protocols do not
> satisfactorily address this usage model.  We clearly do not want
> individual applications to provide their own dialogs for prompting users
> for Kerberos passwords or other secrets.

> I do not have a proposal at the moment.  I am posting this primarily so
> that people will think about the issue.

I don't have a general solution either, but I do want to echo this issue
and note that when designing our site-wide web authentication system, we
ran into a similar issue.  The Registrar's Office was uncomfortable, in
part for regulatory reasons, with allowing single sign-on access to a
student's grades and class registration due to the widespread use of
walk-up clusters and kiosk machines on campus and the prevelance of
students who don't understand the importance of logging out.

We therefore built into WebAuth the capability for an application to
assert a "force login" flag when redirecting the user to the central
WebLogin server.  When that flag is asserted, the central WebLogin server
will decline to use any single sign-on credentials (whether pre-existing
WebLogin cookies or mechanisms such as Negotiate-Auth) and will force a
reauthentication.  Currently, that reauthentication is via
username/password over SSL, unfortunately, but I can see a world in which
it may eventually require a hardware token authentication or something
similar (although communicating that information to the WebLogin server
for hardware devices that use X.509 instead of hardware-generated OTPs is
hard, and that gets back to Jeff's point).  Systems with this
authentication requirement set the "force login" flag and then combine
that with the inactivity timeout on the subsequent per-server credentials
that WebAuth supports so that the user remains authenticated as long as
they keep doing things on the site, but if they go idle for more than a
few minutes, they're forced to log in again.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>