client principal selection and UI

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

client principal selection and UI

hartmans



About a year ago we talked about selecting the realm (and thus client
principal) based on the target principal you are using.

We've gotten more interest in going forward with that work.  I'd like
to talk a bit more about one vision of a UI for that.  Alexis may have
another idea.  What is clear is that the UI is complicated and there
are a lot of API and usability concerns.  Please consider the
following discussion points.  We will need rounds of discussion
looking at how easy this is to implement and about how it departs from
what we do now.


I'd like to ignore several issues at this level.  First, I'd like to
ignore cases wher you have administrative or non-null-instance
tickets.  Second I'd like to ignore cases where you are using a client
principal different than the one you typically expect to use.  In
short I want to focus on default behavior.  Clearly we need to support
non-default behaviors as well but let's optimize for the default case.

So, you're going to a service that you've not gone to before and for
which you don't have good hinting information.  You will know the
hostname and service name; you may know the full target principal.

You pop up a authentication dialogue.  You default the client
principal to the default client principal.  The user can enter in a
client principal of their choosing.  You now know what client
principal to use for contacting this service.  You need to get tickets
for this client principal and you need to decide what realm to use.

Here are possibilities for what realm to use.  You can try the realm
of the client principal hoping for success or for a referral.  You can
try the realm that is indicated by your domain_realm mapping.  You can
ask the user.  Asking the user seems wrong: most users will have
enough trouble dealing with the client realm and will not be able to
deal with both a client and server realm separately.  Another option
is a certificate-like behavior where you ask the server what realm it
wants and pop up a dialogue if it doesn't meet some heuristics.


You then remember that this client principal is used with this server.
The question is how strong of a binding do you want?  Do you want to
bind to all servers in that domain?  Only this server?  How long term
of a binding do you want?  Does the binding mean you won't pop up a
dialogue ne next time if you have tickets for the bound client
principal, or will you pop up a dialogue with the fields filled in
already?

Another question.  How do you make the experience work well if the
user already has tickets for the client principal they select?  One
option is to always make them enter in a password and get new tickets
when you pop the dialogue.  Another option is to allow OK to be
pressed without entering a password if you already have tickets for
that principal.  Another option (probably undesirable) is to separate
the password entry from the principal entry.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: client principal selection and UI

hartmans

There are a few things that I forgot to mention.  Frist, you will note
that my proposal completely ignores the concept of a default
principal.  The proposal is focused on an environment wher eyou have a
lot of different services and realms and it is not clear you have a
meaningful default principal.  I consider the question of deciding
when default principals are useful and how they should work to be
open.  I don't have good answers.

The other big open issue is how you get default hinting.  For example
you probably want some hinting so that you don't have to get prompted
for the first time you talk to each service in your own local domain.

I'll note that other models are possible that are a lot closer to what
we have today.

--Sam

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: client principal selection and UI

Henry B. Hotz
In reply to this post by hartmans
Following just my totally offhand opinions, and I may be wrong, in fact  
I've already changed my mind.  ;-)

On Jun 30, 2005, at 9:44 AM, [hidden email] wrote:

> Date: Wed, 29 Jun 2005 16:31:19 -0400
> From: Sam Hartman <[hidden email]>
> To: [hidden email]
> Cc: [hidden email]
> Subject: client  principal selection and UI
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 2
>
>
>
>
> About a year ago we talked about selecting the realm (and thus client
> principal) based on the target principal you are using.
>
> We've gotten more interest in going forward with that work.  I'd like
> to talk a bit more about one vision of a UI for that.  Alexis may have
> another idea.  What is clear is that the UI is complicated and there
> are a lot of API and usability concerns.  Please consider the
> following discussion points.  We will need rounds of discussion
> looking at how easy this is to implement and about how it departs from
> what we do now.
>
>
> I'd like to ignore several issues at this level.  First, I'd like to
> ignore cases wher you have administrative or non-null-instance
> tickets.  Second I'd like to ignore cases where you are using a client
> principal different than the one you typically expect to use.  In
> short I want to focus on default behavior.  Clearly we need to support
> non-default behaviors as well but let's optimize for the default case.
>
> So, you're going to a service that you've not gone to before and for
> which you don't have good hinting information.  You will know the
> hostname and service name; you may know the full target principal.

If you already have a service ticket for any client that matches the  
target then try it.  Of course to get to that point . . .

> You pop up a authentication dialogue.  You default the client
> principal to the default client principal.  The user can enter in a
> client principal of their choosing.  You now know what client
> principal to use for contacting this service.  You need to get tickets
> for this client principal and you need to decide what realm to use.

Pop-up selection, based on existing tgt's (or recently acquired  
tgt's?), or fill-in.

> Here are possibilities for what realm to use.  You can try the realm
> of the client principal hoping for success or for a referral.  You can
> try the realm that is indicated by your domain_realm mapping.  You can
> ask the user.  Asking the user seems wrong: most users will have
> enough trouble dealing with the client realm and will not be able to
> deal with both a client and server realm separately.  Another option
> is a certificate-like behavior where you ask the server what realm it
> wants and pop up a dialogue if it doesn't meet some heuristics.

I like the idea of asking the server what it wants.  (DOS concern?)  
Some kind of fall-back to current d-r mapping behavior, then client  
realm (if different) (for referral).

That assumes that fallback/retry is feasible.  Reasonable assumption?

> You then remember that this client principal is used with this server.
> The question is how strong of a binding do you want?  Do you want to
> bind to all servers in that domain?  Only this server?  How long term
> of a binding do you want?  Does the binding mean you won't pop up a
> dialogue ne next time if you have tickets for the bound client
> principal, or will you pop up a dialogue with the fields filled in
> already?

Bind just the single server (but all services on it) permanently.  
Don't think you can presume the (DNS?) domain is the right boundary in  
all environments.  No UI if you have a binding, but need to make sure  
you re-present the initial dialog if you have any errors that might  
indicate a change/error in the binding.

However what I just said would probably result in a  
confusing/distracting dialog box after unrelated errors.  Not good.

I don't think I like any user interaction on this point.  I don't like  
spurious error messages.  I don't like making unjustifiable assumptions  
about the scope of a realm.

> Another question.  How do you make the experience work well if the
> user already has tickets for the client principal they select?  One
> option is to always make them enter in a password and get new tickets
> when you pop the dialogue.  Another option is to allow OK to be
> pressed without entering a password if you already have tickets for
> that principal.  Another option (probably undesirable) is to separate
> the password entry from the principal entry.

