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

[Jeffrey Altman]

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.

-------------- 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/krbdev/attachments/20070706/af383596/attachment.bin