Client Principal Selection

[Jeffrey Altman]

I believe Alexis did a wonderful job describing the various scenarios.
Here are a few additional thoughts I have on the topic.

Prompting:

KFM has always done a much better job of prompting the user than KFW
has.  KFM provides the user with the name of the application that is
attempting to obtain credentials.  Unfortunately, as Alexis aludes to
the name of the application often is not enough.  The user really needs
to know what purpose the credential is going to be used for if any
prompt is going to be at all useful.

Take Mozilla for example.  It provides not only web browsing but ftp
access, calendaring, e-mail, chat services, etc.   All these protocols
are implemented by a single process perhaps with multiple Windows with
individual titles, but it is still a single process.  Before the user
can attempt to determine which principal should be used, she must be
given a much more complete context.  The name of the service principal
being requested might not be all that more helpful given how there
is no one to one mapping of service principal to service.  The "host"
service principal is often used by multiple services plus the name
of the machine on which the service is located might not have any
real meaning to the user.

Another example is AFS.   For each cell a user is going to communicate
with in an authenticate manner, a service ticket must be obtained.
A user may obtain service tickets for multiple cells using the same
user principal but in many cases users have a separate identity
associated with individual cells.  ACLs in AFS can utilize user
principals either derived from the locally associated realm or realms
associated with foreign cells.  What therefore is important to the
end user is knowing that the required credentials are needed by AFS
to access the contents of a particular path within a given cell.  Given
the different privileges associated with different actions it might be
the case that a user must obtain a service ticket with an "admin"
user principal for some actions and not for others.  e.g. "delete" vs
"read".

Therefore, if we are going to support end user prompting in a usable
manner, the APIs that are used to access the Kerberos library really
must obtain context information with which the appropriate dialog
can be constructed.

  * Application
  * Resource Description
  * Action

At the current time the GSSAPI and KRB5 APIs, let alone any new
credential management API based on KLL do not support this type of
information provision and will require modification.


Caching (positive/negative):

Caching should be based not only on the application but also on the
resource description and the desired action.  We can think of obtaining
the correct Kerberos principal the same as a browser treats
username/password data for a web form.   A browser will optionally
cache the responses (username, password, arbitrary data.)   The user
is usually given the option of caching all the data, data minus the
password, or none of it.  Of course, the user must be able to say
"never" use Kerberos for this tuple.  (Although I wonder whether or
not it should be the responsibility of the application author to filter
out the Kerberos negotiation and not leave that to the Kerberos layer.)
  The user may also be given options as to how often the user should be
prompted to confirm the cached data: every time, once per session, or
never (in which case the cached response is automatically used.)

The hardest part about caching is that the cached data really should
not be stored locally for a user.  It should be part of the user's
profile and should roam with the user from machine to machine.  Tools
must be provided to manage this data and reset it as necessary.   If
passwords are being stored, then they must be stored in a secure
location, preferably one provided by the OS.


Searching:

Searching is a great idea but regardless of how it is implemented and
what search algorithm we use there is going to be the case where the
Kerberos library selects the wrong principal.  If we want to avoid
prompting and I believe we do, the question we must answer is this:

  if the library's search algorithm chooses the wrong principal
  for a given appl/resource/action, how is the user supposed to
  correct it in an intuitive easy to use manner?

Perhaps a more important question is:

  if the library's search algorithm chooses the wrong principal
  for a given appl/resource/action, how is the user supposed to identify
  that the wrong principal was utilized when accessing the resource?

The reason this is important is to prevent the accidental use of
credentials with an inappropriate set of access permissions whether.

If we can't answer these two questions, it will be nearly impossible
to roll out a solution that users will accept.


Hints:

The big question I have regarding hints is;

  how are the hints going to be distributed in a secure manner?

One of the things that KenH and I proposed years ago as a means
of providing hints was the DNS TXT records providing host/domain
to realm mappings.  This was implemented in the MIT code but disabled
by default because of the security issues.



Prompting aggressiveness:

I have tended to be a bit more aggressive about obtaining Kerberos
credentials in the tools I have implemented than you have.  Kermit
tried a number of heuristics and prompted the user if there was
any doubt.  As someone supporting an application, I felt it was
important that a user be confronted with the choice of using Kerberos
or not the first time it becomes available to them.  In many application
protocols the user has the choice of sending a clear text password,
a password over TLS, perhaps SRP, and Kerberos.   Organizations as
part of a migration will often construct a Kerberos realm, modify
the backend services to verify the user/password combination against
Kerberos, perhaps use TLS to protect that transmission, and finally
turn on true Kerberos authentication later on.   In this environment,
the users will never use Kerberos unless they are prompted when it
is available.   TLS was used in the past and it will continue to be
used.   Only when Kerberos is offered by the server and the Kerberos
libraries provide the necessary credentials will Kerberos ever end
up being used.

The way I see it, if a service does not accept Kerberos authentication
then it should not be offering it.   If the users are being prompted
when they should not be, its a server administrators responsibility to
fix it.

The circumstance where there would be an issue is the case where
Kerberos is accepted for some users and not for others.   However,
that would certainly be the rare case and I think we should not feel
responsible to code for it.

We can aliviate some of the prompting by giving the user the ability
to turn off the use of Kerberos for the specific request, the service
instance, the domain instance, etc.


Privacy:

One of the issues that has often concerned by regarding the use of
public key credentials for authentication is the fact that a local
list is kept that includes a list of all the hosts/services that
have been contacted by the user.   If the user's credentials are
compromised, a Kerberos preferences cache will give the attacker a map
of all the interesting places that s/he should go to.

There are very similar issues regarding the use of caching in public
facilities.

Sam has also raised the issue of not wanting the system to probe for
Kerberos service tickets as a means of populating a list because doing
so reveals to the realm administrators what the user is attempting to
access even if the service can not be authenticated via Kerberos.


User Interfaces:

Any user of a cache, system configurable hints, or additional
configuration for algorithm selection is going to require the use
of additional user interfaces.  Who is going to build them for all
the affected platforms?


GSS-API and KRB5 API:

As Sam and I have discussed, the existing GSS-API and KRB5 API are
simply not designed with this type of prompting and authentication
caching in mind.   They don't have parameters for specifying the
necessary context information and the flow of control is not at all
optimal for an interactive dialog with an end user.   Both APIs are
designed for use by an application that already has all the information
required from the user up front so that the service credential requested
can simply be obtained or not.

All of the issues we are discussing regarding client principal selection
within Kerberos applies equally well to credentials for arbitrary
GSS mechanisms.  It would seem to me that if we are going to solve the
problem for Kerberos, we might as well solve the general problem for
GSS in the process.   Since GSS is the preferred API for using Kerberos
at the current time, I don't see how we could do one and not the other.

We should probably think about the impact on SASL while we are at it.


Jeffrey Altman





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2707 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20050711/ad8a1fb1/attachment.bin