See above imprecise statement.  They select from a menu.  If the  
selection is for an existing credential, done.  If selection is for a  
historical credential, filled-in dialog.  If selection is "new", then  
not-filled-in dialog.

I guess this matches what you said was probably undesirable, and a  
double-dialog interaction is an issue unless you can convince yourself  
that the second one will only rarely be needed.

I don't think the Mac UI guidelines would allow a pop-up menu to  
auto-close its dialog box after a selection.  I don't like the idea of  
presenting fill-in fields that are usually to be left blank.

If I suggest that the lower portion of the dialog should morph based on  
the pop-up selection at the top, is that reasonable to do  
cross-platform?

> ------------------------------
>
> Date: Wed, 29 Jun 2005 18:35:00 -0400
> From: Sam Hartman <[hidden email]>
> To: [hidden email]
> Cc: [hidden email]
> Subject: Re: client  principal selection and UI
> Message-ID: <[hidden email]>
> In-Reply-To: <[hidden email]> (Sam Hartman's message of  
> "Wed, 29
>  Jun 2005 16:31:19 -0400")
> References: <[hidden email]>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 3
>
>
> There are a few things that I forgot to mention.  Frist, you will note
> that my proposal completely ignores the concept of a default
> principal.  The proposal is focused on an environment wher eyou have a
> lot of different services and realms and it is not clear you have a
> meaningful default principal.  I consider the question of deciding
> when default principals are useful and how they should work to be
> open.  I don't have good answers.

User preference selection.  I'll reserve what the default preference  
should be until I see what we come up with.

> The other big open issue is how you get default hinting.  For example
> you probably want some hinting so that you don't have to get prompted
> for the first time you talk to each service in your own local domain.

If there's a reasonable way to ask the server, that would seem to be  
ideal.

> I'll note that other models are possible that are a lot closer to what
> we have today.
>
> --Sam
------------------------------------------------------------------------
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[hidden email], or [hidden email]

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: client principal selection and UI

Jeffrey Altman-4
In reply to this post by hartmans
I know that Sam is aware of this but I figure I should make it clear for
everyone else on the list.   Whatever path we choose to take is going to
require changes to both the raw krb5 api and the gss api.  At the moment
we have some hooks in the gss_acquire_cred() that allow an "Obtain
Credentials" dialog to be displayed to the user when there are no TGTs
available.

Unfortunately, there is simply not enough information available within
gss_acquire_cred() to determine which principal to use.   The function
does not have access to the service name the application eventually
wants to communicate with.   Without that information, we might as well
choose a random principal.

Assuming that we did have access to the service name, we would be able
to build a database of user principal names and passwords that had
previously used to access the service in the past.   I believe the model
we desire is very similar to the one currently implemented in browsers.
When you go to a web page that requires authentication, you are asked to
provide the necessary credential.  In the case of username and password,
the browser will remember the user name and optionally the password.
The next time you go to the page the browser will use the information
you provided the previous time to pre-populate the enter credential
information dialog.   If you used multiple names to access the page,
you are given a choice of which you want to use and the ability to
enter a new name.

With regard to the question of "should a user be required to enter
the password again if an existing TGT for the specified principal
already exists?"   I believe the answer is that we should not.  In the
OpenAFS for Windows Credential Manager I added the ability to re-use
an existing principal with a TGT for obtaining service tickets.   In
my UI, the password field is disabled if the user already has a valid
TGT.  I think this is the appropriate model.

I should point out that there has been much discussion regarding access
to HIPPA protected services.   Under the HIPPA rules, when a user
accesses a HIPPA protected service, the user MUST re-authenticate to the
login server for each and every access.  According to these rules, a
user would always have to obtain an Initial Service Ticket for the
service when the service is accessed.  Using a TGT to obtain the service
ticket is not permitted.  The only way that a client would know this is
by querying the KDC or some other remote database.

The downside of permanently caching all of this data is that we must
provide UIs for the user to manage it.

I can ramble some more on this topic in the future.

Jeffrey Altman


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: client principal selection and UI

Love Hörnquist Åstrand
In reply to this post by hartmans

Sam Hartman <[hidden email]> writes:

> About a year ago we talked about selecting the realm (and thus client
> principal) based on the target principal you are using.

I talked to Alexis about this yestoday. The first time I read your mail I
felt I was missing some part of the discussion.

I think the imporant part is to first define what problems we want to solve
(use cases, common problems today) , so that is clear to all involved, and
then how to define a good user interface to encourage secure user behavior.

Love


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

attachment0 (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Client Principal Selection

Alexandra Ellwood
In reply to this post by hartmans

I'm a little concerned that we're starting to look at this from an  
implementation standpoint before we have a clear idea of what our  
constraints are, what the algorithm needs to do, and which site  
configurations it will support.  Before launching into proposals for  
a client principal selection algorithm, I'd like to outline our goals  
and requirements.


---------
The Goal:
---------

Over the past couple years MIT has been seeing an increasing number  
of requests for better support for users with multiple client  
principals.  Currently these users must manually switch back and  
forth between client principals, resulting in a cumbersome and  
frustrating user experience.  We would like to improve this process.


-------------------
Timing Constraints:
-------------------

The reason for the sudden interest in this is that we are in the  
early stages of redesigning Kerberos for Macintosh's KLL (Kerberos  
Login Library) to be cross platform.  The KLL is fundamentally an API  
for initial ticket acquisition, and in an environment with multiple  
client principals that also means it needs to be aware of client  
principal selection.  As a result, we feel that it is important to  
decide how we are going to solve the client principal selection  
problem before redesigning the KLL.  Otherwise the new KLL may end up  
limiting what we can do.


-----------------
The Requirements:
-----------------

A number of different site configurations affect client principal  
selection.  Since many of these can be combined at a single site, and  
a given user may use multiple sites, it is critical that we behave  
reasonably when these configurations or combinations of them are used  
simultaneously.

In particular, it is important that our new client principal  
selection algorithm not result in behavior which is less desirable  
than the existing behavior for any given configuration.  Otherwise we  
will effectively "break" that configuration.


1) Cross-realm authentication

The cross-realm authentication is currently the best-supported  
configuration.  Users acquire a TGT for a single client principal  
automatically get service tickets for other realms without any user  
input.  Since there is only one client principal, no principal  
selection algorithm is needed.


2) Client principals for multiple realms with no cross-realm  
authentication

In this configuration users have identities in multiple realms.    
These realms correspond to departments in an organization or multiple  
organizations.  For political (ie: not technically solvable) reasons  
the realms cannot shared keys.   As a result, users must  
independently acquire ticket granting tickets for multiple realms.

