[OpenAFS-devel] aklog on MacOS X was Re: Service Ticket Questions

[Jeffrey Altman]

This is a cryptographically signed message in MIME format.

--------------ms000704030800050309010508
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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 jane@MY.REALM
followed by a Kerberos 524 translation and that the
krbtgt/MY.REALM@MY.REALM ticket for jane@MY.REALM 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


--------------ms000704030800050309010508
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJXzCC
AwowggJzoAMCAQICAw7NrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0NzU3WhcNMDYwNTI3MTc0NzU3
WjBzMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT
SmVmZnJleSBFcmljIEFsdG1hbjErMCkGCSqGSIb3DQEJARYcamFsdG1hbkBzZWN1cmUtZW5k
cG9pbnRzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKjPyrF+rdjOUSK/
bWwZHdx5p1+y6iiCd4vvYEVDxouYFp5C/fZEWm5n45ubBUbMSUI1MAZN6ooEoH09UTj6BXhM
S8B987ls81dKOIUphTF2jOzq8gsFmeA15yHMRAD20LqUWeLyvYk8FCNQw+dsKMMhX+WdsxOm
RY/1jPkJL6oN8kEwoUFkOX9/OfWWh6oFnV6faiEHUKDMFubsb9X0KVD8iIeR7Cxz7i4kXqRX
wMlp2fyoxcDIJrBaTY8nA++g3p34IkWt1a5po6g683nIgSnGpwYIwuJheBqSEZfLYWa+1KdD
6Sn27Ud94GqUvPVG5jC6zVC5EJ2aWuoAu+nNuV8CAwEAAaM5MDcwJwYDVR0RBCAwHoEcamFs
dG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA
A4GBADtvO//tjiAV6VJGtoNtrl34mB5jGyGTiotzw8riB6zz0GvY11bcWDmp6JKif+pVG+8L
IySDosbuva13qu2HwYUxBmWc7CoNd2k9kRlcrfbDUTTrGOZK8qyqNqT3gQZTAa9ZnUI0su9G
y/n2o5bQcaYdqR3htNrpvdLSPOWhILOXMIIDCjCCAnOgAwIBAgIDDs2tMA0GCSqGSIb3DQEB
BAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w
NTA1MjcxNzQ3NTdaFw0wNjA1MjcxNzQ3NTdaMHMxDzANBgNVBAQTBkFsdG1hbjEVMBMGA1UE
KhMMSmVmZnJleSBFcmljMRwwGgYDVQQDExNKZWZmcmV5IEVyaWMgQWx0bWFuMSswKQYJKoZI
hvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAqM/KsX6t2M5RIr9tbBkd3HmnX7LqKIJ3i+9gRUPGi5gWnkL99kRa
bmfjm5sFRsxJQjUwBk3qigSgfT1ROPoFeExLwH3zuWzzV0o4hSmFMXaM7OryCwWZ4DXnIcxE
APbQupRZ4vK9iTwUI1DD52wowyFf5Z2zE6ZFj/WM+Qkvqg3yQTChQWQ5f3859ZaHqgWdXp9q
IQdQoMwW5uxv1fQpUPyIh5HsLHPuLiRepFfAyWnZ/KjFwMgmsFpNjycD76DenfgiRa3Vrmmj
qDrzeciBKcanBgjC4mF4GpIRl8thZr7Up0PpKfbtR33gapS89UbmMLrNULkQnZpa6gC76c25
XwIDAQABozkwNzAnBgNVHREEIDAegRxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMAwG
A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAO287/+2OIBXpUka2g22uXfiYHmMbIZOK
i3PDyuIHrPPQa9jXVtxYOanokqJ/6lUb7wsjJIOixu69rXeq7YfBhTEGZZzsKg13aT2RGVyt
9sNRNOsY5kryrKo2pPeBBlMBr1mdQjSy70bL+fajltBxph2pHeG02um90tI85aEgs5cwggM/
MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM
V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z
dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD
VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv
bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5
WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk
LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2
vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9
A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw
EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0
ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R
BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB
AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ
Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN
d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG
A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMjEyMjI1MzFaMCMGCSqG
SIb3DQEJBDEWBBT4HCXvTRd+2KAIDbQ0Jf4l1vE+TzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQQIDDs2tMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTANBgkqhkiG9w0BAQEFAASC
AQBZ37JOkVK8WOd21SP5Y/O9DxnIGvYf1h0VH/e2nKK/l0f4egppFt+mUAOXj1CpNTaeTzD6
VUX2E07f3lHJpx8CR2ASLHokh4a3ANWhIjFXSOJ7PyBC44DP7HD48O1B5BBWBYLaZAVDBpHx
kiPWGKjbkMpXde+Qj4U4e+bShBRcjYaIELo5HUCk1qXx0i/JxjEuJTxoz0kx8zWzKH2+Ahuk
LW/nOsTCtTbBk4iAYJL9gq8+G21LDZHUH5DdtpEJV8V+kH4MVcPc0xwLvpFqRdBzckooIFEq
nmGrDD3AuG44kI9EgP0vEc9s0CircOXkyWiL0Xb5OsgeuKlc+5/Lw5t0AAAAAAAA
--------------ms000704030800050309010508--