On Mar 21, 2006, at 12:12 PM, Ernest Prabhakar wrote:
Hi lxs,
On Mar 21, 2006, at 7:01 AM, 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.
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).
Um, I'm having trouble following this argument, but I want to make
sure I understand your issue. I completely understand that AFS
users don't want to run a GUI application. But, I'm confused with
how that impacts the issue of using "Keychain Services" as the
underlying API and storage mechanism for managing AFS tickets:
http://developer.apple.com/documentation/Security/Conceptual/
Security_Overview/Security_Services/chapter_4_section_6.html
Presumably, it would be straightforward for AFS and Kerberos to use
Keychain Services and provide their own CLI interface, no? Or are
you concerned about something completely different?
Using Keychain Services but implementing our own GUI doesn't make a
lot of sense for the MIT Kerberos team. We already have to provide
cross-platform implementations for the credentials storage mechanisms
(memory, file and CCAPI) since there's no Keychain Services on
Windows or the UNIX platforms we support. The only reason I can
think for using Keychain Services is to leverage its Mac GUI:
Keychain Access. Last time I looked into this I ran into the
following problems:
* The Keychain Access application doesn't deal terribly well with
transient credentials. Kerberos credentials disappear on reboot and
logout (including if the computer panics), only last 10-21 hours and
need to be renewed regularly. If the site uses credentials with
addresses in them, new credentials may be acquired every time the
machine changes networks. The Keychain Access GUI doesn't really
have a good way of expressing the difference between a saved password
and a 10 hour Kerberos credential.
* The Keychain Access application doesn't have a way of expressing
the Kerberos concepts of ticket-granting and service credentials. A
Kerberos identity consists of a ticket-granting credential and one or
more service credentials. Since the user may have more than one
Kerberos identity, these credentials need to be logically grouped in
order for the user to understand what is going on.
That being said, my argument from my previous mail is basically this:
Keychain Access, Kerberos.app and the Network Identity Manager all
exist to debug and fix problems with identity selection and
credential acquisition. If everything is working the user won't
launch these applications unless they're a "look under the hood" type.
Now Kerberos has serious problems with identity selection. Currently
applications automatically select the "default" credentials, which
results in terrible behavior when the user has multiple identities
which they want to use simultaneously. So in the multiple-identity
Kerberos case, something is going wrong constantly, and users need to
use Kerberos.app all the time. But rather than sinking resources
into Kerberos.app now, I think we'd get a whole lot more bang for our
buck if we replace the default ccache model with something more
expressive. Then users won't need to go to Kerberos.app except when
they have a real problem.
None of this solves the problem for AFS of course, I'm just
explaining why you shouldn't count on a Mac version of the Network
Identity Manager (or similar functionality in Keychain Access) any
time soon.
--lxs
Alexandra Ellwood <[EMAIL PROTECTED]>
MIT Kerberos Development Team
<http://mit.edu/lxs/www>
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