Selecting for the correct client principal is critical to sane  
application behavior.  For example, let's say we have a user John Doe  
who has identities with his company's IT department  
([hidden email]), which he uses for email and also the QA  
department ([hidden email]) which he uses to connect to the  
QA department's ticket tracking system.  Due to political reasons  
inside his company, COMPANY.COM and QA.COMPANY.COM don't share keys.

Now if John has both his email and ticket tracking applications  
running, each application needs to find the right tickets, and the  
current "system default client principal" and KRB5CCNAME model  
becomes problematic.  To check his email, John must select the ticket  
cache containing tickets for "[hidden email]" and then click the  
"check mail" button.  To view the contents of a ticket in the ticket  
tracking system, John must then select the ticket cache containing  
tickets for "[hidden email]" and open the ticket.  As you  
might imagine, manually switching client principals gets old fast.

Currently sites in this situation create scripts which set KRB5CCNAME  
to the cache with the appropriate tickets and then launch the  
relevant application.  Users then use these scripts to launch the  
application rather than launching the application itself so that each  
application gets its own default ccache.  Unfortunately this requires  
sysadmin involvement in the setup of client machines and interacts  
poorly with the graphical user experience on some OSes (eg: Windows  
and Mac OS X).


3) Multiple client principals with different privileges (ie:  
[hidden email] and user/[hidden email])

Some sites like to provide highly privileged users (sysadmins,  
financial staff, etc) with client principals with different  
privileges.  For example, a sysadmin who just wants to read a  
newsgroup doesn't need the ability to delete it and wouldn't want to  
accidentally do so anyway.  In this configuration users use their  
unprivileged identities when performing basic activities and only  
switch over to the privileged identity when they need it.

Currently these users switch back and forth between identities using  
the system default client principal (KfM) or KRB5CCNAME.  It is  
important that our new principal selection algorithm continue to  
provide these users with some control over which principal gets  
used.  However, since these users are usually more technical than the  
average user, we can make this functionality more obscure than a  
regular user feature.


4) Use of SASL/TLS/SPNEGO to negotiate something other than Kerberos

Unfortunately, not all organizations and services use Kerberos.  When  
negotiating authentication (ie: SASL/TLS/SPNEGO/etc), it is important  
that we not interfere with the negotiation of other authentication  
systems.

Currently Kerberos for Macintosh does a rather poor job of this.  If  
the user has no tickets at all and tries to connect to a service  
which can negotiate Kerberos, KfM will prompt the user to get  
Kerberos tickets.  If the user can't use Kerberos to connect to that  
service, they have to hit cancel every time they connect.  We have  
alleviated this problem somewhat by only prompting if a krb5.conf  
file is present, which means that only Kerberos users who do not  
currently have tickets see this problem.  This is really a band-aid  
solution though.


5) Use of applications which perform scheduled tasks in the background

A number of sites make use of long running processes which perform  
Kerberos-authenticated operations at regular intervals.  Probably the  
most common of these are mail applications which check mail every N  
minutes.

When designing our selection algorithm we should be aware that if we  
prompt the user from inside the library, we may be doing it  
frequently and not in response to any user action.  In particular we  
need to avoid popping up questions over whatever task the user is  
really doing, interrupting them and stealing focus from the frontmost  
application.


6) Ticket acquisition via secure authentication screens

Windows tries to get users to authenticate via its secure login  
screen.  Due to the fact that it's really easy to spoof regular  
authentication dialogs and steal the user's password, I suspect that  
other operating systems are eventually going to implement something  
similar.  At that time we should probably start using it and would no  
longer be able to seamlessly prompt the user for new tickets.


7) Referrals

Traditional Kerberos installations use fully qualified hostnames and  
domain-realm mappings to generate service principals (ie: the "imap"  
service on "po12.mit.edu" maps to the service principal "imap/
[hidden email]").  This allows clients to generate the  
service principal from the configuration entered by the user.  
Unfortunately this feature requires that the Kerberos sysadmins have  
DNS servers (so clients can reverse resolve the server name) and  
tightly couple domains and realms so that the client correctly maps  
the server's domain to the correct realm.  In addition, without  
secure DNS this technique is vulnerable to spoofing.

Instead of using DNS, Kerberos referrals use the KDC.  Referrals  
allow the client to contact a KDC in the client principal's realm to  
find out the service principal corresponding to a given service and  
server name pair.

What this means for client principal selection is that figuring out  
if a given client principal is correct for a given server/service  
pair requires an extra communication with the client principal's KDC  
to get the service principal via a referral.



---------------
The Algorithms:
---------------

Rather than suggesting a complete and finished algorithm, I'd like to  
suggest a series of sub-algorithms which we can use to make a final  
algorithm.  The reason for this is that I think that there is no one  
"ideal" algorithm and that there are multiple reasonable algorithms.  
By breaking the algorithms down into the components, we should be  
able to describe and compare them more easily.


* Prompting the User:

The most trivial algorithm is just to ask the user which principal to  
use.  The problem with asking is that once a large number of sites  
and services start using Kerberos, the questions become longer and  
more complicated.

For example, another hypothetical user, Jane Doe, works for the IT  
department of a company (company.com) that does not use cross-realm  
and has separate realms for each department.  In addition, Jane also  
has an account with a Kerberized email service (secure-email.com) for  
her personal email.  Here's an example of what she would see when she  
runs her mail program:

> janedoe % email
>
> The application 'email' would like to use Kerberos to communicate  
> with the server 'imap26.company.com' using the service 'imap'.  
> Which Kerberos identity would you like to use?
>         N: Don't use Kerberos.
>         1: [hidden email]
>         2: [hidden email]
>         3: [hidden email]
>         P: None of the above.  (Prompt to get tickets for a new  
> identity.)
> (Default=1):

The problem is that Jane may not know what principal to use.  Most of  
us could guess that the first principal "[hidden email]" is the  
right one to use.  But maybe the IT department has its own email  
services (but not its own subdomain) and the answer is really  
"[hidden email]".

To make matters worse, Jane may have configured her mail program to  
check mail for both her work email and her secure-email account.  If  
this is the case she will get this question twice (once for each  
mailbox) and need to answer "2" the first time and "3" the second  
time.  If she hasn't already gotten tickets for  
'[hidden email]' and '[hidden email]', then she  
will have to answer "P" twice and enter those two principal names  
from memory.


* Caching:

Obviously asking this question every time the user performs an  
operation is unacceptable.  Fortunately we can cache mappings from  
server/service to client principal.  This means that if Jane uses  
Kerberos for email, she will only be asked the first time.  This  
functionality is critical for applications which perform periodic  
tasks from the background.


* Negative Caching:

Let's say Jane has a third email account which does not use Kerberos,  
but runs servers which are capable of negotiating Kerberos via TLS.  
To avoid prompting Jane to answer "N" every time through, we would  
also need to cache negative cache entries (ie: 'don't use any client  
principal for service 'imap' and server 'imap.company.com').

Unfortunately, if we do negative caching, then we will run into  
problems when a site using SASL/TLS/SPNEGO adds Kerberos support for  
a service that previously didn't support it.  Because the service  
didn't previously support Kerberos, users will have cache entries  
that say not to use Kerberos.  Rather than a seamless upgrade, the  
site would have to force all the users to run some tool that removes  
the negative entry from their cache.  This greatly reduces the  
usefulness of wrapping Kerberos in authentication negotiation systems  
like SASL, SPNEGO and TLS.

(Note that stale data is not a problem for positive caching because  
if the client principal fails to get the service ticket for the  
service then we know the entry is stale and can delete it.)


* Searching:

Caching doesn't prevent the user from being prompted the first time,  
and the more wide-spread Kerberos adoption gets, the longer the  
client principal selection list will be.  If the user's first  
experience with Kerberos is a series of long thought-provoking  
questions from each Kerberized application, we're not going to be  
winning any popularity contests -- especially with the site support  
staff. :-)

