Difference between revisions of "Projects/Fast negotiation"

Latest revision as of 23:48, 15 February 2010

The FAST negotiation project builds on Projects/FAST. That project defines an interface that a client can use to make an armor ticket available to the library. Currently, that interface mandates the use of FAST; if a client supplies an armor ticket then the library requires the KDC to support FAST.

In many situations, it is desirable to use FAST when it is available but to fall back to not using FAST if FAST is unavailable. This project proposes to implement a secure mechanism for accomplishing that goal.

Larry Zhu proposed [1] a mechanism for negotiating FAST. The client includes a padata in its request indicating it supports the negotiation mechanism. If the KDC receives this padata, it returns a modified as-rep including a checksum of the client's as-req along with an indication of whether FAST is supported.

Functional Requirements

• A mechanism to request an armor ticket and during the process of requesting that armor ticket securely determine whether the KDC supports FAST.
• A mechanism to store the result of FAST negotiation
• Enhancements of the FAST API to require/use FAST only when it is supported

In addition, the following would be strongly desirable:

• A mechanism to use Anonymous pkinit to obtain an armor ticket for a given set of realms if no armor ticket is provided

Encrypted Padata

Projects/Aliases added support for the encrypted padata field in MIT Kerberos. This field is currently a Microsoft extension introduced in Windows 2000. The KDC reply may contain a second set of padata encrypted in the reply key of the request. This field would not be useful for solving the same problems that FAST solves; among other reasons, the client must know the reply key before it can decrypt. However, this facility is sufficient for securely negotiating FAST.

Larry proposes to standardize this field and to standardize a mechanism for FAST negotiation. At the interop event, Larry's proposal was prototyped for MIT Kerberos. This included the necessary work to send the padata and to verify results.

Storing Negotiation results

Currently, armor tickets are stored in a credentials cache. In order to effectively use the negotiation mechanism, the client needs to be able to look at a given armor ticket and determine whether fast is available. [krbdev.mit.edu #6206] provides a way to store configuration information in a ticket cache. This API shall be used to store information on whether FAST is available.

The current approach is to store state based on what is returned from the AS request. The pre-authentication framework does permit a cross-realm armor ticket to be used; for example, if a host key is used to obtain an armor ticket and the client and host are registered in different realms, then a cross-realm armor ticket will be used. The assumption of this project is that whether FAST is used will be determined based on what the KDC against which the AS request to get the armor ticket supports. This can be expanded in the future to store more fine-grained negotiation state if needed. Options would include:

• Constructing configuration keys that include the realm name and using the negotiation procedure recursively
• Using the negotiation procedure recursively and storing per-realm state with some new mechanism--possibly associated with the TGT for that realm

Another complexity is handling of renewed and validated credentials. Currently, the APIs for handling renewal and credential validation take a ccache, but do not write credentials out to the ccache. Since there is no API documentation it's not clear what behavior changes are acceptable. For a program today that runs the renewal and then replaces the credentials in the cache, writing out the credentials would be a no-op. For a program that expects credentials unrelated to the renewal to remain in the cache and be undisturbed, that behavior change would be significant. Another approach might be to preserve set_config state across calls to krb5_cc_initialize. That should not affect existing code, although it would make it difficult to unset configuration state in a ccache.

Unexpected preauth handling

Prior to [krbdev.mit.edu #6480], included in Krb5 1.7, if the KDC received unknown padata it would return KDC_ERR_PREAUTH_FAILED rather than KDC_ERR_PREAUTH_REQUIRED. Also, prior to 1.7, the KDC did not include the set of pre-authentication types to try with the PREAUTH_FAILED error. The FAST negotiation code needs to handle this situation. The proposal is that if PREAUTH_FAILED is received as the first error and no pre-authentication types were forced, then try again without including the request for negotiation. If the KDC ends up supporting negotiation, the ticket flag will be set and we will correctly fail. When standardizing this we will need to require that KDCs implementing this negotiation ignore unknown padata and return PREAUTH_REQUIRED not PREAUTH_FAILED.

API Changes

FAST API

The current FAST API requires that if a client specifies a FAST armor ticket, then FAST will be required. However comments in the header file make it clear that this is not a guaranteed interface. the API contract is that the client is providing an armor ticket for the library. The library may either interpret this as "must use FAST," as it does today or "should use fast."

This project changes the behavior from "must use fast," to "should use fast." and provides an additional API to force FAST be required.

The following APIs are introduced:

/**Set a ccache where resulting credentials will be stored.  If set, then the
 * krb5_get_init_creds family of APIs will write out credentials to the given
 * ccache.  Setting an output ccache is desirable both because it simplifies
 * calling code and because it permits the krb5_get_init_creds APIs to write
 * out configuration information about the realm to the ccache.
 */
krb5_error_code KRB5_CALLCONV
krb5_get_init_creds_opt_set_out_ccache
(krb5_context context, krb5_get_init_creds_opt *opt, krb5_ccache ccache);
krb5_error_code KRB5_CALLCONV
krb5_get_init_creds_opt_set_fast_flags
(krb5_context context, krb5_get_init_creds_opt *opt, krb5_flags flags);
krb5_error_code KRB5_CALLCONV
krb5_get_init_creds_opt_get_fast_flags
(krb5_context context, krb5_get_init_creds_opt *opt, krb5_flags *out_flags);

/* Fast flags*/
#define KRB5_FAST_REQUIRED 1l<<0 /*!< Require KDC to support FAST*/

Review

This section documents the review of the project according to Project policy. It is divided into multiple sections. First, approvals should be listed. To list an approval type

#~~~~

(hash mark followed by four tilde characters) on its own line. The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with {{project-block}}.

Approvals

1. Ghudson 16:38, 7 December 2009 (UTC)

Discussion