Using Kerberos for authenticating the distribution of controlled substances, etc.
Henry B. Hotz
hotz at jpl.nasa.gov
Wed Jul 18 20:50:00 EDT 2007
On Jul 18, 2007, at 9:09 AM, krbdev-request at mit.edu wrote:
> Date: Wed, 18 Jul 2007 11:38:46 -0400
> From: Jeffrey Altman <jaltman at secure-endpoints.com>
> Subject: Using Kerberos for authenticating the distribution of
> controlled substances, etc.
> To: "'krbdev at mit.edu'" <krbdev at mit.edu>
> Message-ID: <469E3406.5040000 at secure-endpoints.com>
> Content-Type: text/plain; charset="iso-8859-1"
> At SOUPS the following real world scenario was raised. In hospitals
> there is a strong desire for single sign-on, but there are a number of
> situations in which there is a requirement that multiple users perform
> an "in person" authentication in order to prevent the abuse of
> controlled substances or perhaps to verify that the correct body part
> was in fact entered into the patient's chart. Applications address
> these regulatory requirements by prompting each user for their name
> password for each transaction. This is separate authentication
> from the
> name and password required for the initial authentication required for
> starting the application.
> When Single Sign-on replaced per-application logon, the cached single
> sign-on credentials can be used for the authentication required when
> starting the application but they must not be used for the multiple
> "in person" transaction authentications which are being used as a form
> of signature that is recorded for audit compliance.
> One serious question is how do we design the user experience such that
> these multiple authentications can be performed for a single
> and ensure that the credentials retrieved for the transaction are
> discarded after a single use. Current single sign-on models as
> to authentication and data confidentiality for network protocols do
> satisfactorily address this usage model. We clearly do not want
> individual applications to provide their own dialogs for prompting
> 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.
> Jeffrey Altman
> Secure Endpoints Inc.
In the interest of not re-inventing wheels where possible: remember
the "initial" flag and its use with password changing. From an
application standpoint is it sufficient to require "initial" service
tickets and enforce a short ticket lifetime (e.g. 5 min.)? That
doesn't address client/UI issues, of course.
Someday I might, conceivably, have a similar concern w.r.t. sending
commands to certain expensive, very remotely located, equipment. ;-)
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu
More information about the krbdev