In particular, if the correct client principal is obvious (eg:  
connecting to a server at secure-email.com requires tickets at SECURE-
EMAIL.COM), the user will wonder why the system didn't just select  
the correct ticket automatically.  If the correct client principal  
isn't obvious (eg: cross-realm is involved), then novice users won't  
know which one to select.

Rather than prompting the user and having the site's support staff  
hand-holding all their users through these questions, we could search  
for the correct principal in the cache collection.  Here's a  
potential simplistic cache search order:

1) client principal of the system default cache

Searching the system default cache first allows the user to control  
which principal is selected if user has tickets for multiple  
principals which can access the service.  So if the user has  
user@REALM and user/admin@REALM they can keep user@REALM selected as  
the default and know that user/admin@REALM won't accidentally get used.

2) client principals in the realm mapped to by the server's domain

Searching matching realms next prevents obscure cross-realm paths  
from being used when there is a direct path available.  For example  
if realms A.COM and B.COM share keys and the user has tickets for  
[hidden email] and [hidden email], when the user tries to connect to  
server.a.com, they won't accidentally end up using their [hidden email]  
tickets.  (Note that we could come up with an even more elaborate  
algorithm so that we use the shortest cross-realm path or the most  
trusted one -- I just don't want to get bogged down in details.)

3) remaining client principals

Necessary to catch any referrals-based or cross-realm paths.


* Site-provided Hints:

Unfortunately, as the number of principals the user has tickets for  
increases, searching will get expensive.  Under pessimal network  
conditions this could be unacceptably slow.

Another way to generate the initial mappings would be to create a  
command line tool, API or protocol extension for generating hints.  
These hints would assist the Kerberos library in finding appropriate  
client principals, greatly reducing the number of client principals  
the search algorithm would have to try.  Then each site the user uses  
could populate a hints table for their users.

For example, a hint like "imap,imap*.company.com" -> "*@COMPANY.COM"  
could tell the cache that for the imap service server  
imap26.company.com, it should search for client principals in the  
realm COMPANY.COM.

Note that hints are not the same as a cache entry.  A cache entry  
corresponds to a successful authentication and indicates which  
specific client principal should be used for a given server/service  
pair.  A site-provided hint is really just a suggestion for which  
client principals to try first to optimize searching.



---------------------------
Initial Ticket Acquisition:
---------------------------

As you've probably noticed, I have yet to discuss how the user gets  
TGTs in the first place.  The reason I delayed this discussion is  
that it's probably the hardest part to get right.  On the one hand  
we'd like to make Kerberos as easy to use and prompt the user rather  
than producing a "no tickets -- go run kinit" error.  On the other  
hand we can't harass non-Kerberos users with Kerberos related questions.

Whether or not it's okay to prompt depends on what information the  
Kerberos libraries currently have about the server and service.  As a  
result I'll break this discussion down into the various states the  
library can be in at the time it would like to ask the user for more  
information.  Note that in all the cases here that the library has  
already tried all the tickets in the cache collection.


* A cache entry exists for the server/service pair

In this case it should be safe to prompt if no tickets (or only  
expired tickets) for the client principal exist.  If a cache entry  
exists then we know the user has successfully used Kerberos for this  
service already, and we know which client principal the user needs to  
get.  Because we know the client principal, we can even pre-fill the  
authentication dialog/prompt with the client principal in the cache  
entry so the user knows which principal they need to get tickets for.


* A hint exists for the server/service pair but no cache entry

Whether or not we prompt here really depends on how we decide hints  
should be used.  If hints are something you provide even if the  
service doesn't use Kerberos, then we shouldn't prompt.  But if the  
presence of a hint indicates the service probably uses Kerberos, then  
we should prompt, filling in as much information about the client  
principal as possible.  I would recommend the latter since it allows  
sites to use hints to improve the user experience (ie: Kerberos will  
work without a hint, but will be more user-friendly if you have one).


* No hint or cache entry exists

This is the real problem case.  I would argue that you can't prompt  
here.  The problem is that if you are using SPNEGO/TLS/SASL, you  
don't know whether or not the user even wants to use Kerberos.  If  
they don't, then prompting will only irritate them.




At this point I'd like to ask folks for their opinions on this before  
getting any further into the details.  In particular I'd like to know  
if I've missed any configurations that impact client principal  
selection and whether folks agree with my views on prompting the user  
for client principal selection (don't if you can possibly avoid it)  
and initial ticket acquisition (only if you know the user wants to  
use Kerberos).


--lxs

Alexandra Ellwood <[hidden email]>
MIT Kerberos Development Team
<http://mit.edu/lxs/www>


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Client Principal Selection

Nicolas Williams
On Fri, Jul 08, 2005 at 04:29:27PM -0400, Alexandra Ellwood wrote:
[...]

> 2) Client principals for multiple realms with no cross-realm  
> authentication
>
> In this configuration users have identities in multiple realms.    
> These realms correspond to departments in an organization or multiple  
> organizations.  For political (ie: not technically solvable) reasons  
> the realms cannot shared keys.   As a result, users must  
> independently acquire ticket granting tickets for multiple realms.
>
> Selecting for the correct client principal is critical to sane  
> application behavior.  For example, let's say we have a user John Doe  
> who has identities with his company's IT department  
> ([hidden email]), which he uses for email and also the QA  
> department ([hidden email]) which he uses to connect to the  
> QA department's ticket tracking system.  Due to political reasons  
> inside his company, COMPANY.COM and QA.COMPANY.COM don't share keys.

