Difference between revisions of "Projects/Fast negotiation"

Revision as of 15:42, 4 November 2009

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.

API Changes

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.