Alexandra Ellwood wrote: > Apple has such a tool. It's called Keychain Access. It stores certs, > passwords, identity preferences... basically anything living in your > keychain. I can't speak for Apple (I'm not even an Apple employee) but > I'd place good money on this being where Apple would display Kerberos > and AFS credentials if they were doing the support themselves.
I completely agree that Keychain Access is the MacOSX equivalent of the Network Identity Manager. Apple could consider providing the same set of services to end users through Keychain Access that we do in KFW with NetIDMgr. This would require that Keychain Access provide the necessary plug-in framework to allow additional credential types to be added and to allow the credential acquisition dependency trees supported by NetIDMgr. > That being said I've never placed high priority on Kerberos support in > Keychain Access because Mac users don't seem to want it. Mac users want > Kerberos to work without any interaction with any tools. They want to > be prompted for tickets when they need new ones (or have them > automatically acquired in the pkinit case). Users never want to have a tool that they must play with. Its not like NetIDMgr or Kerberos.app are games and they certainly do not provide any additional benefit to a user. Watching credentials be obtained and renewed has zero entertainment benefit. The only reason a user would want to look at a monitor application is when something goes wrong. That said, there also needs to be a mechanism by which end users are able to configure the authentication system so that it is possible to deduce that when a user wants an AFS token for my.cell that the way you obtain such a token is with the Kerberos 5 principal [EMAIL PROTECTED] followed by a Kerberos 524 translation and that the krbtgt/[EMAIL PROTECTED] ticket for [EMAIL PROTECTED] is obtained using the Public/Private Key pair stored in Keychain Access. Once this type of configuration is done the future use of the credentials must be seamless and transparent and the application should never again need to be touched. > For example, we've provided automatic ticket renewal via Kerberos.app in > KfM for several years now, yet we still receive numerous bug reports > asking for automatic ticket renewal. When we point out the support in > Kerberos.app, users invariably reply that having to run an application > to get that support is unacceptable, even if that application is > automatically launched as part of their startup items. From the user's > standpoint the only acceptable solutions involve seamless behavior with > minimal interaction on their part. I have been doing the same for KFW since the 2.6 release. Users want renewals to take place automatically. This of course requires that a process be run in their user session. It does not mean that the process must interact with the end user. In KFW we require NetIDMgr (or Leash in previous releases) to be running in order for there to be a standard mechanism by which the Kerberos libraries can interact with the desktop. All dialogs are generated by NetIDMgr (or Leash) and not by the individual applications that are calling into GSS or the Kerberos libraries. We both agree that the goal should be minimal interaction with the user. However, there must be a tool available to assist in debugging when things go wrong. > As a result I bet that a Network Identity Manager or Kerberized Keychain > Access would be just as unloved on Mac OS X as Kerberos.app is. At best > it would be used as a tool for support staff to diagnose authentication > problems. Which makes it very low priority given the development > resources available to the KfM product (ie: me). This is why I've been > putting all my effort into the new KLL. The goal of the new KLL is to > provide prompt-based identity selection similar to the way passwords are > prompted for already. Note that this is effectively what Apple already > does with the keychain access when it asks whether you want to use > something stored in the keychain. There is no disagreement that the cross-platform Kerberos login library is a much higher priority since it brings more bang for the buck. I'm not trying to imply in any way that MIT's Kerberos team (in other words, you) should be spending time providing a core service that Apple should be providing for all credential mechanisms. I strongly believe that operating system vendors must step up and provide a single point of entry for management of the user's credentials regardless of how they are being used. There should not be KeyChain Access for three types, and Kerberos.app for a fourth, and an InfoCard.app for the same credential types when used with WS-Trust applications. > Note that I suspect this mentality is unique to the Mac and > intentionally fostered by Apple. Apple consistently provides interfaces > which emphasize simplicity and seamlessness. You can see this with the > existing uses of the keychain. Users basically only visit Keychain > Access when something has gone wrong. Normally cert/password/identity > selection is done by keychain dialogs which are automatically spawned by > the application that needs the cert/password/identity. I do not believe that the approach taken by Apple is wrong. Users should not have to be aware of all of the decisions that take place on their behalf. The phishing problem is only made worse when end users are trained to be involved in providing credentials for each and every resource that they attempt to access. I think that Password Managers for browsers are a wonderful tool to help train users to not enter in passwords everywhere they go. Unfortunately, I believe that unless the Password Managers are integrated into the OS, the attack footprint becomes to large when each browser decides to implement their own mechanisms in the user space and can't properly secure the contents. AFS (and NFSv4) users have a specific set of needs that differ from those of standard applications because they do not have a natural user interface with which to interact with the user. Therefore, we must provide tools that can be used once to configure the mechanisms by which credentials should be obtained and then implement the automation that can ensure that those credentials are always available. It is not possible to guess whether or not the user wants unauthenticated vs authenticated access to a particular directory/file except by examining the credentials that are available at the time of the request. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