[...]

> 3) Multiple client principals with different privileges (ie:  
> [hidden email] and user/[hidden email])
>
> Some sites like to provide highly privileged users (sysadmins,  
> financial staff, etc) with client principals with different  
> privileges.  For example, a sysadmin who just wants to read a  
> newsgroup doesn't need the ability to delete it and wouldn't want to  
> accidentally do so anyway.  In this configuration users use their  
> unprivileged identities when performing basic activities and only  
> switch over to the privileged identity when they need it.
>
> Currently these users switch back and forth between identities using  
> the system default client principal (KfM) or KRB5CCNAME.  It is  
> important that our new principal selection algorithm continue to  
> provide these users with some control over which principal gets  
> used.  However, since these users are usually more technical than the  
> average user, we can make this functionality more obscure than a  
> regular user feature.

I see these two as very similar problems.  Both can be addressed with
notions of environment variables, trust partitions, AFS-like PAGs or
variants thereof -- each application instance then has access to only
one set of TGTs for only one client principal.  I think that could be
seen as very user-friendly in some cases, as not at all user-friendly in
others.

In any case, use of any OS facility more advanced than environment
variables runs into portability problems.


> 4) Use of SASL/TLS/SPNEGO to negotiate something other than Kerberos

Are you saying that you may want KLL to support initial credential
acquisition for mechanisms other than Kerberos V?

A generic facility (i.e., not mechanism-specific, though perhaps with
mechanism-specific options) for initial credential acquisition is highly
desirable.


> 7) Referrals
>
[...]
> Instead of using DNS, Kerberos referrals use the KDC.  Referrals  
> allow the client to contact a KDC in the client principal's realm to  
> find out the service principal corresponding to a given service and  
> server name pair.

But this implies cross-realm configuration, if not even cross-realm
keys.

Perhaps we need a requirement for the referrals work that it allow for
referrals where no cross-realm keys have been exchanged.

> What this means for client principal selection is that figuring out  
> if a given client principal is correct for a given server/service  
> pair requires an extra communication with the client principal's KDC  
> to get the service principal via a referral.

Which the client was going to do anyways.  I don't mind the
infrastructure -- everyone seems to want some online infrastructure
nowadays.

> ---------------
> The Algorithms:
> ---------------
>
[...]
> * Prompting the User:
>
> The most trivial algorithm is just to ask the user which principal to  
> use.  The problem with asking is that once a large number of sites  
> and services start using Kerberos, the questions become longer and  
> more complicated.

Also, it isn't always possible to ask.


[...]
> * Caching:
>
> Obviously asking this question every time the user performs an  
> operation is unacceptable.  Fortunately we can cache mappings from  
> server/service to client principal.  This means that if Jane uses  
> Kerberos for email, she will only be asked the first time.  This  
> functionality is critical for applications which perform periodic  
> tasks from the background.

But you'd still have to ask when priming the cache, and you'd have to
know how long to cache mappings for, a way to clean the cache...


> * Searching:
>
> Caching doesn't prevent the user from being prompted the first time,  
> and the more wide-spread Kerberos adoption gets, the longer the  
> client principal selection list will be.  If the user's first  
> experience with Kerberos is a series of long thought-provoking  
> questions from each Kerberized application, we're not going to be  
> winning any popularity contests -- especially with the site support  
> staff. :-)
>
> In particular, if the correct client principal is obvious (eg:  
> connecting to a server at secure-email.com requires tickets at SECURE-
> EMAIL.COM), the user will wonder why the system didn't just select  
> the correct ticket automatically.  If the correct client principal  
> isn't obvious (eg: cross-realm is involved), then novice users won't  
                                   ^
                                   not?
> know which one to select.

[...]
> * Site-provided Hints:
>
> Unfortunately, as the number of principals the user has tickets for  
> increases, searching will get expensive.  Under pessimal network  
> conditions this could be unacceptably slow.

And the prompts get longer too.

> Another way to generate the initial mappings would be to create a  
> command line tool, API or protocol extension for generating hints.  
> These hints would assist the Kerberos library in finding appropriate  
> client principals, greatly reducing the number of client principals  
> the search algorithm would have to try.  Then each site the user uses  
> could populate a hints table for their users.
>
> For example, a hint like "imap,imap*.company.com" -> "*@COMPANY.COM"  
> could tell the cache that for the imap service server  
> imap26.company.com, it should search for client principals in the  
> realm COMPANY.COM.
>
> Note that hints are not the same as a cache entry.  A cache entry  
> corresponds to a successful authentication and indicates which  
> specific client principal should be used for a given server/service  
> pair.  A site-provided hint is really just a suggestion for which  
> client principals to try first to optimize searching.

But since many users could not be expected to provide these this
approach implies more distributed configuration/online infrastructure.

[...]
> At this point I'd like to ask folks for their opinions on this before  
> getting any further into the details.  In particular I'd like to know  
> if I've missed any configurations that impact client principal  
> selection and whether folks agree with my views on prompting the user  
> for client principal selection (don't if you can possibly avoid it)  
> and initial ticket acquisition (only if you know the user wants to  
> use Kerberos).

This is going to be fun.

The need for interaction in initial ticket acquisition [usually :)]
cannot be avoided; use of a consistent system-wide mechanism for this is
desirable.

For the rest, clearly prompting is a vary bad idea.  Don't do it.  If it
means more configuration, oh well.  See above.

Cheers,

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Client Principal Selection

Alexandra Ellwood

On Jul 11, 2005, at 2:31 PM, Nicolas Williams wrote:

