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

[g.w@hurderos.org]

On Jul 18, 11:38am, jaltman at secure-endpoints.com wrote:
} Subject: Using Kerberos for authenticating the distribution of controlled 

Good afternoon to everyone, hope everyone's week is going well..

Experience has taught me to steer clear of these conversations but
besides being a systems architect I'm a registered pharmacist in a
couple of states and spent a significant segment of time designing and
building healthcare MIS infra-structure.

So, some comments in the spirit of Don Quixote.

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

We actually have, at some length.

The basic problem is that the basic problem is not authentication, its
authorization.  As everyone who has been reading these forums will
know the mantra is 'Kerberos does authentication, authorization is an
application issue'.  Unfortunately the 'real world' cares little about
authentication and is much more concerned about authorization.

In this case, technically, the issue is 'user immediacy' but for all
intents and purposes its an authorization problem.  The application
already knows who the user is, the real issue is whether or not the
user is authorized to implement a transaction of some type.

Even more correctly the problem is one of digital signing but that is
even more problematic.

Since the only tool applications have is authentication the problem
gets fixed by hitting it with that hammer.  In this case multiple
authentications to prove that someone who is authorized to execute a
particular type of procedure is running the controls.

Without better infra-structure or a more expansive vision the best
solution is to make it easy for applications to re-request
authentication credentials.  Actually all that is needed is the
authentication secret since the application already knows the identity
of the user via their logon credentials.

Most of the thinking which went into IDfusion and OTI was based on a
lot of experience with these issues.  In this case OTI provides a
framework for a mixed mode user interaction where existing
authentication credentials can be used in combination with a USB based
dongle to provide validation of user immediacy.

Interestingly healthcare already understands and can mechanistically
deal with this model.  Anyone who has been observant around
institutional healthcare probably has seen nursing staff with a wire
stretch bracelet with a key dangling from it, thats the 'narc cabinet'
key.

All that is needed is sufficient cleverness to convert that dongle
into something more electronic, and of course vision to use it.

The only real certainty in all this is that you need support and
participation from the application and its creators.  The problem
can't be fixed unilaterally with better authentication tools.

> Jeffrey Altman
> Secure Endpoints Inc.

Best wishes for a pleasant weekend to everyone.

}-- End of excerpt from jaltman at secure-endpoints.com

As always,
Greg Wettstein

------------------------------------------------------------------------------
			 The Hurderos Project
         Open Identity, Service and Authorization Management
                       http://www.hurderos.org

"Those who will not study history are doomed to debug it."
                                -- Barry Shein