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

Henry B. Hotz hotz at
Wed Jul 18 20:50:00 EDT 2007

On Jul 18, 2007, at 9:09 AM, krbdev-request at wrote:

> Date: Wed, 18 Jul 2007 11:38:46 -0400
> From: Jeffrey Altman <jaltman at>
> Subject: Using Kerberos for authenticating the distribution of
> 	controlled	substances, etc.
> To: "'krbdev at'" <krbdev at>
> Message-ID: <469E3406.5040000 at>
> 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  
> and
> 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  
> user
> "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  
> 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.
> 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, or hbhotz at

More information about the krbdev mailing list