> On Fri, Jul 08, 2005 at 04:29:27PM -0400, Alexandra Ellwood wrote:
> [...]
>
>> 2) Client principals for multiple realms with no cross-realm
>> authentication
>>
>> In this configuration users have identities in multiple realms.
>> These realms correspond to departments in an organization or multiple
>> organizations.  For political (ie: not technically solvable) reasons
>> the realms cannot shared keys.   As a result, users must
>> independently acquire ticket granting tickets for multiple realms.
>>
>> Selecting for the correct client principal is critical to sane
>> application behavior.  For example, let's say we have a user John Doe
>> who has identities with his company's IT department
>> ([hidden email]), which he uses for email and also the QA
>> department ([hidden email]) which he uses to connect to the
>> QA department's ticket tracking system.  Due to political reasons
>> inside his company, COMPANY.COM and QA.COMPANY.COM don't share keys.
>>
>
> [...]
>
>
>> 3) Multiple client principals with different privileges (ie:
>> [hidden email] and user/[hidden email])
>>
>> Some sites like to provide highly privileged users (sysadmins,
>> financial staff, etc) with client principals with different
>> privileges.  For example, a sysadmin who just wants to read a
>> newsgroup doesn't need the ability to delete it and wouldn't want to
>> accidentally do so anyway.  In this configuration users use their
>> unprivileged identities when performing basic activities and only
>> switch over to the privileged identity when they need it.
>>
>> Currently these users switch back and forth between identities using
>> the system default client principal (KfM) or KRB5CCNAME.  It is
>> important that our new principal selection algorithm continue to
>> provide these users with some control over which principal gets
>> used.  However, since these users are usually more technical than the
>> average user, we can make this functionality more obscure than a
>> regular user feature.
>>
>
> I see these two as very similar problems.  Both can be addressed with
> notions of environment variables, trust partitions, AFS-like PAGs or
> variants thereof -- each application instance then has access to only
> one set of TGTs for only one client principal.  I think that could be
> seen as very user-friendly in some cases, as not at all user-
> friendly in
> others.

They're similar problems given the current KRB5CCNAME/system default  
principal model of client principal selection.  However, once we  
start caching or searching they become different problems because in  
#2 it's very likely that only one of the client principals can  
actually authenticate to the service -- or that one authentication  
path is obviously preferable to the other.  In #3 both the user@REALM  
and user/admin@REALM principals can successfully authenticate.

Note that the KRB5CCNAME/system default principal model is  
insufficient for applications like Mail.app or Eudora which support  
getting email for multiple accounts.  Fortunately right now we  
haven't gotten users with two Kerberos-using email accounts, but if  
we're successful in increasing Kerberos deployment we'll eventually  
have some.


> In any case, use of any OS facility more advanced than environment
> variables runs into portability problems.

Once the CCAPI gets ported to Unix we should have a lot more  
flexibility in what we can do.  The CCAPI only requires the OS  
provide a local RPC and has been written to support two platforms  
with wildly different local RPC models (Mac OS X and Windows).  The  
rest of the CCAPI functionality is provided through the RPC layer  
including the ability to have multiple ccaches and iterate over them.


>> 4) Use of SASL/TLS/SPNEGO to negotiate something other than Kerberos
>>
>
> Are you saying that you may want KLL to support initial credential
> acquisition for mechanisms other than Kerberos V?

No, the KLL is actually primarily intended for GUI programs that  
perform the functionality of kinit/klist/kdestroy/etc (ie: a  
replacement for the krb5_get_init_creds* APIs).  It provides APIs for  
seamless acquisition and control of both v4 and v5 tickets,  
controlling ticket options, graphical hardware preauth prompting, and  
plugins for automatically performing operations (like getting AFS  
tokens) on ticket acquisition and renewal.

Much of the KLL use is internal to the Kerberos for Macintosh  
product.  However, the Mac platform also has a reasonable number of  
callers which use the KLL to "get around" the limitations of the  
current KRB5CCNAME/system default principal model or to provide their  
own custom interface for ticket acquisition.  I've seen several  
postings to the Kerberos lists from folks calling krb5_init_creds*  
from their application for basically the same reasons so I assume if  
we provide a KLL for Unix and Windows they will come. :-)

Since all the platform specific GUI code for ticket acquisition lives  
in the KLL, it's also what the krb5 library calls on the Mac to  
automatically prompt the user to renew their tickets.  The call that  
does this is private, but makes extensive use of the regular KLL APIs.


The initial reason we started redesigning the KLL is that it needs to  
become thread-safe and lose a lot of its Macintosh specific aspects  
before it can become cross-platform.  We'd also like to make it more  
object-oriented so it's easier to write an OOP version of the API.  
However, once I started working on it, I realized that the current  
API is focused on client principals.  In particular it expects  
callers to always know the client principal or want to use the one in  
KRB5CCNAME/the system default ccache.  I got to talking to Sam about  
how this model meshes with the concept of client principal selection  
and we realized that it would be very difficult to use the current  
KLL with some of the algorithms we were proposing.  So I'd like to  
pick a client principal selection algorithm before doing the KLL  
rewrite.


I don't think the new KLL is ever going to be a good fit for a  
generic initial credential API.  In order to provide a good user  
experience, it needs to expose far too much of the details of  
Kerberos (principal formats, ticket options, etc).  If it didn't, the  
GUI authors wouldn't be able to give the user enough control.  What  
the KLL is good at is masking a lot of the details from the novice  
Kerberos developer by providing sane defaults.  So if you don't know  
what ticket options you want to set, you don't need to.  This is in  
contrast to the krb5_get_init_creds APIs which have a bunch of  
usually unnecessary arguments that the caller needs to know should be  
0 or NULL to get the default behavior.


> A generic facility (i.e., not mechanism-specific, though perhaps with
> mechanism-specific options) for initial credential acquisition is  
> highly
> desirable.
>
>
>
>> 7) Referrals
>>
>>
> [...]
>
>> Instead of using DNS, Kerberos referrals use the KDC.  Referrals
>> allow the client to contact a KDC in the client principal's realm to
>> find out the service principal corresponding to a given service and
>> server name pair.
>>
>
> But this implies cross-realm configuration, if not even cross-realm
> keys.
>

Sure, but you can't detect the presence of cross-realm without  
trying.  Which means if we search for the tickets, we will end up  
trying to get referrals from the realm of each of the client  
principals in the cache collection.

This also brings up a point Sam made but I forgot to add to my  
initial email.  If a user uses a Kerberized service they don't want  
people to know they use, our searching algorithm may end up asking  
other realms for a referral for it.  This exposes information about  
the user that they might not want exposed.  For example we might end  
up asking the KDC for COMPANY.COM for a referral for the HTTP service  
for www.porn.com.

> Perhaps we need a requirement for the referrals work that it allow for
> referrals where no cross-realm keys have been exchanged.

I think that's probably outside the scope of this discussion.

>
>> What this means for client principal selection is that figuring out
>> if a given client principal is correct for a given server/service
>> pair requires an extra communication with the client principal's KDC
>> to get the service principal via a referral.
>>
>
> Which the client was going to do anyways.  I don't mind the
> infrastructure -- everyone seems to want some online infrastructure
> nowadays.
>

Some of our customers seem to have performance requirements due to  
using Kerberos over high-latency networks, networks with no DNS and  
networks where large numbers of ports are blocked (causing timeouts).

