RX Kerberos 5 security class requirements of Kerberos library
hartmans at MIT.EDU
Tue Jan 2 12:34:07 EST 2007
>>>>> "Jeffrey" == Jeffrey Altman <jaltman at secure-endpoints.com> writes:
Jeffrey> Sam Hartman wrote:
>>>>>>> "Jeffrey" == Jeffrey Altman <jaltman at secure-endpoints.com>
Jeffrey> Before I submit a patch, is the concept of
Jeffrey> krb5_generate_creds_with_keytab something that MIT and
Jeffrey> Heimdal would accept? If so, a patch can be ready in a
Jeffrey> few hours.
>> I'm very uncomfortable with this. IT takes the KDC out of the
>> loop for generating service tickets. I'm not sure how it will
>> interact with future plans for use of authorization data,
>> ticket extensions, etc.
Jeffrey> This function is being written explicitly to provide
Jeffrey> service to service authentication when the services share
Jeffrey> the same key. The two scenarios are:
Jeffrey> * Service A authenticates as service A to service B
Jeffrey> where the two services share the same key
Especially for things that really need to work when the KDC is down,
this seems ugly but perhaps necessary.
Jeffrey> * Service A authenticates as authenticated user U to
Jeffrey> service B where Service A is trusted to do so. (Think
Jeffrey> Samba or WebDAV export of AFS without credential
Jeffrey> delegation of the client's credentials.)
This case really needs to involve the KDC for auditing and
It's because of this case that I'm very nervous about providing this
functionality. If we could find a way of providing the functionality
for AFS, but making it very clear that it was not generally useful and
that designing applications to depend on it is a bad ide, I'd be much
Jeffrey> This provides a benefit to services that rely on the
Jeffrey> Kerberos 5 ticket format as an internal authentication
Jeffrey> token format.
I'm not convinced services should do that unless they use the Kerberos
Jeffrey> Without krb5_generate_creds_with_keytab there are two
Jeffrey> alternatives that AFS can pursue:
Jeffrey> (1) AFS can use the keytab entry to query the KDC for a
Jeffrey> ticket for itself. Doing so removes the ability of
Jeffrey> multiple AFS services on the same machine to communicate
Jeffrey> when the network connection goes down unless there is a
Jeffrey> KDC instance on the machine.
I think that this is a far better design for AFS.
Jeffrey> (2) AFS can use a token format that is independent of the
Jeffrey> Kerberos 5 ticket in which case AFS can print as many
Jeffrey> tokens as it wants without contacting the KDc.
Obviously AFS can do this; it at least provides a cleaner abstraction
than using part but not all of Kerberos. I don't have an opinion on
whether this is the right approach.
I'd really appreciate feedback from those not involved in AFS either
as users or developers on two issues. First, whether we should
introduce AFS-specific functionality into Kerberos. Second on whether
this is a desirable function to expose as a general function that is
not AFS specific.
I'd appreciate input from the AFS community on what we can do if we
decide that this functionality needs to be AFS specific to limit its
More information about the krbdev