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

[Alexandra Ellwood]

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?

     * 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?

     * 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?


* 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?


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



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>