>
>> * Caching:
>>
>> Obviously asking this question every time the user performs an
>> operation is unacceptable.  Fortunately we can cache mappings from
>> server/service to client principal.  This means that if Jane uses
>> Kerberos for email, she will only be asked the first time.  This
>> functionality is critical for applications which perform periodic
>> tasks from the background.
>>
>
> But you'd still have to ask when priming the cache, and you'd have to
> know how long to cache mappings for, a way to clean the cache...
>

Yes, we will need some interface for editing the cache and/or hints  
table.

>
>
>> * Searching:
>>
>> Caching doesn't prevent the user from being prompted the first time,
>> and the more wide-spread Kerberos adoption gets, the longer the
>> client principal selection list will be.  If the user's first
>> experience with Kerberos is a series of long thought-provoking
>> questions from each Kerberized application, we're not going to be
>> winning any popularity contests -- especially with the site support
>> staff. :-)
>>
>> In particular, if the correct client principal is obvious (eg:
>> connecting to a server at secure-email.com requires tickets at  
>> SECURE-
>> EMAIL.COM), the user will wonder why the system didn't just select
>> the correct ticket automatically.  If the correct client principal
>> isn't obvious (eg: cross-realm is involved), then novice users won't
>>
>                                    ^
>                    not?
>

If the site is using cross realm, then a service at server.a.com may  
actually use the client principal [hidden email].  I'm not sure how a  
novice user would know that realm A.COM and realm B.COM share keys  
and thus that [hidden email] is the correct client principal to choose.  
If there's no cross realm (and you aren't some ancient thing like  
MIT), then your realm is probably the uppercase of the server's domain.

Of course you may also have no DNS, in which case again, it's not  
easy to intelligently guess.

>> know which one to select.
>>
>
> [...]
>
>> * Site-provided Hints:
>>
>> Unfortunately, as the number of principals the user has tickets for
>> increases, searching will get expensive.  Under pessimal network
>> conditions this could be unacceptably slow.
>>
>
> And the prompts get longer too.
>
>
>> Another way to generate the initial mappings would be to create a
>> command line tool, API or protocol extension for generating hints.
>> These hints would assist the Kerberos library in finding appropriate
>> client principals, greatly reducing the number of client principals
>> the search algorithm would have to try.  Then each site the user uses
>> could populate a hints table for their users.
>>
>> For example, a hint like "imap,imap*.company.com" -> "*@COMPANY.COM"
>> could tell the cache that for the imap service server
>> imap26.company.com, it should search for client principals in the
>> realm COMPANY.COM.
>>
>> Note that hints are not the same as a cache entry.  A cache entry
>> corresponds to a successful authentication and indicates which
>> specific client principal should be used for a given server/service
>> pair.  A site-provided hint is really just a suggestion for which
>> client principals to try first to optimize searching.
>>
>
> But since many users could not be expected to provide these this
> approach implies more distributed configuration/online infrastructure.
>

Yes, I'm talking about the site providing this.  I'd also be  
interested in people's thoughts on whether these need to be delivered  
in a secure manner (ie: integrity protected?  privacy protected?).  
Having the hints table be public seems like an information leak and  
being able to add bogus hints it seems like a good way to irritate  
the user, but not much worse than unauthentic DNS SRV records.

> [...]
>
>> At this point I'd like to ask folks for their opinions on this before
>> getting any further into the details.  In particular I'd like to know
>> if I've missed any configurations that impact client principal
>> selection and whether folks agree with my views on prompting the user
>> for client principal selection (don't if you can possibly avoid it)
>> and initial ticket acquisition (only if you know the user wants to
>> use Kerberos).
>>
>
> This is going to be fun.
>
> The need for interaction in initial ticket acquisition [usually :)]
> cannot be avoided; use of a consistent system-wide mechanism for  
> this is
> desirable.
>
> For the rest, clearly prompting is a vary bad idea.  Don't do it.  
> If it
> means more configuration, oh well.  See above.


--lxs

Alexandra Ellwood <[hidden email]>
MIT Kerberos Development Team
<http://mit.edu/lxs/www>


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Client Principal Selection

Nicolas Williams
On Mon, Jul 11, 2005 at 03:41:19PM -0400, Alexandra Ellwood wrote:

> On Jul 11, 2005, at 2:31 PM, Nicolas Williams wrote:
> >On Fri, Jul 08, 2005 at 04:29:27PM -0400, Alexandra Ellwood wrote:
> >[...]
> >
> >>2) Client principals for multiple realms with no cross-realm
> >>authentication
> >
> >>3) Multiple client principals with different privileges (ie:
> >>[hidden email] and user/[hidden email])
> >>
> >I see these two as very similar problems.  Both can be addressed with
> >notions of environment variables, trust partitions, AFS-like PAGs or
> >variants thereof -- each application instance then has access to only
> >one set of TGTs for only one client principal.  I think that could be
> >seen as very user-friendly in some cases, as not at all user-
> >friendly in
> >others.
>
> They're similar problems given the current KRB5CCNAME/system default  
> principal model of client principal selection.  However, once we  
> start caching or searching they become different problems because in  
> #2 it's very likely that only one of the client principals can  
> actually authenticate to the service -- or that one authentication  
> path is obviously preferable to the other.  In #3 both the user@REALM  
> and user/admin@REALM principals can successfully authenticate.
>
> Note that the KRB5CCNAME/system default principal model is  
> insufficient for applications like Mail.app or Eudora which support  
> getting email for multiple accounts.  Fortunately right now we  
> haven't gotten users with two Kerberos-using email accounts, but if  
> we're successful in increasing Kerberos deployment we'll eventually  
> have some.

Right -- they're similar only assuming a solution that binds each
application instance to a single client principal and its credentials.

They are dissimilar otherwise.

>
> >In any case, use of any OS facility more advanced than environment
> >variables runs into portability problems.
>
> Once the CCAPI gets ported to Unix we should have a lot more  
> flexibility in what we can do.  The CCAPI only requires the OS  
> provide a local RPC and has been written to support two platforms  
> with wildly different local RPC models (Mac OS X and Windows).  The  
> rest of the CCAPI functionality is provided through the RPC layer  
> including the ability to have multiple ccaches and iterate over them.

I was referring to the need or desire to track groups of processes --
initial group members and progeny.  It isn't necessarily easy to do that
portably without making use of environment variables.

> >>7) Referrals
> >>
> >>
> >[...]
> >
> >>Instead of using DNS, Kerberos referrals use the KDC.  Referrals
> >>allow the client to contact a KDC in the client principal's realm to
> >>find out the service principal corresponding to a given service and
> >>server name pair.
> >>
> >
> >But this implies cross-realm configuration, if not even cross-realm
> >keys.
> >
>
> Sure, but you can't detect the presence of cross-realm without  
> trying.  Which means if we search for the tickets, we will end up  
> trying to get referrals from the realm of each of the client  
> principals in the cache collection.

