Projects/Initial creds improvements

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.

This project is mostly internal design changes to the initial creds API. The immediate user-visible impact should not be significant.

Background

get_in_tkt.c implements the krb5_init_creds_step() API, which is responsible for processing a KDC reply and generating the next request (or terminating the exchange). Currently this function is divided into two helper functions: init_creds_step_reply(), which examines the KDC reply and alters the request state, and init_creds_step_request(), which generates a request based on the current state.

The current code has the following limitations, most of which do not arise in current pre-authentication scenarios:

• If two krb5_init_creds_step() operations are interleaved using the same krb5_context, they erroneously share per-request per-module data pointers, which may confuse clpreauth modules. (They also share the "tried" list which tracks previously tried mechanisms, but that list is not currently doing much.)

• Support for optimistic preauth is very limited. It must be initiated by the calling application, not by configuration, and there is no way to specify salt or s2kparams for producing the reply key.

• If a preauth mechanism fails (even during optimistic preauth), we do not continue on to other mechanisms, unless it failed on the client side during method-data processing.

• clpreauth modules do not get much information about the padata they are processing. It could be from optimistic preauth, from KDC METHOD-DATA in a PREAUTH_REQUIRED error, from KDC METHOD-DATA in a MORE_PREAUTH_DATA_REQUIRED error, or from an AS-REP. (Other KDC errors are handled via the tryagain method, so those are distinguishable.)

• clpreauth modules cannot indicate that they expect additional padata values before the mechanism is complete. In the middle of a conversation, a KDC could issue an AS-REP with no padata and the client would try to decrypt it with whatever the reply key currently is. This limitation has no current security consequences, but could become important in the future.

• The preferred_preauth_types realm variable is a hack; the order of KDC padata should be the preferred order. However, it is important to keep trying PKINIT first by default as current KDCs do not always put it before encrypted timestamp when they ought to.

Improvements

Proper scoping of per-request preauth data

The per-request krb5_clpreauth_modreq pointers for each module should be maintained an object separate from krb5_preauth_context. This object should be linked from krb5_init_creds_context.

The "tried" list is currently unused and should be removed. A list of preauthentication mechanisms which have failed should be maintained separately from preauth state.

Optimistic preauth

TBD

Continuing after failures=

A preauth mechanism can fail in several ways:

• The clpreauth module's process method can fail to generate initial padata value during optimistic preauth or processing of KDC method-data. In this case we already continue on to the next mechanism.

• The KDC can reply with KDC_ERR_PREAUTH_FAILED, with or without METHOD-DATA.

• The KDC can reply with KDC_ERR_MORE_PREAUTH_DATA_REQUIRED, and the process method can fail to generate a padata value.

• The KDC can reply with another error containing e-data, and the tryagain method can fail to generate a padata value.

If optimistic preauth results in KDC_ERR_PREAUTH_FAILED, we should discard per-request preauth state and begin anew. If the KDC included METHOD-DATA, we should use that; otherwise we should send an unauthenticated request in order to get a KDC_ERR_PREAUTH_REQUIRED error with METHOD-DATA.

The first time we receive a KDC METHOD-DATA list, we should remember it for the purpose of continuing after failures. We should discard this list on a KDC_ERR_PREAUTH_EXPIRED error (as the METHOD-DATA list may include a stale cookie). If we receive multiple METHOD-DATA lists, we can either replace the initial list or ignore the subsequent lists; it should not be very important. However, the METHOD-DATA in a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error should be treated separately from this list, as it is part of a multi-hop conversation for a particular mechanism.

We should maintain a list of preauth mechanisms which have failed so that we don't try them again. This list should be separate from the KDC METHOD-DATA and the preauth request state, as we should not retry a failed preauth mechanism after KDC_ERR_PREAUTH_EXPIRED. This list should be discarded on a realm referral, although a realm referral during a preauthentication conversation should be rare. A KDC_ERR_PREAUTH_EXPIRED error should not count as failing. Optimistic preauthentication failure should not count either, as it may only have failed for lack of information from the KDC.

Stage tracking for clpreauth modules

TBD

clpreauth module control of conversation termination

TBD