Proposal for NIM 2.0 Multiple Identity Provider User Experience and PK-INIT

[Jeffrey Altman]

comments in-line:

Alexandra Ellwood wrote:
>
> A few comments:
>
>
> * In your design the information used to acquire credentials is the
> "primary identity" and the Kerberos principal of the acquired
> credentials is the "derived identity":
>
>     * In an environment where multiple pieces of information are
> required to acquire Kerberos credentials (ie: two-factor
> authentication), which of the two pieces of information is the primary
> identity?
The "primary identity" is the initial credential and secret.  In
traditional Kerberos v5 this is the ticket granting ticket and the
password.    Secondary credentials are those obtained via a subsequent
authentication using a service ticket.  For example, a Kerberos v4 TGT,
an AFS token, a X.509 certificate issued by a KCA.

In the SmartCard world, the initial credential is the private key and
the certificate and the secret is the PIN or biometric used to access
the private key.
>
>     * What happens when a site migrates principals from one type of
> authentication to another?  For example if a sysadmin changes a bunch
> of principals from PKINIT to smart cards, is any of the cached
> information in NIM still useful or does the user need to start over
> because their primary identity has changed?  How does NIM behave when
> the user tries to use their certificate identity instead of the new
> smart card one?
The configuration of the Kerberos v5 identity remains the same and is
re-used.  If a traditional Kerberos v5 authentication attempt fails with
a pre-auth required error and the permitted list is PKINIT, then the
user will be given the error and prompted to select a certificate (if
one can not be found by searching the store for a certificate with an
appropriate SAN.)   When the user selects a certificate, the appropriate
Certificate identity will be created and associated with the krb5
principal for credential acquisition.

Going in the reverse direction.  If the user has attempted to obtain
credentials using the certificate and pkinit is no longer supported,
then the user will be notified and the krb5 library prompter will
request a password (or other data) through the NIM user interface.
>
>     * Have you thought about how this design interacts with
> application identity selection?  I notice in all your examples you
> still have a "default identity".  With the new Kerberos Identity
> Management (KIM) API there will be no default identity.  Instead
> applications will provide information about the service they want to
> contact and a client principal will be selected for them based on
> cached information.  Using your terminology this means that given a
> "derived identity" (the Kerberos identity) KIM must be able to
> determine the "primary identity" that generates it to start the
> authentication process.  Do you store this information?
This information is stored in the user's profile.    Today, without KIM,
GSS-API queries NIM for a specific krb5 principal.  NIM searches for
credentials for that principal.  If found, it returns the cache that
contains them.  Otherwise, it searches for a configuration for the
requested principal and prompts the user.  If a configuration does not
exist, it creates a configuration based upon default values and prompts
the user.   If the user successfully obtains credentials, the cache is
returned to the caller.

In the multiple identity provider case, each identity provider will be
queried for configurations that can be used to obtain the requested
credentials.  if there is more than one, the user will be prompted with
the identity selection dialog displaying only those that can be used
(plus the "new identity ..." option.)

KIM can take advantage of the configuration data to help it figure out
which certificate to use and so on.  Obviously, once KIM is available
the krb5 credential provider will have to be modified to interact with it.
> * In several places you refer to a user-configurable icon which
> identifies the identity's site.  If the user is relying on the icon to
> figure out what identity to choose, what prevents malicious software
> from swapping the icons around to trick the user into using the wrong
> identity?
There is nothing that protects the user configuration data other than
the user's permissions.   Malicious software could modify any of the
user's configuration data because it is stored in the user's profile.
> * I'm not sure I agree with your statements that users will have an
> easier time remembering their smart card or certificate than the
> Kerberos identity.  I do agree wholeheartedly that for the most part
> users have no idea that the string in question has anything to do with
> Kerberos and our user interfaces shouldn't force them to know it is a
> Kerberos string.  But Kerberos identities look like email addresses,
> which are something users are already very familiar with.  They are
> also short and easy to remember (unlike, say, the information about a
> cert).  Also as I pointed out above if sysadmins are migrating from
> one type of hardware pre-authentication to another the Kerberos
> identity string is the only thing that is consistent across the
> migration.
The help desks at several organizations that I am working with do not
believe that the Kerberos v5 principal looking like an e-mail address is
a benefit because the realm and the e-mail domain appear similar but the
e-mail addresses are not necessarily related to the non-realm components
of the authentication identity.  This has become the case because while
e-mail addresses are recycled after a period of time, authentication
identities never are because they are placed on ACLs.

Jeffrey Altman
Secure Endpoints Inc.

