Fast Negotiation: renewed and validated credentials

[Sam Hartman]

Greg, I really appreciate the excellent write-up.
>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:

    Greg> krb5_cc_set_config.  (Another option would be to claim a
    Greg> ticket flag for local use and set a flag on the TGT.  For
    Greg> the moment that option is not on the table.)
Let's put it on the table.
This is the second complexity we've run into because of the particular design choices I'm making.
In my mind, that means we should be thinking about alternatives.

I'd like to discuss the tradeoffs of the different options.
    Greg>   1. Change the behavior of krb5_get_credentials_renew and
    Greg> krb5_get_credentials_validate to re-initialize the ccache
    Greg> and store the new TGT there.  The theory is that in pretty
    Greg> much all use cases, we imagine that the caller was going to
    Greg> do that anyway.

This probably doesn't break existing code.  However, existing code
will not get the benefits of negotiation, because if the existing code
calls krb5_cc_initialize then the negotiation state will be
overwritten.

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

I don't think this breaks anything existing.  It makes it more
difficult to unset an option set by krb5_cc_set_config.

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

Good summary there.

4. Use a ticket flag rather than krb5_cc_set_config to store state in the ccache.

One positive benefit is that it may be more clear how to handle the cross-realm armor ticket case I discussed on the working group list.

The main drawback is that it leaves us with a longer-term problem in
that the krb5_cc_set_config interface really isn't useful when
combined with renewal and validation.  We could decide that
krb5_cc_set_config is a bad idea, although to me, it seems like it has
significant potential future utility.

I think this option is by far the easiest  option to implement, although I think it doesn't give us as many options for future extensibility.

5. Extend krb5_get_renew_creds and krb5_get_validate_creds to create new APIs that take an output ccache.

This option has similar effects to option 1, without the possibility
of breaking existing code.  It's slightly more difficult to implement
than option 1, although I don't think implementation would be
difficult at all.

I'd recommend that we drop option 1 as option 5 seems superior with
the exception of API clutter.

My current favorite is option 2, because it means negotiation will
work with existing code and because it does not break code.  If needed
we can introduce an API that initializes a cache without maintaining
config state.

However option 3 is attractive in its simplicity.