Fast Negotiation: renewed and validated credentials

[Greg Hudson]

Let me elaborate on this a little bit for the sake of those not closely
following the project.

The point of FAST, as it currently exists in MIT krb5, is to protect
AS-REQs for password-based principals using an armor ticket.  The armor
ticket is typically obtained using a regular AS request for a different
principal such as a host principal, which is presumed to have a strong
key.

Sam's project implements a feature which allows a client to determine,
while obtaining the armor ticket, whether the KDC understands FAST.  The
plan is to store the result of this negotiation in the armor ticket's
ccache using krb5_cc_set_config.  (Another option would be to claim a
ticket flag for local use and set a flag on the TGT.  For the moment
that option is not on the table.)

A complication of this plan is that our APIs for getting credentials
currently return the credential without storing it in the ccache; the
ccache operations are performed by the caller (e.g. kinit).  For
krb5_get_init_creds_{password,keytab} it is relatively straightforward
to solve this, because the API is extensible.  The caller can provide a
ccache via a new API krb5_get_init_creds_opt_set_ccache, and we get to
remove ccache operations from kinit.

The issue at hand is: what if someone decides to renew an armor ticket,
or validate a post-dated armor ticket?  The APIs for renewal and
validation do not take extensible options structures--but they do take
ccaches.  Currently, those ccaches are basically read-only; the caller
(typically kinit) takes responsibility for re-initializing the ccache
and storing the renewed or validated TGT.  This process would obliterate
the FAST negotiation state.

The solutions on the table are:

  1. Change the behavior of krb5_get_credentials_renew and
krb5_get_credentials_validate to re-initialize the ccache and store the
new TGT there.  The theory is that in pretty much all use cases, we
imagine that the caller was going to do that anyway.

  2. Change the behavior of krb5_cc_initialize to preserve set_config
state, so that FAST negotiation state is preserved when the caller
reinitializes the ccache.

  3. Don't support renewal or validation of armor tickets.  This would
be acceptable for the typical expected use case (using a host key to
armor a user AS-REQ) but might constrain weirder use cases, such as
using an existing user TGT to armor a request for a new one shortly
before reaching the end of your renewal lifetime.  (This option was
presented by Sam over Jabber; he didn't mention it in his mail.)

One could also imagine creating extended variants of the renew and
validate APIs.

I am still thinking about which solution I prefer.