>
>
>
> On Jul 6, 2007, at 3:44 PM, Jeffrey Altman wrote:
>
>> In April Secure Endpoints was approached by the Navy regarding the
>> issuance of a KFW 3.x release including PKINIT this Summer in time for
>> the October 1, 2007 Homeland Security Presidential Directive (HSPD) #12
>> deadline.  Although in past years there have been extensions granted,
>> this year there will not be any and all government agencies must have an
>> HSPD-12 compliant smartcard system deployed.
>>
>> On April 25th Sam and I met and discussed the future of KFW which was
>> followed up by a summary KFW road map e-mail sent to kfwdev on April
>> 26th.  In that e-mail I indicated that a proposal for integrating PKINIT
>> into KFW would be forthcoming.  I was hoping to be much further along in
>> the implementation of KFW 3.3 by this point in time.  However, user
>> experience design work is really hard and it has taken close to two
>> months to put together a design that Asanka and I believe will be easy
>> to end users to get their heads around.
>>
>> Yesterday I sent the proposal to kfwdev.  However, after speaking with
>> Sam, I am re-sending it to krbdev because it is hoped that the user
>> experience design used for adding PKINIT support will be consistent
>> across all platforms.  At the current time there are no plans to add
>> PKINIT user interface support to MIT Kerberos 1.7.  However, there is a
>> significant need (and some limited funding) to make this happen on
>> Microsoft Windows.
>>
>> A copy of our user experience design proposal can be found at
>>
>> http://www.secure-endpoints.com/netidmgr/proposal-nim-multiple-id-nc-ux.pdf
>>
>>
>> It contains extensive mock-ups for what we believe the user interface
>> should look like and how the flow of control should behave.
>>
>> The key concept that this design is based upon is the multiple identity
>> provider support that Network Identity Manager's internal framework was
>> designed to support.  NIM was designed from day one to ease the
>> implementation and use of Single Sign-On.  It was designed at the same
>> time that I was developing the Kerberos Consortium Proposal and Project
>> List as well as while the PKINIT drafts were being worked on in the
>> IETF.  One of my strongest beliefs is that the "Kerberos protocol" is
>> the glue technology that can be used to bridge all other authentication
>> systems.  This belief strongly influenced the NIM architecture.
>>
>> NIM 1.x implemented a single identity provider built around Kerberos v5
>> principals as identities and an extensible system of Credential
>> Providers for which there are now Kerberos v5, Kerberos v4, AFS, and
>> Kerberized Certificate Authority implementations from Secure Endpoints.
>> There have also been Credential Providers implemented by third parties.
>>  There is the GRID Proxy Cert provider and at least one provider used
>> for acquiring web credentials internal to a private organization.
>> Credential providers can be used to form hierarchies which permit the
>> Identity Provider to work with its Credential Provider to obtain initial
>> credentials.  These initial credentials can then be used to obtain
>> additional credentials via other credential providers which can then be
>> used for additional credentials and so on.  The end result is a Single
>> Sign-On infrastructure where a user obtains credentials once and a whole
>> collection of credentials of different types are automatically obtained
>> and renewed.
>>
>> The NIM design permits (but did not implement) multiple Identity
>> Providers.  One reason we added the concept of multiple Identity
>> Providers was because of the direction that the PKINIT drafts were
>> taking.  Under PKINIT, a single certificate/smartcard can be used to
>> authenticate a user to multiple disjoint Kerberos v5 realms.  As it
>> turns out, one of the concepts behind HSPD-12 is that a single
>> identification card issued by the United States government should be
>> usable for authentication within multiple agencies.
>>
>> Other potential Identity Providers are either local or remote "Secure
>> Key Stores".  Think Apple's KeyChain or Google's NSS Browser Password
>> Sync.  The user unlocks a key store and uses the credentials contained
>> within to obtain additional credentials.  For example, obtain
>> credentials for multiple Kerberos v5 identities.  I can imagine that
>> users will want a KeyChain identity provider when NIM is ported to
>> MacOS X.
>>
>> For PKINIT support there are essentially two ways that it can be
>> implemented.  The most natural to Kerberos v5 developers is to simply
>> add the certificate specification to the Kerberos v5 identity
>> configuration.  This way the user continues to select their identity by
>> the Kerberos v5 principal name.  There are several problems with this
>> approach.
>>
>> The user interface becomes more complex.  Not only does the user have to
>> remember their Kerberos v5 identity but they have to now choose between
>> password and certificate/smartcard authentication.  If you want to make
>> the prompts smart, then you need to contact the KDC to determine if
>> pkinit is supported.  For that matter you will also need a way of
>> determining if password authentication is disabled for the account.
>> However, requiring communication with the KDC should be avoided as it
>> leads to uncomfortable delays on slow networks or when the KDC is
>> inaccessible.  Users do not anticipate a communication to the KDC until
>> after they press the "Finish" button.
>>
>> In addition, I suspect that for a long time to come organizations will
>> encourage the use of certificates/smartcards when possible but they are
>> going to have to continue to permit the use of password
>> pre-authentication simply because there are too many systems to update
>> and not all of the protocols will permit the use of remote
>> smartcards/certificates.  Therefore, its not going to be possible to
>> design a user experience that requires a smartcard/certificate if the
>> KDC supports it for the account and otherwise prompts for a password.
>>
>> Users have a really hard time thinking about identities.  Kerberos v5 is
>> a protocol and we, as developers, think of it as an identity type.
>> Users on the other hand don't.  When you put users through a usability
>> lab you find that users might know that they have a Stanford University
>> Network ID (SUNetId) but they don't know that SUNetIds are Kerberos
>> principals.  For them, it might as well be an e-mail address.  This is
>> where the concept of logo branding came from.  A user might not remember
>> which realm name they want to use from a list, but they will absolutely
>> remember the University or Corporate logo associated with the identity.
>>
>> In a Single Sign-On environment, the user is more likely to remember:
>>
>>  * insert SmartCard
>>  * select SmartCard from list
>>  * enter passphrase to access SmartCard
>>
>> than:
>>
>>  * select Kerberos v5 principal from list
>>  * select use SmartCard or Password
>>  * insert SmartCard (if necessary)
>>  * enter passphrase or password
>>
>> In addition, if the user has to authenticate to multiple systems, you
>> want the user to access the smartcard once and obtain all of the desired
>> credentials in one step instead of requiring the user to manually
>> credentials one Kerberos identity at a time.
>>
>> Then there is the issue of what to do about all of the users that don't
>> have PKINIT support available to them.  We just spent a year simplifying
>> the user interface of NIM.  For users that do not have a smartcard, why
>> should they be forced to deal with the added complexity necessary to
>> support PKINIT for those who do have it?
>>
>> The proposal we have put forward is clean.  Users that do not have a
>> smartcard/certificate and cannot use PKINIT will barely notice that
>> there has been a change in the user interface.  Their user experience is
>> essentially the same.  The only difference is that instead of being able
>> to automatically create an identity on the fly by simply entering in a
>> new principal name and password, they will be forced to use a wizard
>> that will assist them is setting up the identity.
>>
>> Users that need to use a smartcard/certificate will use the wizard to
>> construct their smartcard/certificate identity and associate it with a
>> Kerberos v5 principal.  From that point forward they can think about
>> their smartcard/certificate and not about which Kerberos name they
>> happen to be assigned.  If the smartcard/certificate is to be used to
>> obtain Kerberos credentials for multiple realms, that can easily be
>> configured as well.
>>
>> One of the nice things is that once the Kerberos v5 identity
>> configuration is created, it is re-used regardless of which initial
>> authentication path the user selects: smartcard/certificate or password.
>> If in the future a Secure Key Store provider becomes available, it will
>> seamlessly make use of the prior configuration.
>>
>> I realize that this approach to thinking about credential management may
>> be hard to accept for a development team focused on building and
>> promoting Kerberos.  As I see it the strength of Kerberos is in its
>> ability to not only provide for secure authentication, but also in its
>> ability to be used to join together with other authentication
>> technologies to provide a universal single sign-on experience for end
>> users regardless of which initial authentication technology is selected
>> by the user's home organization and which final authentication
>> technology selected by the service provider.   It is not important that
>> every user know what Kerberos is for it to be successful.  What is
>> important is that Kerberos be the mechanism by which single sign-on is
>> possible.
>>
>> The selection of the user experience for PKINIT is extremely important
>> and it will require a great deal of thought and consideration.  I
>> strongly believe that the approach Asanka and I have taken in the
>> proposed design is the right one.  Each of you probably have your own
>> ideas about how this should work.  I encourage each of you to think
>> about the question and propose your own ideas.
>>
>> I look forward to seeing your comments.
>>
>> Jeffrey Altman
>> Secure Endpoints Inc.
>>
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>
> --lxs
>
> Alexandra Ellwood <lxs at mit.edu>
> MIT Kerberos Development Team
> <http://mit.edu/lxs/www>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kfwdev/attachments/20070717/7d67d317/attachment.bin