Sure, that's a lot of online work -- though it can be parallelized.  And
the results may not be deterministic (what if more than one client
principal can get a service ticket for the target?  how should one or
another be selected?).

> This also brings up a point Sam made but I forgot to add to my  
> initial email.  If a user uses a Kerberized service they don't want  
> people to know they use, our searching algorithm may end up asking  
> other realms for a referral for it.  This exposes information about  
> the user that they might not want exposed.  For example we might end  
> up asking the KDC for COMPANY.COM for a referral for the HTTP service  
> for www.porn.com.

Yes, clearly this approach has privacy issues.

> >Perhaps we need a requirement for the referrals work that it allow for
> >referrals where no cross-realm keys have been exchanged.
>
> I think that's probably outside the scope of this discussion.

I didn't suggest discussing technical details of referrals, but whether
there might be a need for a feature that could be brought to the KRB
WG's attention.  I don't see why that wouldn't be in scope here, except
unless you reject the use of referrals immediately due to the issues
above.

> >
> >>What this means for client principal selection is that figuring out
> >>if a given client principal is correct for a given server/service
> >>pair requires an extra communication with the client principal's KDC
> >>to get the service principal via a referral.
> >>
> >
> >Which the client was going to do anyways.  I don't mind the
> >infrastructure -- everyone seems to want some online infrastructure
> >nowadays.
> >
>
> Some of our customers seem to have performance requirements due to  
> using Kerberos over high-latency networks, networks with no DNS and  
> networks where large numbers of ports are blocked (causing timeouts).

Sure, which leads you down the distributed configuration/hints path.

> >
> >>* Searching:
> >>
> >>Caching doesn't prevent the user from being prompted the first time,
> >>and the more wide-spread Kerberos adoption gets, the longer the
> >>client principal selection list will be.  If the user's first
> >>experience with Kerberos is a series of long thought-provoking
> >>questions from each Kerberized application, we're not going to be
> >>winning any popularity contests -- especially with the site support
> >>staff. :-)
> >>
> >>In particular, if the correct client principal is obvious (eg:
> >>connecting to a server at secure-email.com requires tickets at  
> >>SECURE-
> >>EMAIL.COM), the user will wonder why the system didn't just select
> >>the correct ticket automatically.  If the correct client principal
> >>isn't obvious (eg: cross-realm is involved), then novice users won't
> >>
> >                                   ^
> >                   not?
> >
>
> If the site is using cross realm, then a service at server.a.com may  
> actually use the client principal [hidden email].  I'm not sure how a  
> novice user would know that realm A.COM and realm B.COM share keys  
> and thus that [hidden email] is the correct client principal to choose.  
> If there's no cross realm (and you aren't some ancient thing like  
> MIT), then your realm is probably the uppercase of the server's domain.

Ah, I get it.

[...]
> >But since many users could not be expected to provide these this
> >approach implies more distributed configuration/online infrastructure.
> >
>
> Yes, I'm talking about the site providing this.  I'd also be  
> interested in people's thoughts on whether these need to be delivered  
> in a secure manner (ie: integrity protected?  privacy protected?).  

Yes, such configuration should be delivered securely.  As securely as
DNS (i.e., if you want it secure deploy DNSSEC) is probably OK.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Client Principal Selection

Jeffrey Altman-4
In reply to this post by Alexandra Ellwood
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






_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Client Principal Selection

David M. O'Rourke
In reply to this post by Alexandra Ellwood
followup

While not ideal, I would hate to sacrifice a good solution to #2  
because it doesn't fully address a solution for #3.

On Jul 12, 2005, at 8:46 AM, David M. O'Rourke wrote:

>
> The issue of multiple identities in the "same" realm is less  
> interesting and has I believe existing workarounds in most OS's  
> (i.e. I can simply log into two separate user sessions on the OS of  
> my choice, Windows XP, and Mac OS both fully support this  
> functionality via user switching).   While not ideal, I would hate  
> to sacrifice a good solution to #1 because it doesn't fully address  
> a solution for #3.
>
>

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Client Principal Selection

Jeffrey Hutzelman
In reply to this post by Jeffrey Altman-4
On Monday, July 11, 2005 04:56:32 PM -0400 Jeffrey Altman <[hidden email]>
wrote:

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

I'm afraid it's not that simple.  For example, consider SSH with
GSSAPI-based key exchange.  The SSH protocol begins with each side sending
a banner followed by a KEXINIT message which contains a list of algorithms
supported by that side.  The KEXINIT messages are sent simultaneously, and
a client that waits to receive the server's message before sending its own
risks deadlock.

Thus, the SSH client needs to know whether to claim support for the gssapi
keyex method without waiting to see if the server supports it.  Further, if
the gssapi keyex method is chosen and then the user has no credentials, the
connection will fail.  Therefore, current ssh clients generally make the
first gss_init_sec_context call before the negotation even starts, to see
whether they are likely to be able to authenticate to this particular
server.

So, in this case we cannot use the service's support for Kerberos
authentication or lack thereof to decide whether to obtain credentials,
because we need to know whether we can/should use Kerberos before we ever
get that information from the server.


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Client Principal Selection

Jeffrey Altman-4
Jeffrey Hutzelman wrote:

> I'm afraid it's not that simple.  For example, consider SSH with
> GSSAPI-based key exchange.  The SSH protocol begins with each side
> sending a banner followed by a KEXINIT message which contains a list of
> algorithms supported by that side.  The KEXINIT messages are sent
> simultaneously, and a client that waits to receive the server's message
> before sending its own risks deadlock.
>
> Thus, the SSH client needs to know whether to claim support for the
> gssapi keyex method without waiting to see if the server supports it.
> Further, if the gssapi keyex method is chosen and then the user has no
> credentials, the connection will fail.  Therefore, current ssh clients
> generally make the first gss_init_sec_context call before the negotation
> even starts, to see whether they are likely to be able to authenticate
> to this particular server.
>
> So, in this case we cannot use the service's support for Kerberos
> authentication or lack thereof to decide whether to obtain credentials,
> because we need to know whether we can/should use Kerberos before we
> ever get that information from the server.
This is true and for these applications there is little that can be done
to prevent the need to evaluate which client principal should be used.
For applications such as e-mail, the ability to avoid the evaluation is
possible.

Jeffrey Altman


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

smime.p7s (3K) Download Attachment