Difference between revisions of "Projects/Initial creds improvements"

Revision as of 17:55, 21 June 2015

This project is an internal improvement and should have minimal externally visible impact.

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.

Several conditions can cause a "restart" of the exchange, discarding any existing KDC padata and FAST state: a realm referral, a KDC_ERR_PREAUTH_FAILED response when the client sent only informational padata, or a PA-FX-FAST padata element when the client did not use FAST but has an armor key.

Although the krb5_init_creds_context structure contains many state variables, they do not track a progression towards the end goal. As a result, an attacker impersonating a KDC can send replies to the client in non-sensical orders, which the client will attempt to interpret. This project will add stage-tracking so that the client can better manage request state.

Proposed stages

Stage 1: Optimistic pre-authentication

If no optimistic pre-authentication information is available, and the client moves immediately to stage 2. In the future, we may implement optimistic PA-SPAKE, in which case there will always be an optimistic pre-authentication step.

We currently have minimal support for optimistic pre-authentication: the caller can specify a list of preauth types with krb5_get_init_creds_opt_set_preauth_list() to activate those mechanisms for the initial request; any parameters needed by the preauth mechs must be determined via gic options or profile variables, none of which we currently have. Optimistic pre-authentication is currently performed after restarts, but this property is not important; in the proposed new plan, only one optimistically pre-authenticated request will be generated.

If the KDC responds with KDC_ERR_PREAUTH_FAILED, the client should move to stage 2. If the KDC responds with KDC_ERR_MORE_PREAUTH_DATA_REQUIRED, it should respond as in stage 3. Otherwise, the client should respond as in stage 2.

(XXX problem: if the KDC responds with PREAUTH_FAILED and a hint list, we should really move to stage 3, especially if we're doing optimistic PA-SPAKE all the time. But what if the KDC them comes back with a realm referral? The whole idea is not to backtrack stages. This needs more thought.)

Stage 2: Unauthenticated request

In this stage, the client sends a request with no substantive padata and no cookie. It may send informational padata such as PA-REQ-ENC-PA-REP or PA-AS-FRESHNESS.

If the KDC responds with a realm referral (KDC_ERR_WRONG_REALM or KDC_ERR_C_PRINCIPAL_UNKNOWN with a distinct crealm), the client should remain in stage 2 and retry in the new realm.

If the KDC responds with KDC_ERR_PREAUTH_FAILED, it is likely a pre-1.7 MIT krb5 KDC which does not ignore unknown client padata types. The client should remain in stage 2 and retry without informational padata. This retry should not be performed twice without changing realms.

If the KDC responds with an error containing padata, one of the padata elements is PA-FX-FAST, and the client did not use FAST but has an armor key, the client should remain in stage 2 and should retry using FAST. This retry should be exclusive with the previous retry, as pre-1.7 MIT krb5 KDCs do not support FAST.

If the KDC responds with KDC_ERR_PREAUTH_REQUIRED, the client should move to stage 3.

If the KDC responds with any other error, the client should abort the exchange.

If the KDC responds with an AS-REP, the client should move to stage 4.

Stage 3: Pre-authentication

In this stage, the client sends a pre-authenticated request using the METHOD-DATA from a previous KDC error, which we will call the "current hint list." The client iterates over the current hint list in the order supplied by the KDC (perhaps as re-sorted by preferred_preauth_types) and selects the first non-informational pre-authentication mechanism for which it can produce a padata value. If no padata value can be generated, the client should abort the exchange.

If the KDC responds with KDC_ERR_PREAUTH_REQUIRED, the client should remain in stage 3, replace the current hint list, and produce a new pre-authenticated message. This case should be unusual, the MIT KDC does it as part of the SAM-2 Duo integration. The client may restrict this case to the situation when the previous requested used SAM-2, and may restrict itself to using SAM-2 for subsequent requests, but it must be willing to perform multiple KDC_ERR_PREAUTH_REQUIRED -> PA-SAM-2 round trips.

If the KDC responds with KDC_ERR_MORE_PREAUTH_REQUIRED, the client should remain in stage 3 and continue using the same pre-authentication mechanism, passing the padata for that type to the mechanism's handler to produce a new padata value. If the clpreauth module cannot continue, the client should move on to the next untried padata type in the current hint list.

If the KDC responds with KDC_ERR_PREAUTH_FAILED, the client should remain in stage 3 and try the next untried padata type in the current hint list.

If the KDC responds with KDC_ERR_PREAUTH_EXPIRED, the client should remain in stage 3, discard the cookie and pre-authentication mechanism state, and produce a new padata value for the same pre-authentication mechanism. If the AS key was generated during a previous attempt, it should be retained. Any responder items should also be retained.

If the KDC responds with any other error containing padata, the client should remain in stage 3 and try to produce a new padata value using the current mechanism's tryagain method.

If the KDC responds with an AS-REP, the client should move to stage 4.

Stage 4: AS-REP processing

In this stage, the client processes the padata in the AS-REP, and either aborts or successfully terminates the exchange.