RX Kerberos 5 security class requirements of Kerberos library

[Sam Hartman]

>>>>> "Jeffrey" == Jeffrey Altman <jaltman at secure-endpoints.com> writes:

    Jeffrey> Sam Hartman wrote:
    >>>>>>> "Jeffrey" == Jeffrey Altman <jaltman at secure-endpoints.com>
    >>>>>>> writes:
    >>
    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.
    >> 
    >> --Sam
    >> 
    Jeffrey> Sam:

    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
authorization.

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
happier.


    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
protocol.

    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
general applicability.

--Sam